Licenses

All ebuilds must specify a LICENSE (note the American English spelling) variable. The license names listed in this variable must match files existing in the repository's licenses/ directory.

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. If the package has a "main license" — i.e. a license covering most of its files — then this should be listed first.

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 LICENSE:

LICENSE="LGPL-2.1+ tools? ( GPL-2+ )"

If the package sources include additional files that are neither installed nor used at build time, their license should not be listed.

If the application is multi-license (either of several licenses can be used) then use the following syntax:

LICENSE="|| ( foo bar )"

License-implied restrictions

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.

If the license of a package does not explicitly permit redistributing distfiles found in SRC_URI, the corresponding ebuilds must have RESTRICT=mirror to prevent the affected files from being copied to Gentoo mirrors. In some cases, the license permits redistributing unmodified original archives only — in that case, SRC_URI must not contain modified or repackaged upstream archives, and all changes must be applied via patching in appropriate ebuild phases.

If the license does not permit distributing Gentoo binary packages built using the ebuild, with or without source modifications, it must have RESTRICT=bindist. This is also the case if restrictions are set based on the cost of redistribution (e.g. the license prohibits selling the product).

Some EULAs may also require the user to fetch distfiles manually, in which case RESTRICT=fetch is necessary. Note that RESTRICT=fetch implies RESTRICT=mirror.

Determining the correct license

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 GitHub License API for example can only return a single license for a given repository.

To establish the correct value of LICENSE, 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.

When looking for license information, the following should be considered:

COPYING* and LICENSE* files distributed with the package
explicit statements in documentation
explicit license notices in source and data files

The latter (more specific) options take precedence over the former. In particular, COPYING* files are frequently included as hardcopies of applicable licenses but the exact application of licenses and their versions are specified elsewhere.

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 all-rights-reserved license, and RESTRICT="bindist mirror".

Detecting upstream license problems

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!

Common license problems include but are not limited to:

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.
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.
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.
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.

GPL-x vs GPL-x+

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. GPL-2+ and GPL-2.

Determining the correct variant usually requires looking for copyright notices in the code. For example, the following copyright notice indicates GPL-2+ license:

 * 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.

Adding new licenses

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), because non-text files do not belong in the repository. Finally you need to check if your license should be added to a license group as listed in the repository's profiles/license_groups file. For more information see GLEP 23.

It is not normally necessary to mail the gentoo-dev list or [email protected] 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.

When adding a new license, it should be checked whether there is an established name in the SPDX license list. 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.