1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
|
<?xml version="1.0" encoding="UTF-8"?>
<guide self="general-concepts/licenses/">
<chapter>
<title>Licenses</title>
<body>
<p>
All ebuilds must specify a <c>LICENSE</c> (note the American English
spelling) variable. The license names listed in this variable must
match files existing in the repository's <c>licenses/</c> directory.
</p>
<p>
The value of this variable should include all licenses pertaining to the
"corresponding source" of the files installed by the package. This includes
all their source code, but also all scripts used to control compilation and
installation.
</p>
<p>
If some parts of the package are installed only conditionally, or their
license depends on the USE flag combination, you can use USE conditionals
in <c>LICENSE</c>:
</p>
<codesample lang="ebuild">
LICENSE="LGPL-2.1+ tools? ( GPL-2+ )"
</codesample>
<p>
If the package sources include additional files that are neither installed
nor used at build time, their license should not be listed.
</p>
<p>
If the application is multi-license (either of several licenses can
be used) then use the following syntax:
</p>
<codesample lang="ebuild">
LICENSE="|| ( foo bar )"
</codesample>
</body>
<section>
<title>License-implied restrictions</title>
<body>
<p>
Non-free licenses may impose additional restrictions that need to be stated
in the ebuild. In order to identify such restrictions correctly, it is necessary
to analyze relevant license(s) and determine applicable clauses based
on the files contained in upstream packages. Note that upstreams may use
the same license for multiple products, with some restrictions not being
applicable to the ebuild in question.
</p>
<p>
If the license of a package does not explicitly permit redistributing distfiles
found in <c>SRC_URI</c>, the corresponding ebuilds must have
<c>RESTRICT=mirror</c> to prevent the affected files from being copied to Gentoo
mirrors. In some cases, the license permits redistributing unmodified original
archives only <d/> in that case, <c>SRC_URI</c> must not contain modified
or repackaged upstream archives, and all changes must be applied via patching
in appropriate ebuild phases.
</p>
<p>
If the license does not permit distributing Gentoo binary packages built using
the ebuild, with or without source modifications, it must have
<c>RESTRICT=bindist</c>. This is also the case if restrictions are set based
on the cost of redistribution (e.g. the license prohibits selling the product).
</p>
<p>
Some EULAs may also require the user to fetch distfiles manually, in which case
<c>RESTRICT=fetch</c> is necessary. Note that <c>RESTRICT=fetch</c> implies
<c>RESTRICT=mirror</c>.
</p>
</body>
</section>
<section>
<title>Determining the correct license</title>
<body>
<warning>
Do not trust the license indicated by GitHub or other sites that use automation
to guess the license! The information presented may be incomplete and/or
incorrect. The
<uri link="https://developer.github.com/v3/licenses/#get-the-contents-of-a-repositorys-license">
GitHub License API</uri> for example can only return a single license for a
given repository.
</warning>
<p>
To establish the correct value of <c>LICENSE</c>, you need to trace
the licenses of all installed files. Normally, the licenses of output
files (compiled executables, generated files) are implied
by the licenses of the relevant input files.
</p>
<p>
When looking for license information, the following should be
considered:
</p>
<ol>
<li>
<c>COPYING*</c> and <c>LICENSE*</c> files distributed with
the package
</li>
<li>
explicit statements in documentation
</li>
<li>
explicit license notices in source and data files
</li>
</ol>
<p>
The latter (more specific) options take precedence over the former.
In particular, <c>COPYING*</c> files are frequently included as hardcopies
of applicable licenses but the exact application of licenses and their
versions are specified elsewhere.
</p>
<p>
If the package does not indicate any license, then you should contact
the author for clarification. Adding packages with no explicit license
statement is strongly discouraged. If they are present already, they
ought to have <c>all-rights-reserved</c> license,
and <c>RESTRICT="bindist mirror"</c>.
</p>
</body>
</section>
<section>
<title>Detecting upstream license problems</title>
<body>
<p>
Please watch out for upstream licensing problems and report them
upstream.
You may ask the Gentoo licenses team for guidance. In general, it is
preferable to wait for upstream to resolve the issue and release a new
version. Do not add packages that seem to include license term
violations!
</p>
<p>
Common license problems include but are not limited to:
</p>
<ol>
<li>
<p>
Including third party code without appropriate copyright notices.
Practically all licenses (with notable exception of public
domain-alike) require attribution, and some require copying
original copyright notices verbatim.
</p>
</li>
<li>
<p>
Combining incompatible licenses. When you are combining multiple
files using different licenses into a single executable, those
licenses need to be compatible. For example, it is not possible
to combine proprietary code with copyleft licenses (e.g. GPL).
It is also incorrect to combine GPL-2 (only) and GPL-3 code.
</p>
</li>
<li>
<p>
Dynamically linking incompatible executables. Arguably, some
licenses also apply restriction on dynamic linking between
executables and shared libraries. For example, normally you can't
link GPL executables with OpenSSL. The same restriction does not
apply to LGPL, and some projects are adding specific linking
exceptions to their GPL usage.
</p>
</li>
<li>
<p>
Wrong or incomplete license information about a project. Upstream
may indicate the wrong effective license for a project (e.g.
in README. For example, upstream may indicate that the project
is licensed as GPL-2+ while some of the source code files use
GPL-3+ license.
</p>
</li>
</ol>
</body>
</section>
<section>
<title>GPL-x vs GPL-x+</title>
<body>
<p>
FSF licenses (GPL, LGPL, AGPL, FDL) occur in two variants: the 'vN only'
and 'vN or later' variants. In Gentoo, the licenses of the latter variants
are denoted by appending
a plus sign (+) to their respective license notations of the former variant,
e.g. <c>GPL-2+</c> and <c>GPL-2</c>.
</p>
<p>
Determining the correct variant usually requires looking for copyright
notices in the code. For example, the following copyright notice
indicates <c>GPL-2+</c> license:
</p>
<pre>
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
</pre>
</body>
</section>
<section>
<title>Adding New Licenses</title>
<body>
<p>
If your package's license is not already in the tree, you must add the
license before committing the package. When adding the license, use a
plain text file (UTF-8 encoded) if at all possible. Some licenses are
PDF files rather than plain text <d/> this should only be done if we
are legally required to do so.
Finally you need to check if your license should be added to a license group
as listed in $PORTDIR/profiles/license_groups. For more information see the
<uri link="https://www.gentoo.org/glep/glep-0023.html">GLEP 23</uri>.
</p>
<p>
It is not normally necessary to mail the <c>gentoo-dev</c> list or
<c>licenses@gentoo.org</c> before adding a new license. You should
only do so if the license could be considered 'questionable' or if
you are unsure as to the meaning of any part of it.
</p>
<p>
When adding a new license, it should be checked whether there is an established
name in the <uri link="https://spdx.org/licenses/">SPDX license list</uri>.
However, Gentoo does not consider the Software Package Data Exchange to be an
authoritative standard, so we may sometimes deviate from it, e.g., if their
"short identifier" is excessively long. Also, we generally don't rename our
existing identifiers.
</p>
</body>
</section>
<section>
<title>Further reading</title>
<body>
<p>
The following resources are recommended as source of more information
on copyright and licensing:
</p>
<ul>
<li>
<uri link="https://dwheeler.com/essays/floss-license-slide.html">
David A. Wheeler, The Free-Libre / Open Source Software (FLOSS)
License Slide
</uri>
</li>
<li>
<uri link="https://www.gnu.org/licenses/license-compatibility.en.html">
Richard Stallman, License Compatibility and Relicensing
</uri>
</li>
</ul>
</body>
</section>
</chapter>
</guide>
|
GitWeb