en/glep/glep-0023.txt

GLEP: 23
Title: Portage handling of ACCEPT_LICENSE
Version: $Revision: 1.3 $
Last-Modified: $Date: 2004/10/26 00:21:28 $
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


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.

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

These groups are defined in a new file ``license_groups`` in 
the ``profiles`` subdirectory of the tree (or overlays).
The format of this file is

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

Also any line starting with # is ignored and may be used for comments.
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 Behaviour
-----------------

Unaccepted licenses will be treated like any other masked package, that is
emerge 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-INTERACTIVE`` in the main gentoo repository as there will
be no internal default in portage.

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	genone	1.4	Version: $Revision: 1.3 $
4			Last-Modified: $Date: 2004/10/26 00:21:28 $
5			Author: Jason Stubbs <jstubbs@gentoo.org>, Marius Mauch <genone@gentoo.org>
6	g2boojum	1.3	Status: Accepted
7	g2boojum	1.1	Type: Standards Track
8			Content-Type: text/x-rst
9			Created: 9-Mar-2004
10	genone	1.4	Post-History: 8-Mar-2004 10-Mar-2004 25-Oct-2004 18-Nov-2006
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	g2boojum	1.3
21			Status Update
22			=============
23
24			Repoman has been updated to check for the LICENSE syntax.
25	genone	1.4	A development portage branch with support for ACCEPT_LICENSE
26			and license groups exists.
27	g2boojum	1.1
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	g2boojum	1.2	LICENSE="mandatory-license
67			\|\| ( choosable-licence1 chooseable-license-2 )
68	g2boojum	1.1	useflag? ( optional-component-license )"
69
70
71			License Groups
72			--------------
73
74			Almost all users are willing to install any software that is
75	g2boojum	1.2	FSF-approved. Other users are willing to install any software and
76	g2boojum	1.1	implicitly accept its license. To this end, portage will also need to
77			handle grouping of licenses.
78
79	g2boojum	1.2	At a minimum, there needs to be the groups ``GPL-COMPATIBLE``,
80			``FSF-APPROVED``, ``OSI-APPROVED`` and ``NON-INTERACTIVE``.
81			``NON-INTERACTIVE`` licenses are those that don't require interactive
82			acceptance for to be considered legally binding. This is the current
83			behaviour of portage.
84	g2boojum	1.1
85	genone	1.4	These groups are defined in a new file ``license_groups`` in
86			the ``profiles`` subdirectory of the tree (or overlays).
87			The format of this file is
88
89			::
90
91			<groupname> <license1> <license2> ... <licenseN>
92
93			Also any line starting with # is ignored and may be used for comments.
94			License groups may not contain negated elements, so a group
95
96			::
97
98			mygroup foo -bar -bla
99
100			is illegal.
101
102	g2boojum	1.1
103			ACCEPT_LICENSE
104			--------------
105
106			This GLEP proposes that a user be able to explicitly accept or decline
107			licenses by editing a new variable ``ACCEPT_LICENSE`` in
108			``/etc/make.conf``. Again, to keep things simple, the syntax should be
109			similar to that of other incrementals. For example:
110
111			::
112
113			ACCEPT_LICENSE="-* accepted-license -declined-license"
114
115			As an extension, ``ACCEPT_LICENSE`` must also support `license groups`_.
116			This GLEP proposes that the license group be prepended by the special
117			character "``@``". For example:
118
119			::
120
121	g2boojum	1.2	ACCEPT_LICENSE="-* @FSF-APPROVED"
122	g2boojum	1.1
123	genone	1.4	License groups may be negated with the result that all elements of that group
124			are also negated.
125	g2boojum	1.1
126	genone	1.4	Portage Behaviour
127			-----------------
128	g2boojum	1.1
129	genone	1.4	Unaccepted licenses will be treated like any other masked package, that is
130			emerge will display a message listing any license that has to be accepted
131			before the package can be merged with a pointer to the exact license text.
132
133			Past versions of this document proposed to handle license-masked packages
134			like blockers, but this would be inconsistent with other visibility
135			filters as well as the current blocker system (as a blocker affects two
136			packages) and be more complicated to implement.
137	g2boojum	1.1
138			Rationale
139			=========
140
141			An implementation of this proposal should make it easy for users wishing
142			to regulate their software without affecting those that don't.
143
144
145			Reference Implementation
146			========================
147
148	genone	1.4	Available in portage svn repository under main/branches/license-masking
149	g2boojum	1.1
150
151			Backwards Compatibility
152			=======================
153
154			There should be no change to the user experience without the user
155			explicitly choosing to do so. This mandates that the
156			configuration variable be named ``ACCEPT_LICENSE`` as some users may
157			already have it set due to ebuilds using ``eutil.eclass``'s
158			implementation. It also mandates that the default ``ACCEPT_LICENSE`` be
159	genone	1.4	set to ``@NON-INTERACTIVE`` in the main gentoo repository as there will
160			be no internal default in portage.
161	g2boojum	1.1
162			References
163			==========
164
165			.. [1] Gentoo Linux Bug 17367
166			(http://bugs.gentoo.org/show_bug.cgi?id=17367)
167			.. [2] Gentoo Linux Bug 34146
168			(http://bugs.gentoo.org/show_bug.cgi?id=34146)
169
170
171			Copyright
172			=========
173
174			This document has been placed in the public domain.
175