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
|
<?xml version="1.0"?>
<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 files installed by the package. 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 not installed,
their license should not be listed. However, if those files are used
at build time, then the license must not impose any restrictions that
could prevent users from building the software.
</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>
<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.
</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>
<p>
Please watch for license conflicts. If the license indicated
by the package is incompatible with the licenses used by its sources
(e.g. BSD/MIT package including GPL sources), please contact
the licenses team for guidance. Do not add packages that seem
to include license term violations.
</p>
</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>
</body>
</section>
</body>
</chapter>
</guide>
|
GitWeb