en/glep/glep-0023.txt

GLEP: 23
Title: Handling of ACCEPT_LICENSE
Version: $Revision: 1.5 $
Last-Modified: $Date: 2006/11/19 22:46:27 $
Author: Jason Stubbs <jstubbs@gentoo.org>, Marius Mauch <genone@gentoo.org>
Status: Accepted
Type: Standards Track
Content-Type: text/x-rst
Created: 9-Mar-2004
Post-History: 8-Mar-2004 10-Mar-2004 25-Oct-2004 18-Nov-2006 19-Nov-2006


Abstract
========

Currently, every ebuild in the main gentoo repository 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.

Status Update
=============

Repoman has been updated to check for the LICENSE syntax.
A development portage branch with support for ACCEPT_LICENSE
and license groups exists.

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 names may contain [a-zA-Z0-9] (english alphanumeric characters),
_ (underscore), - (dash), . (dot) and + (plus sign).

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, implementations 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-MUST-HAVE-READ``.  
``NON-MUST-HAVE-READ`` licenses are those that don't require manual 
acceptance for to be considered legally binding.  This is the current 
behaviour of portage.

These groups are defined in a new file ``license_groups`` in 
the ``profiles`` subdirectory of the tree (or overlays).
Details of handling groups defined in overlays is implementation dependent.

The format of this file is

::
        
        <groupname> <license1> <license2> ... <licenseN>

Also any line starting with # is ignored and may be used for comments.
Group names use the same syntax as normal license names. Also license groups 
may contain other groups.
License groups may not contain negated elements, so a group

::
        
        mygroup foo -bar -bla

is illegal.


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"

License groups may be negated with the result that all elements of that group
are also negated.

Portage will also offer a package.license facility to offer this functionality
on a per-package base (analog to package.keywords), other implementations may
implement such a facility differently or not at all.

Behaviour
---------

Unaccepted licenses will be treated like any other masked package, that is
the user interface of an implementation will display a message listing any 
license that has to be accepted before the package can be merged with a 
pointer to the exact license text.

Past versions of this document proposed to handle license-masked packages
like blockers, but this would be inconsistent with other visibility 
filters as well as the current blocker system (as a blocker affects two 
packages) and be more complicated to implement.

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
========================

Available in portage svn repository under main/branches/license-masking


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-MUST-HAVE-READ`` in the main gentoo repository as implementations
are not required to provide an internal default.

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	GLEP: 23
2	Title: Handling of ACCEPT_LICENSE
3	Version: $Revision: 1.5 $
4	Last-Modified: $Date: 2006/11/19 22:46:27 $
5	Author: Jason Stubbs <jstubbs@gentoo.org>, Marius Mauch <genone@gentoo.org>
6	Status: Accepted
7	Type: Standards Track
8	Content-Type: text/x-rst
9	Created: 9-Mar-2004
10	Post-History: 8-Mar-2004 10-Mar-2004 25-Oct-2004 18-Nov-2006 19-Nov-2006
11
12
13	Abstract
14	========
15
16	Currently, every ebuild in the main gentoo repository is required to have a
17	valid 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	Status Update
22	=============
23
24	Repoman has been updated to check for the LICENSE syntax.
25	A development portage branch with support for ACCEPT_LICENSE
26	and license groups exists.
27
28	Motivation
29	==========
30
31	Many users wish to regulate the software they install with regards to
32	licenses for various reasons [1]_. Some want a system free of any
33	software that is not OSI-approved; others are simply curious as to what
34	licenses they are implicitly accepting.
35
36	Furthermore, some software requires that a user interactively accept its
37	license for its author's to consider it legally binding. This is
38	currently implemented using ``eutils.eclass``.
39
40
41	Specification
42	=============
43
44	Ebuild LICENSE Variable
45	-----------------------
46
47	Most ebuilds are for software which is released under a single license.
48	In these cases, the current LICENSE variable can remain as is. For
49	example:
50
51	::
52
53	LICENSE="single-license"
54
55	However, there are several ebuilds for software which is released under
56	several licenses, of which the user must accept one, some or all [2]_.
57	To complicate this, some ebuilds include optional components which fall
58	under a different license.
59
60	To accomodate these cases, LICENSE syntax should accomodate all
61	functionality offered by a DEPEND string. To keep things simple, this
62	GLEP proposes that the syntax be identical. For example:
63
64	::
65
66	LICENSE="mandatory-license
67	\|\| ( choosable-licence1 chooseable-license-2 )
68	useflag? ( optional-component-license )"
69
70
71	License names may contain [a-zA-Z0-9] (english alphanumeric characters),
72	_ (underscore), - (dash), . (dot) and + (plus sign).
73
74	License Groups
75	--------------
76
77	Almost all users are willing to install any software that is
78	FSF-approved. Other users are willing to install any software and
79	implicitly accept its license. To this end, implementations will also
80	need to handle grouping of licenses.
81
82	At a minimum, there needs to be the groups ``GPL-COMPATIBLE``,
83	``FSF-APPROVED``, ``OSI-APPROVED`` and ``NON-MUST-HAVE-READ``.
84	``NON-MUST-HAVE-READ`` licenses are those that don't require manual
85	acceptance for to be considered legally binding. This is the current
86	behaviour of portage.
87
88	These groups are defined in a new file ``license_groups`` in
89	the ``profiles`` subdirectory of the tree (or overlays).
90	Details of handling groups defined in overlays is implementation dependent.
91
92	The format of this file is
93
94	::
95
96	<groupname> <license1> <license2> ... <licenseN>
97
98	Also any line starting with # is ignored and may be used for comments.
99	Group names use the same syntax as normal license names. Also license groups
100	may contain other groups.
101	License groups may not contain negated elements, so a group
102
103	::
104
105	mygroup foo -bar -bla
106
107	is illegal.
108
109
110	ACCEPT_LICENSE
111	--------------
112
113	This GLEP proposes that a user be able to explicitly accept or decline
114	licenses by editing a new variable ``ACCEPT_LICENSE`` in
115	``/etc/make.conf``. Again, to keep things simple, the syntax should be
116	similar to that of other incrementals. For example:
117
118	::
119
120	ACCEPT_LICENSE="-* accepted-license -declined-license"
121
122	As an extension, ``ACCEPT_LICENSE`` must also support `license groups`_.
123	This GLEP proposes that the license group be prepended by the special
124	character "``@``". For example:
125
126	::
127
128	ACCEPT_LICENSE="-* @FSF-APPROVED"
129
130	License groups may be negated with the result that all elements of that group
131	are also negated.
132
133	Portage will also offer a package.license facility to offer this functionality
134	on a per-package base (analog to package.keywords), other implementations may
135	implement such a facility differently or not at all.
136
137	Behaviour
138	---------
139
140	Unaccepted licenses will be treated like any other masked package, that is
141	the user interface of an implementation will display a message listing any
142	license that has to be accepted before the package can be merged with a
143	pointer to the exact license text.
144
145	Past versions of this document proposed to handle license-masked packages
146	like blockers, but this would be inconsistent with other visibility
147	filters as well as the current blocker system (as a blocker affects two
148	packages) and be more complicated to implement.
149
150	Rationale
151	=========
152
153	An implementation of this proposal should make it easy for users wishing
154	to regulate their software without affecting those that don't.
155
156
157	Reference Implementation
158	========================
159
160	Available in portage svn repository under main/branches/license-masking
161
162
163	Backwards Compatibility
164	=======================
165
166	There should be no change to the user experience without the user
167	explicitly choosing to do so. This mandates that the
168	configuration variable be named ``ACCEPT_LICENSE`` as some users may
169	already have it set due to ebuilds using ``eutil.eclass``'s
170	implementation. It also mandates that the default ``ACCEPT_LICENSE`` be
171	set to ``@NON-MUST-HAVE-READ`` in the main gentoo repository as implementations
172	are not required to provide an internal default.
173
174	References
175	==========
176
177	.. [1] Gentoo Linux Bug 17367
178	(http://bugs.gentoo.org/show_bug.cgi?id=17367)
179	.. [2] Gentoo Linux Bug 34146
180	(http://bugs.gentoo.org/show_bug.cgi?id=34146)
181
182
183	Copyright
184	=========
185
186	This document has been placed in the public domain.