1 |
commit: b393fd4f412720d6d01664abdacc791211b643a3 |
2 |
Author: Ulrich Müller <ulm <AT> gentoo <DOT> org> |
3 |
AuthorDate: Tue May 3 10:47:31 2022 +0000 |
4 |
Commit: Ulrich Müller <ulm <AT> gentoo <DOT> org> |
5 |
CommitDate: Tue May 3 10:47:31 2022 +0000 |
6 |
URL: https://gitweb.gentoo.org/data/glep.git/commit/?id=b393fd4f |
7 |
|
8 |
glep-0023: Delete trailing whitespace |
9 |
|
10 |
Signed-off-by: Ulrich Müller <ulm <AT> gentoo.org> |
11 |
|
12 |
glep-0023.rst | 80 +++++++++++++++++++++++++++++------------------------------ |
13 |
1 file changed, 40 insertions(+), 40 deletions(-) |
14 |
|
15 |
diff --git a/glep-0023.rst b/glep-0023.rst |
16 |
index 9113464..e8df911 100644 |
17 |
--- a/glep-0023.rst |
18 |
+++ b/glep-0023.rst |
19 |
@@ -24,20 +24,20 @@ Abstract |
20 |
======== |
21 |
|
22 |
Currently, every ebuild in the main Gentoo repository is required to have a |
23 |
-valid LICENSE entry. However, the syntax of this entry is not officially |
24 |
-defined and the entry itself is only used when outputting package |
25 |
+valid LICENSE entry. However, the syntax of this entry is not officially |
26 |
+defined and the entry itself is only used when outputting package |
27 |
details. |
28 |
|
29 |
Motivation |
30 |
========== |
31 |
|
32 |
-Many users wish to regulate the software they install with regards to |
33 |
-licenses for various reasons [1]_. Some want a system free of any |
34 |
-software that is not OSI-approved; others are simply curious as to what |
35 |
+Many users wish to regulate the software they install with regards to |
36 |
+licenses for various reasons [1]_. Some want a system free of any |
37 |
+software that is not OSI-approved; others are simply curious as to what |
38 |
licenses they are implicitly accepting. |
39 |
|
40 |
-Furthermore, some software requires that a user interactively accept its |
41 |
-license for its author's to consider it legally binding. This is |
42 |
+Furthermore, some software requires that a user interactively accept its |
43 |
+license for its author's to consider it legally binding. This is |
44 |
currently implemented using ``eutils.eclass``. |
45 |
|
46 |
|
47 |
@@ -47,21 +47,21 @@ Specification |
48 |
Ebuild LICENSE Variable |
49 |
----------------------- |
50 |
|
51 |
-Most ebuilds are for software which is released under a single license. |
52 |
-In these cases, the current LICENSE variable can remain as is. For |
53 |
+Most ebuilds are for software which is released under a single license. |
54 |
+In these cases, the current LICENSE variable can remain as is. For |
55 |
example: |
56 |
|
57 |
:: |
58 |
|
59 |
LICENSE="single-license" |
60 |
|
61 |
-However, there are several ebuilds for software which is released under |
62 |
-several licenses, of which the user must accept one, some or all [2]_. |
63 |
-To complicate this, some ebuilds include optional components which fall |
64 |
+However, there are several ebuilds for software which is released under |
65 |
+several licenses, of which the user must accept one, some or all [2]_. |
66 |
+To complicate this, some ebuilds include optional components which fall |
67 |
under a different license. |
68 |
|
69 |
To accommodate these cases, LICENSE syntax should accommodate all |
70 |
-functionality offered by a DEPEND string. To keep things simple, this |
71 |
+functionality offered by a DEPEND string. To keep things simple, this |
72 |
GLEP proposes that the syntax be identical. For example: |
73 |
|
74 |
:: |
75 |
@@ -78,34 +78,34 @@ begin with a hyphen, a dot or a plus sign. |
76 |
License Groups |
77 |
-------------- |
78 |
|
79 |
-Almost all users are willing to install any software that is |
80 |
-FSF-approved. Other users are willing to install any software and |
81 |
-implicitly accept its license. To this end, implementations will also |
82 |
+Almost all users are willing to install any software that is |
83 |
+FSF-approved. Other users are willing to install any software and |
84 |
+implicitly accept its license. To this end, implementations will also |
85 |
need to handle grouping of licenses. |
86 |
|
87 |
-At a minimum, there needs to be the groups ``GPL-COMPATIBLE``, |
88 |
-``FSF-APPROVED``, ``OSI-APPROVED`` and ``NON-MUST-HAVE-READ``. |
89 |
-``NON-MUST-HAVE-READ`` licenses are those that don't require manual |
90 |
-acceptance for to be considered legally binding. This is the current |
91 |
+At a minimum, there needs to be the groups ``GPL-COMPATIBLE``, |
92 |
+``FSF-APPROVED``, ``OSI-APPROVED`` and ``NON-MUST-HAVE-READ``. |
93 |
+``NON-MUST-HAVE-READ`` licenses are those that don't require manual |
94 |
+acceptance for to be considered legally binding. This is the current |
95 |
behaviour of portage. |
96 |
|
97 |
-These groups are defined in a new file ``license_groups`` in |
98 |
+These groups are defined in a new file ``license_groups`` in |
99 |
the ``profiles`` subdirectory of the tree (or overlays). |
100 |
Details of handling groups defined in overlays is implementation dependent. |
101 |
|
102 |
The format of this file is |
103 |
|
104 |
:: |
105 |
- |
106 |
+ |
107 |
<groupname> <license1> <license2> ... <licenseN> |
108 |
|
109 |
Also any line starting with # is ignored and may be used for comments. |
110 |
-Group names use the same syntax as normal license names. Also license groups |
111 |
+Group names use the same syntax as normal license names. Also license groups |
112 |
may contain other groups. |
113 |
License groups may not contain negated elements, so a group |
114 |
|
115 |
:: |
116 |
- |
117 |
+ |
118 |
mygroup foo -bar -bla |
119 |
|
120 |
is illegal. |
121 |
@@ -114,17 +114,17 @@ is illegal. |
122 |
ACCEPT_LICENSE |
123 |
-------------- |
124 |
|
125 |
-This GLEP proposes that a user be able to explicitly accept or decline |
126 |
-licenses by editing a new variable ``ACCEPT_LICENSE`` in |
127 |
-``/etc/make.conf``. Again, to keep things simple, the syntax should be |
128 |
+This GLEP proposes that a user be able to explicitly accept or decline |
129 |
+licenses by editing a new variable ``ACCEPT_LICENSE`` in |
130 |
+``/etc/make.conf``. Again, to keep things simple, the syntax should be |
131 |
similar to that of other incrementals. For example: |
132 |
|
133 |
:: |
134 |
|
135 |
ACCEPT_LICENSE="-* accepted-license -declined-license" |
136 |
|
137 |
-As an extension, ``ACCEPT_LICENSE`` must also support `license groups`_. |
138 |
-This GLEP proposes that the license group be prepended by the special |
139 |
+As an extension, ``ACCEPT_LICENSE`` must also support `license groups`_. |
140 |
+This GLEP proposes that the license group be prepended by the special |
141 |
character "``@``". For example: |
142 |
|
143 |
:: |
144 |
@@ -142,19 +142,19 @@ Behaviour |
145 |
--------- |
146 |
|
147 |
Unaccepted licenses will be treated like any other masked package, that is |
148 |
-the user interface of an implementation will display a message listing any |
149 |
-license that has to be accepted before the package can be merged with a |
150 |
+the user interface of an implementation will display a message listing any |
151 |
+license that has to be accepted before the package can be merged with a |
152 |
pointer to the exact license text. |
153 |
|
154 |
Past versions of this document proposed to handle license-masked packages |
155 |
-like blockers, but this would be inconsistent with other visibility |
156 |
-filters as well as the current blocker system (as a blocker affects two |
157 |
+like blockers, but this would be inconsistent with other visibility |
158 |
+filters as well as the current blocker system (as a blocker affects two |
159 |
packages) and be more complicated to implement. |
160 |
|
161 |
Rationale |
162 |
========= |
163 |
|
164 |
-An implementation of this proposal should make it easy for users wishing |
165 |
+An implementation of this proposal should make it easy for users wishing |
166 |
to regulate their software without affecting those that don't. |
167 |
|
168 |
|
169 |
@@ -167,11 +167,11 @@ Available in portage svn repository under main/branches/license-masking |
170 |
Backwards Compatibility |
171 |
======================= |
172 |
|
173 |
-There should be no change to the user experience without the user |
174 |
-explicitly choosing to do so. This mandates that the |
175 |
-configuration variable be named ``ACCEPT_LICENSE`` as some users may |
176 |
-already have it set due to ebuilds using ``eutils.eclass``'s |
177 |
-implementation. It also mandates that the default ``ACCEPT_LICENSE`` be |
178 |
+There should be no change to the user experience without the user |
179 |
+explicitly choosing to do so. This mandates that the |
180 |
+configuration variable be named ``ACCEPT_LICENSE`` as some users may |
181 |
+already have it set due to ebuilds using ``eutils.eclass``'s |
182 |
+implementation. It also mandates that the default ``ACCEPT_LICENSE`` be |
183 |
set to ``@NON-MUST-HAVE-READ`` in the main Gentoo repository as implementations |
184 |
are not required to provide an internal default. |
185 |
|
186 |
@@ -180,7 +180,7 @@ References |
187 |
|
188 |
.. [1] Gentoo Linux Bug 17367 |
189 |
(http://bugs.gentoo.org/show_bug.cgi?id=17367) |
190 |
-.. [2] Gentoo Linux Bug 34146 |
191 |
+.. [2] Gentoo Linux Bug 34146 |
192 |
(http://bugs.gentoo.org/show_bug.cgi?id=34146) |