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 ofWITH
expression) -
CC0-1.0
(status: allowed-content, and has ausage
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).
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.
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".
License of build tools
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.
You MAY specify these licenses in SourceLicense
tag:
SourceLicense: MIT AND MIT-open-group AND FSFULLRWD AND GPL-2.0-or-later
WITH Autoconf-exception-generic
Short decision matrix
A file that is included in the final RPM package. Or that is compiled and the result is used in RPM:
The license should be included in the License
tag.
A file that uses not allowed license:
The file has to be removed from sources before uploading to dist-git or the package needs an exception from FESCO.
Build script or makefile that is not included in the binary RPM:
Does not affect the License tag. But the license of the file must be from the allowed list. You MAY list the license in SourceLicense
tag.
Test file or example that is not included in the binary RPM:
Does not affect the License tag. But the license of the file must be from the allowed list. You MAY list the license in SourceLicense
tag.
Test file or example that is included in the binary RPM:
The license MUST be included in the License
tag.
A file that is not used during build time. E.g. windows include, or support for architecture not used by Fedora:
Does not affect the License tag. But the license of the file must be from the allowed list. You MAY list the license in SourceLicense
tag.
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.
Exceptions
Several packages in Fedora may use a not-allowed license. This always has to be tracked as "usage exception". FESCO has the authority to grant exceptions. If a given package is covered by a "usage exception" allowing the use of an ordinarily not-allowed license, then the License tag rules apply as though it were allowed, If it’s included in some sense in the binary RPM, it should be reflected in the License tag; if it’s just in the source tarball, it shouldn’t be.
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.
LaTeX Project Public License
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+
).
Want to help? Learn how to contribute to Fedora Docs ›