aboutsummaryrefslogtreecommitdiff
blob: f1d5299d76cb6fc033375c2d0498652f5e667c39 (plain)
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
<?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. Please also note
that some licenses may impose additional restrictons, e.g. fetch
and/or mirroring restriction.
</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>

<subsection>
<title>Determining the correct license</title>
<body>

<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>
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>
</subsection>

<subsection>
<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>
</subsection>
</body>

</chapter>
</guide>