Spec File License: Tags

The Fedora convention is that License: tags describe a relevant subset of the licenses that apply to the source code of the package. Any license that applies to anything in the source code must be Fedora-acceptable (assuming you actually need a license for that material), even if it is ultimately not included in the License: tag.

Therefore, before you can figure out how to populate the License: tag for a package, you first need to analyze the source code of the package to determine what licenses apply to that source code. If you encounter any licenses that do not seem to map to what is already in Fedora License Data, those licenses must be reviewed for allowability in Fedora based on Fedora’s license approval criteria.

The License: tag in the spec file Preamble must be populated with an SPDX license expression that consists of a Fedora-acceptable license, or multiple Fedora-acceptable licenses joined by AND and/or OR operators. We say that such a license expression is itself Fedora-acceptable.

Unless your package includes multiple binary subpackages and you opt to specify subpackage-specific License: tags, the Preamble License: tag expression should be an enumeration of all licenses found in the source code of the package, but excluding any licenses that cover material in the source code that is not copied into the binary RPM(s), either verbatim or transformed in some way (for example, by compilation).

Let’s consider a simple example:

Now let’s look at a more complex example:

Licenses that cover files in the source code that are not copied into the binary RPM should be excluded from the License: tag. Consider the package xmodmap:

Except to the extent these guidelines state otherwise, you should not attempt to simplify or reduce the License: tag license expression (for example, based on a theory of GPL copyleft interpretation, sublicensing, or license compatibility, or based on some sort of algebraic transformation).

Examples:

A license should normally appear only once in the License: tag license expression. But if the license expression includes an OR sub-expression, that OR sub-expression is treated as though it were a single license for purposes of this rule. As an exception to this rule, if all the license operands of the OR sub-expression also appear in the license expression outside the OR sub-expression, then you can eliminate the OR sub-expression.

All the license operands of an OR expression should be preserved, but only to the extent that those license operands are allowed. A license operand in an OR expression that is not allowed should normally be excluded from the License: tag license expression, which in some cases will mean that the OR expression is replaced with a single license.

Example:

Perl 5 is released under a dual license that can be represented in SPDX as GPL-1.0-or-later OR Artistic-1.0-Perl. Many Perl modules say simply that they are licensed under "the same terms as Perl itself". Fedora treats this as an unambiguous reference to that well-known Perl dual license.

Artistic-1.0-Perl is not-allowed. Normally this would mean that packages that are under the Perl dual license should include only GPL-1.0-or-later in the License: tag rather than the whole OR expression. However, Fedora has accommodated preferences expressed by Fedora Perl package maintainers and upstream Perl module maintainers by permitting packages under the Perl dual license to use either

GPL-1.0-or-later

or

GPL-1.0-or-later OR Artistic-1.0-Perl

To facilitate this option, Fedora License Data includes a TOML file for GPL-1.0-or-later OR Artistic-1.0-Perl with the status allowed. There is a similar TOML file for the less common variant GPL-2.0-or-later OR Artistic-1.0-Perl.

Example:

Packages under the LaTeX Project Public License version 1.2 (LPPL-1.2) or any later version are allowed with the understanding that Fedora will treat such packages as being licensed under the LaTeX Project Public License version 1.3a or any later version. It is not necessary to include a copy of version 1.3a or to delete or replace copies of version 1.2, or to alter any notices referring to version 1.2. However, any License tag that refers to the LPPL in this situation should use LPPL-1.3a+, not LPPL-1.2 (or LPPL-1.2+).