en/glep/glep-0023.txt

GLEP: 23
Title: Portage handling of ACCEPT_LICENSE
Version: $Revision: 1.1 $
Last-Modified: $Date: 2004/03/08 17:26:04 $
Author: Jason Stubbs <jstubbs@gentoo.org>,
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 9-Mar-2004
Post-History: 8-Mar-2004 10-Mar-2004


Abstract
========

Currently, every ebuild in the portage tree is required to have a valid 
LICENSE entry.  However, the syntax of this entry is not officially 
defined and the entry itself is only used when outputting package 
details.
 

Motivation
==========

Many users wish to regulate the software they install with regards to 
licenses for various reasons [1]_.  Some want a system free of any 
software that is not OSI-approved; others are simply curious as to what 
licenses they are implicitly accepting.

Furthermore, some software requires that a user interactively accept its 
license for its author's to consider it legally binding.  This is 
currently implemented using ``eutils.eclass``.


Specification
=============

Ebuild LICENSE Variable
-----------------------

Most ebuilds are for software which is released under a single license.  
In these cases, the current LICENSE variable can remain as is.  For 
example:

::

        LICENSE="single-license"

However, there are several ebuilds for software which is released under 
several licenses, of which the user must accept one, some or all [2]_.  
To complicate this, some ebuilds include optional components which fall 
under a different license.

To accomodate these cases, LICENSE syntax should accomodate all 
functionality offered by a DEPEND string.  To keep things simple, this 
GLEP proposes that the syntax be identical.  For example:

::

        LICENSE="mandatory-license
            || ( choosable-licence1 chooseable-license-2 )
            useflag? ( optional-component-license )"


License Groups
--------------

Almost all users are willing to install any software that is 
FSF-approved.  Other users are willing to install any software and 
implicitly accept its license.  To this end, portage will also need to 
handle grouping of licenses.

At a minimum, there needs to be the groups ``GPL-COMPATIBLE``, 
``FSF-APPROVED``, ``OSI-APPROVED`` and ``NON-INTERACTIVE``.  
``NON-INTERACTIVE`` licenses are those that don't require interactive 
acceptance for to be considered legally binding.  This is the current 
behaviour of portage.


ACCEPT_LICENSE
--------------

This GLEP proposes that a user be able to explicitly accept or decline 
licenses by editing a new variable ``ACCEPT_LICENSE`` in 
``/etc/make.conf``.  Again, to keep things simple, the syntax should be 
similar to that of other incrementals.  For example:

::

        ACCEPT_LICENSE="-* accepted-license -declined-license"

As an extension, ``ACCEPT_LICENSE`` must also support `license groups`_.  
This GLEP proposes that the license group be prepended by the special 
character "``@``".  For example:

::

        ACCEPT_LICENSE="-* @FSF-APPROVED"


Emerge Behaviour
----------------

At a minimum, emerge must handle unaccepted licenses the same way that 
it handles blockers.  That is, with the --pretend flag the 
not-yet-accepted license should be listed in the output.  Without the 
--pretend flag, emerge should stop before any software is installed.

This GLEP proposes that, unlike blockers, dependencies for software 
should be checked regardless of license acceptance.  Doing so will allow 
the user to review all necessary licenses before initiating an actual 
emerge.

It is also proposed that the --ask option will display an unaccepted 
license and ask for acceptance, but not update any configuration files 
at this stage.  Finally, the --verbose option should also list the 
licenses accepted for each package.


Rationale
=========

An implementation of this proposal should make it easy for users wishing 
to regulate their software without affecting those that don't.


Reference Implementation
========================

TODO


Backwards Compatibility
=======================

There should be no change to the user experience without the user 
explicitly choosing to do so.  This mandates that the 
configuration variable be named ``ACCEPT_LICENSE`` as some users may 
already have it set due to ebuilds using ``eutil.eclass``'s 
implementation.  It also mandates that the default ``ACCEPT_LICENSE`` be 
set to ``@NON-INTERACTIVE``.


References
==========

.. [1] Gentoo Linux Bug 17367
       (http://bugs.gentoo.org/show_bug.cgi?id=17367)
.. [2] Gentoo Linux Bug 34146 
       (http://bugs.gentoo.org/show_bug.cgi?id=34146)


Copyright
=========

This document has been placed in the public domain.

1	g2boojum	1.1	GLEP: 23
2			Title: Portage handling of ACCEPT_LICENSE
3	g2boojum	1.2	Version: $Revision: 1.1 $
4			Last-Modified: $Date: 2004/03/08 17:26:04 $
5	g2boojum	1.1	Author: Jason Stubbs <jstubbs@gentoo.org>,
6			Status: Draft
7			Type: Standards Track
8			Content-Type: text/x-rst
9			Created: 9-Mar-2004
10	g2boojum	1.2	Post-History: 8-Mar-2004 10-Mar-2004
11	g2boojum	1.1
12
13			Abstract
14			========
15
16			Currently, every ebuild in the portage tree is required to have a valid
17			LICENSE entry. However, the syntax of this entry is not officially
18			defined and the entry itself is only used when outputting package
19			details.
20
21
22			Motivation
23			==========
24
25			Many users wish to regulate the software they install with regards to
26			licenses for various reasons [1]_. Some want a system free of any
27			software that is not OSI-approved; others are simply curious as to what
28			licenses they are implicitly accepting.
29
30			Furthermore, some software requires that a user interactively accept its
31			license for its author's to consider it legally binding. This is
32			currently implemented using ``eutils.eclass``.
33
34
35			Specification
36			=============
37
38			Ebuild LICENSE Variable
39			-----------------------
40
41			Most ebuilds are for software which is released under a single license.
42			In these cases, the current LICENSE variable can remain as is. For
43			example:
44
45			::
46
47			LICENSE="single-license"
48
49			However, there are several ebuilds for software which is released under
50			several licenses, of which the user must accept one, some or all [2]_.
51			To complicate this, some ebuilds include optional components which fall
52			under a different license.
53
54			To accomodate these cases, LICENSE syntax should accomodate all
55			functionality offered by a DEPEND string. To keep things simple, this
56			GLEP proposes that the syntax be identical. For example:
57
58			::
59
60	g2boojum	1.2	LICENSE="mandatory-license
61			\|\| ( choosable-licence1 chooseable-license-2 )
62	g2boojum	1.1	useflag? ( optional-component-license )"
63
64
65			License Groups
66			--------------
67
68			Almost all users are willing to install any software that is
69	g2boojum	1.2	FSF-approved. Other users are willing to install any software and
70	g2boojum	1.1	implicitly accept its license. To this end, portage will also need to
71			handle grouping of licenses.
72
73	g2boojum	1.2	At a minimum, there needs to be the groups ``GPL-COMPATIBLE``,
74			``FSF-APPROVED``, ``OSI-APPROVED`` and ``NON-INTERACTIVE``.
75			``NON-INTERACTIVE`` licenses are those that don't require interactive
76			acceptance for to be considered legally binding. This is the current
77			behaviour of portage.
78	g2boojum	1.1
79
80			ACCEPT_LICENSE
81			--------------
82
83			This GLEP proposes that a user be able to explicitly accept or decline
84			licenses by editing a new variable ``ACCEPT_LICENSE`` in
85			``/etc/make.conf``. Again, to keep things simple, the syntax should be
86			similar to that of other incrementals. For example:
87
88			::
89
90			ACCEPT_LICENSE="-* accepted-license -declined-license"
91
92			As an extension, ``ACCEPT_LICENSE`` must also support `license groups`_.
93			This GLEP proposes that the license group be prepended by the special
94			character "``@``". For example:
95
96			::
97
98	g2boojum	1.2	ACCEPT_LICENSE="-* @FSF-APPROVED"
99	g2boojum	1.1
100
101			Emerge Behaviour
102			----------------
103
104			At a minimum, emerge must handle unaccepted licenses the same way that
105			it handles blockers. That is, with the --pretend flag the
106			not-yet-accepted license should be listed in the output. Without the
107			--pretend flag, emerge should stop before any software is installed.
108
109			This GLEP proposes that, unlike blockers, dependencies for software
110			should be checked regardless of license acceptance. Doing so will allow
111			the user to review all necessary licenses before initiating an actual
112			emerge.
113
114			It is also proposed that the --ask option will display an unaccepted
115			license and ask for acceptance, but not update any configuration files
116			at this stage. Finally, the --verbose option should also list the
117			licenses accepted for each package.
118
119
120			Rationale
121			=========
122
123			An implementation of this proposal should make it easy for users wishing
124			to regulate their software without affecting those that don't.
125
126
127			Reference Implementation
128			========================
129
130			TODO
131
132
133			Backwards Compatibility
134			=======================
135
136			There should be no change to the user experience without the user
137			explicitly choosing to do so. This mandates that the
138			configuration variable be named ``ACCEPT_LICENSE`` as some users may
139			already have it set due to ebuilds using ``eutil.eclass``'s
140			implementation. It also mandates that the default ``ACCEPT_LICENSE`` be
141			set to ``@NON-INTERACTIVE``.
142
143
144			References
145			==========
146
147			.. [1] Gentoo Linux Bug 17367
148			(http://bugs.gentoo.org/show_bug.cgi?id=17367)
149			.. [2] Gentoo Linux Bug 34146
150			(http://bugs.gentoo.org/show_bug.cgi?id=34146)
151
152
153			Copyright
154			=========
155
156			This document has been placed in the public domain.
157