| 1 | GLEP: 23 |
1 | GLEP: 23 |
| 2 | Title: Portage handling of ACCEPT_LICENSE |
2 | Title: Handling of ACCEPT_LICENSE |
| 3 | Version: $Revision: 1.1 $ |
3 | Version: $Revision: 1.5 $ |
| 4 | Last-Modified: $Date: 2004/03/08 17:26:04 $ |
4 | Last-Modified: $Date: 2006/11/19 22:46:27 $ |
| 5 | Author: Jason Stubbs <jstubbs@gentoo.org>, |
5 | Author: Jason Stubbs <jstubbs@gentoo.org>, Marius Mauch <genone@gentoo.org> |
| 6 | Status: Draft |
6 | Status: Accepted |
| 7 | Type: Standards Track |
7 | Type: Standards Track |
| 8 | Content-Type: text/x-rst |
8 | Content-Type: text/x-rst |
| 9 | Created: 9-Mar-2004 |
9 | Created: 9-Mar-2004 |
| 10 | Post-History: 8-Mar-2004 |
10 | Post-History: 8-Mar-2004 10-Mar-2004 25-Oct-2004 18-Nov-2006 19-Nov-2006 |
| 11 | |
11 | |
| 12 | |
12 | |
| 13 | Abstract |
13 | Abstract |
| 14 | ======== |
14 | ======== |
| 15 | |
15 | |
| 16 | Currently, every ebuild in the portage tree is required to have a valid |
16 | Currently, every ebuild in the main gentoo repository is required to have a |
| 17 | LICENSE entry. However, the syntax of this entry is not officially |
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 |
18 | defined and the entry itself is only used when outputting package |
| 19 | details. |
19 | details. |
| 20 | |
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. |
| 21 | |
27 | |
| 22 | Motivation |
28 | Motivation |
| 23 | ========== |
29 | ========== |
| 24 | |
30 | |
| 25 | Many users wish to regulate the software they install with regards to |
31 | Many users wish to regulate the software they install with regards to |
| … | |
… | |
| 55 | functionality offered by a DEPEND string. To keep things simple, this |
61 | functionality offered by a DEPEND string. To keep things simple, this |
| 56 | GLEP proposes that the syntax be identical. For example: |
62 | GLEP proposes that the syntax be identical. For example: |
| 57 | |
63 | |
| 58 | :: |
64 | :: |
| 59 | |
65 | |
| 60 | LICENSE="mandatory-license \ |
66 | LICENSE="mandatory-license |
| 61 | ( || choosable-licence1 chooseable-license-2 ) \ |
67 | || ( choosable-licence1 chooseable-license-2 ) |
| 62 | useflag? ( optional-component-license )" |
68 | useflag? ( optional-component-license )" |
| 63 | |
69 | |
|
|
70 | |
|
|
71 | License names may contain [a-zA-Z0-9] (english alphanumeric characters), |
|
|
72 | _ (underscore), - (dash), . (dot) and + (plus sign). |
| 64 | |
73 | |
| 65 | License Groups |
74 | License Groups |
| 66 | -------------- |
75 | -------------- |
| 67 | |
76 | |
| 68 | Almost all users are willing to install any software that is |
77 | Almost all users are willing to install any software that is |
| 69 | OSI-approved. Other users are willing to install any software and |
78 | FSF-approved. Other users are willing to install any software and |
| 70 | implicitly accept its license. To this end, portage will also need to |
79 | implicitly accept its license. To this end, implementations will also |
| 71 | handle grouping of licenses. |
80 | need to handle grouping of licenses. |
| 72 | |
81 | |
| 73 | At a minimum, there needs to be the groups ``OSI-APPROVED`` and |
82 | At a minimum, there needs to be the groups ``GPL-COMPATIBLE``, |
| 74 | ``NON-INTERACTIVE``. ``NON-INTERACTIVE`` licenses are those that don't |
83 | ``FSF-APPROVED``, ``OSI-APPROVED`` and ``NON-INTERACTIVE``. |
| 75 | require interactive acceptance for it to be considered legally binding. |
84 | ``NON-INTERACTIVE`` licenses are those that don't require interactive |
| 76 | This is the current behaviour of portage. |
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. |
| 77 | |
108 | |
| 78 | |
109 | |
| 79 | ACCEPT_LICENSE |
110 | ACCEPT_LICENSE |
| 80 | -------------- |
111 | -------------- |
| 81 | |
112 | |
| … | |
… | |
| 92 | This GLEP proposes that the license group be prepended by the special |
123 | This GLEP proposes that the license group be prepended by the special |
| 93 | character "``@``". For example: |
124 | character "``@``". For example: |
| 94 | |
125 | |
| 95 | :: |
126 | :: |
| 96 | |
127 | |
| 97 | ACCEPT_LICENSE="-* @OSI-APPROVED" |
128 | ACCEPT_LICENSE="-* @FSF-APPROVED" |
| 98 | |
129 | |
|
|
130 | License groups may be negated with the result that all elements of that group |
|
|
131 | are also negated. |
| 99 | |
132 | |
| 100 | Emerge Behaviour |
133 | Portage will also offer a package.license facility to offer this functionality |
| 101 | ---------------- |
134 | on a per-package base (analog to package.keywords), other implementations may |
|
|
135 | implement such a facility differently or not at all. |
| 102 | |
136 | |
| 103 | At a minimum, emerge must handle unaccepted licenses the same way that |
137 | Behaviour |
| 104 | it handles blockers. That is, with the --pretend flag the |
138 | --------- |
| 105 | not-yet-accepted license should be listed in the output. Without the |
|
|
| 106 | --pretend flag, emerge should stop before any software is installed. |
|
|
| 107 | |
139 | |
| 108 | This GLEP proposes that, unlike blockers, dependencies for software |
140 | Unaccepted licenses will be treated like any other masked package, that is |
| 109 | should be checked regardless of license acceptance. Doing so will allow |
141 | the user interface of an implementation will display a message listing any |
| 110 | the user to review all necessary licenses before initiating an actual |
142 | license that has to be accepted before the package can be merged with a |
| 111 | emerge. |
143 | pointer to the exact license text. |
| 112 | |
144 | |
| 113 | It is also proposed that the --ask option will display an unaccepted |
145 | Past versions of this document proposed to handle license-masked packages |
| 114 | license and ask for acceptance, but not update any configuration files |
146 | like blockers, but this would be inconsistent with other visibility |
| 115 | at this stage. Finally, the --verbose option should also list the |
147 | filters as well as the current blocker system (as a blocker affects two |
| 116 | licenses accepted for each package. |
148 | packages) and be more complicated to implement. |
| 117 | |
|
|
| 118 | |
149 | |
| 119 | Rationale |
150 | Rationale |
| 120 | ========= |
151 | ========= |
| 121 | |
152 | |
| 122 | An implementation of this proposal should make it easy for users wishing |
153 | An implementation of this proposal should make it easy for users wishing |
| … | |
… | |
| 124 | |
155 | |
| 125 | |
156 | |
| 126 | Reference Implementation |
157 | Reference Implementation |
| 127 | ======================== |
158 | ======================== |
| 128 | |
159 | |
| 129 | TODO |
160 | Available in portage svn repository under main/branches/license-masking |
| 130 | |
161 | |
| 131 | |
162 | |
| 132 | Backwards Compatibility |
163 | Backwards Compatibility |
| 133 | ======================= |
164 | ======================= |
| 134 | |
165 | |
| 135 | There should be no change to the user experience without the user |
166 | There should be no change to the user experience without the user |
| 136 | explicitly choosing to do so. This mandates that the |
167 | explicitly choosing to do so. This mandates that the |
| 137 | configuration variable be named ``ACCEPT_LICENSE`` as some users may |
168 | configuration variable be named ``ACCEPT_LICENSE`` as some users may |
| 138 | already have it set due to ebuilds using ``eutil.eclass``'s |
169 | already have it set due to ebuilds using ``eutil.eclass``'s |
| 139 | implementation. It also mandates that the default ``ACCEPT_LICENSE`` be |
170 | implementation. It also mandates that the default ``ACCEPT_LICENSE`` be |
| 140 | set to ``@NON-INTERACTIVE``. |
171 | set to ``@NON-INTERACTIVE`` in the main gentoo repository as implementations |
| 141 | |
172 | are not required to provide an internal default. |
| 142 | |
173 | |
| 143 | References |
174 | References |
| 144 | ========== |
175 | ========== |
| 145 | |
176 | |
| 146 | .. [1] Gentoo Linux Bug 17367 |
177 | .. [1] Gentoo Linux Bug 17367 |