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.
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:
Apache-2.0 WITH LLVM-exception(status: allowed; example of
CC0-1.0(status: allowed-content, and has a
LicenseRef-Fedora-Public-Domain(status: allowed; Fedora-defined umbrella identifier)
LicenseRef-sun-rpc(status: not-allowed; Fedora-defined identifier)
We say that a license is "Fedora-acceptable" in the context of a specific package if it is:
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
usageexception defined in the Fedora License Data TOML file for that license.
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.
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
operators. We say that such a license expression is itself
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:
This license expression is Fedora-acceptable, since
MIT is allowed.
Now let’s look at a more complex example:
plasmatube contains executable code
compiled from source code covered mostly by
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-2.0-or-later are allowed; and (2)
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
The executable file and the man page that make up the
RPM are transformations of files in the
xmodmap source code that are
MIT-open-group. However, the source tarball in
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,
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-open-group are allowed.
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).
In the License: tag for the
GPL-2.0-or-later should not be
omitted even though it can be argued that the "effective" license of the
plasmatube executable is
xmodmap package, you might be able to come up with an
argument for why you can regard one or the other of
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.
A license should normally appear only once in the License: tag license
expression. But if the license expression includes an
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
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
The source code of the package
python-pyqt6-sip is disjunctively
triple-licensed under the choice of
and the not-allowed license
LicenseRef-Riverbank-SIP. The License:
License: GPL-2.0-only OR GPL-3.0-only
It should not be
License: GPL-2.0-only, or
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.
Perl 5 is released under a dual license that can be represented in
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
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 Artistic-1.0-Perl
To facilitate this option, Fedora License Data includes a TOML file
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.
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.
Want to help? Learn how to contribute to Fedora Docs ›