Spec File License: Tags

This page explains how to populate RPM spec file License: tags and is aimed mainly at Fedora Linux package maintainers. We assume that you are experienced in building packages for Fedora Linux, that you have some familiarity with open source licensing, and that you have carefully reviewed the documentation on SPDX license expressions and Fedora license approval. If you are dealing with a specific package, we assume you have already analyzed the licensing terms of the source code of the package and determined how those terms map to SPDX license expressions classified in the Fedora License Data repository.

Definitions used in this page

"License"

For convenience, except where context indicates otherwise, this page uses "license" narrowly to mean an SPDX license expression that corresponds to a TOML file in the Fedora License Data repository.

Here are some examples of "licenses" in this sense:

  • GPL-2.0-or-later (status: allowed)

  • Apache-2.0 WITH LLVM-exception (status: allowed; example of WITH expression)

  • CC0-1.0 (status: allowed-content, and has a usage exception)

  • LicenseRef-Fedora-Public-Domain (status: allowed; Fedora-defined umbrella identifier)

  • LicenseRef-sun-rpc (status: not-allowed; Fedora-defined identifier)

"Fedora-acceptable"

We say that a license is "Fedora-acceptable" in the context of a specific package if it is:

  • allowed,

  • allowed for a specific category of material (for example, allowed-content) and, in this package, it only covers that category, or

  • not-allowed, or not allowed for a specific category of material, but its use in this package falls within the usage exception defined in the Fedora License Data TOML file for that license.

Preliminary note

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.

While typically "the source code of the package" refers solely to what is contained in the SRPM of the package, in some situations it refers additionally to source code of other Fedora packages. This is discussed in the section on Bundling, vendoring, static linking, and related topics.

Basic rule

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:

The source code of the package wayland-utils is entirely under MIT. The License: tag is:

License: MIT

This license expression is Fedora-acceptable, since MIT is allowed.

Now let’s look at a more complex example:

The package plasmatube contains executable code compiled from source code covered mostly by GPL-3.0-or-later, though one compiled source file is under GPL-2.0-or-later. It also contains an appdata.xml file that says it is under CC0-1.0 (we’ll assume this file is copyrightable) and an SVG file that is under CC-BY-SA-4.0. The License: tag is:

License: GPL-3.0-or-later AND GPL-2.0-or-later AND CC0-1.0 AND CC-BY-SA-4.0

This license expression is Fedora-acceptable because: (1) GPL-3.0-or-later and GPL-2.0-or-later are allowed; and (2) CC0-1.0 and CC-BY-SA-4.0 are allowed-content, and appdata.xml files and SVG files are classified as "content".

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:

The executable file and the man page that make up the xmodmap binary RPM are transformations of files in the xmodmap source code that are covered by MIT and MIT-open-group. However, the source tarball in the xmodmap SRPM contains a number of Automake, Autoconf, and other build-related files that are covered in part by a variety of other licenses (namely, FSFULLRWD, FSFULLR, GPL-2.0-or-later WITH Autoconf-exception-generic, GPL-3.0-or-later WITH Autoconf-exception-macro, GPL-3.0-or-later WITH Autoconf-exception-generic-3.0, FSFUL, HPND-sell-variant, FSFAP, and LicenseRef-Fedora-Public-Domain). These licenses are all allowed, but since none of those files are copied into the binary RPM, the corresponding licenses should not be included in the License: tag. The License: tag is just:

License: MIT AND MIT-open-group

This license expression is Fedora-acceptable because MIT and MIT-open-group are allowed.

No "effective license" analysis

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:

In the License: tag for the plasmatube package, GPL-2.0-or-later should not be omitted even though it can be argued that the "effective" license of the plasmatube executable is GPL-3.0-or-later.

In the xmodmap package, you might be able to come up with an argument for why you can regard one or the other of MIT and MIT-open-group as the single license of the files in the binary RPM, though it is unclear how you would pick one of the two licenses in a non-arbitrary way. Nevertheless, the License: tag should include both.

Special rules for OR expressions

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:

The source code of the package python-pyqt6-sip is disjunctively triple-licensed under the choice of GPL-2.0-only, GPL-3.0-only, and the not-allowed license LicenseRef-Riverbank-SIP. The License: tag is:

License: GPL-2.0-only OR GPL-3.0-only

It should not be License: GPL-2.0-only, or License: GPL-3.0-only, because no choice should be made among a set of allowed licenses in an OR expression. It should not be License: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-Riverbank-SIP because a not-allowed license that is part of an OR expression should not be included in the License: tag.

Special rules for Perl packages

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:

The Perl module Archive::Tar, packaged in Fedora as perl-Archive-Tar, is licensed upstream "under the same terms as Perl itself". The License: tag is properly:

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

and this license expression is Fedora-acceptable, even though Artistic-1.0-Perl itself is not-allowed.

Subpackage-specific License: tags

Bundling, vendoring, static linking, and related topics