License Review Process
If you find a license that covers part of a Fedora package, a proposed Fedora package, or some other Fedora Project artifact, that is not listed in the allowed or not-allowed license lists, please submit the license for review.
Licenses are classified as allowed, allowed for certain types of
material, or not allowed for inclusion in Fedora as discussed in
License Approval. Fedora has adopted the
use of SPDX expressions along with the SPDX matching guidelines as a
standard system for representing and classifying licenses (regardless
of whether a license is referenced in a spec file
field). In most cases where a license is classified as allowed, Fedora
prefers to use standard SPDX license identifiers (contained in the
SPDX License List) rather than custom-defined identifiers.
The license review process typically involves these three steps:
Open a fedora-license-data issue for review of a license
Open an SPDX license-list-XML issue (usually to request addition of an identifier for the license to the SPDX License List)
Once Fedora has decided how to classify the license, open a merge request to add a TOML file for the license at fedora-license-data.
The first step is typically initiated by the Fedora package maintainer, although any Fedora contributor is encouraged to request review of a license. We prefer that the person who initiates the first step also takes responsibility for the second and third steps, as this reduces the burden on the Fedora License Data maintainers and makes the license review process more efficient.
To request review of a license, you must be a Fedora contributor and become part of the Fedora Gitlab group.
Open a new issue for Fedora License Data using the license review issue template. You should ordinarily create one issue per license, rather than submit an issue referencing multiple licenses for review.
If you need general help with identifying the licenses that apply
to an entire package, we encourage you to submit an issue for this
purpose. We will apply the
Title the issue
License Review: <identifying name>. (The license
template function in Gitlab does not provide for an automatic issue
title.) The "identifying name" should be an SPDX identifier (if
applicable and known), an official or commonly applied license name,
or a placeholder name that you propose for the license. The vast
majority of license review issues use a placeholder name. This is
usually not the identifier that ends up being used to represent the
license in Fedora License Data.
The license review issue template will ask you to provide the following information:
License name (required) — you can use the "identifying name" that you used in the issue title, or "None" if you prefer
Text of license (required) — you can provide a link to the license text, include the text in the issue itself (particularly if it is relatively brief), or include the text in a comment after creating the issue
Fedora package name and link to upstream source code of the package (required)
Is the license (or an exception, if your issue is requesting review of a
WITHexpression) on the SPDX License List? (required) — if yes, then include the applicable SPDX license expression
Reason for the license review (optional) — for example, a link to the Bugzilla ticket for the package review
All discussion related to the license review will occur in the issue thread and an official decision, based on application of the Fedora license approval criteria, will be noted there. A decision may sometimes be noted solely by application of an appropriate scoped label referring to the license classification.
The SPDX License List has an established set of guidelines that define what constitutes a match to a license or exception on the SPDX License List. This is intended to ensure that SPDX license identifiers and expressions mean the same thing wherever they are used.
Many licenses that look similar to the naked eye may have small yet substantive differences. The following tools can help with detecting and matching license texts to identifiers on the SPDX License List:
These tools (and some other license detection tools) are described in the License Audit Tools page in this documentation.
If the Fedora License Data maintainers conclude that the license is
allowed, and they apply the
SPDX::submit issue label, then the next
step is to
an issue for the SPDX License List repository. In most cases, the
purpose of the issue is to request addition of a new license
identifier representing the license in the SPDX License List.
|If the license does not seem to match an identifier already on the SPDX License List, you do not have to wait for a Fedora License Data decision on the license before opening an SPDX issue. Usually, however, an SPDX issue is not opened until the Fedora License Data maintainers have decided to allow the license.|
|Please use the same identifying name in the SPDX issue submission that you used in the Fedora License Data issue title, as this makes it easier to see whether something needs attention in both places.|
In addition to the required information, add a comment referencing the related Fedora License Data issue. If there has already been a Fedora decision regarding the license please note that as well.
In some cases, the license you’ve found may not match an SPDX identifier in the sense meant in the SPDX matching guidelines, but it will be sufficiently close that the SPDX legal team may be persuaded to accommodate your variant by revising the XML file containing the SPDX specification for the identifier in question. The Fedora License Data maintainers may instruct you to create an SPDX License List issue for this purpose.
If SPDX-legal approves the license for inclusion as an identifier on the SPDX License List, please help create the files for your submission in accordance with the SPDX license list process.
If you’ve submitted an SPDX License List issue before there is a decision on the Fedora side, and the Fedora License Data maintainers later decide that the license is not-allowed for Fedora, you should offer to close the SPDX License List issue if it is still pending.
Once (1) Fedora has made a decision to allow or not allow the license, and (2) (if applicable) the SPDX License List process is also complete, create a merge request to add a new TOML file for the license using the TOML file format according the determined status (allowed, not-allowed, allowed-fonts, allowed-documentation, allowed-content, allowed-firmware).
The TOML file corresponding to a given license contains an
expression key whose value must be a valid SPDX expression, and the
name of the TOML file incorporates this SPDX expression (for example,
the expression value in the MIT.toml file is "MIT").
What SPDX expression to use for a new Fedora License Data TOML file depends on the Fedora classification of the license as well as how (if at all) the license has been dealt with by SPDX. There are three typical cases:
If your license already matches an identifier on the SPDX License List (i.e., it was not necessary to create an SPDX License List issue), use that identifier as the expression in the new TOML file.
If an SPDX License List issue was created, SPDX has decided to add your license as an identifier to the SPDX License List, and a pull request for your license submission has been merged in the SPDX License List repository, use this new SPDX identifier as the expression in the new TOML file.
If Fedora has decided that the license is not-allowed, and the license does not match an identifier on the SPDX License List, use the SPDX
LicenseRef-construct to create a custom-defined identifier for the license and use that identifier as the expression in the new TOML file.
There are special cases where Fedora will use a Fedora-defined
LicenseRef- identifier to represent an allowed license. Some of the
reasons why this may occur include:
The license is believed to be unlikely to meet SPDX’s license inclusion guidelines, so the Fedora License Data maintainers have indicated that an SPDX issue should not be created. This is expected to be fairly uncommon but might be likely to occur for some allowed-content and allowed-firmware licenses.
An SPDX issue for an allowed license was created but SPDX ultimately decided not to add the license to the SPDX License List. This is expected to be very rare.
The license qualifies to be covered by the umbrella license identifiers
The license could be represented with a complex composite SPDX expression making use of an SPDX License List identifier, but it is simpler to represent it with a
LicenseRef-expression. These will generally be cases where there is also some benefit to the use of a
LicenseRef-to signal that something is problematic about the license, even though Fedora has decided to allow it. For a good example, see the TOML file for
LicenseRef-Baculaand the related issue.
The license was classified as "good" under the (pre-SPDX) Callaway system, but is believed to no longer be present in supported releases of Fedora.
If a license given a
LicenseRef- identifier is later identified as a
match to a license on the SPDX License List or added to the SPDX
License List, then the Fedora License Data repository should be updated by replacing the TOML file with a new TOML file using the SPDX identifier.
Note that in any case where a
LicenseRef- is used, it is necessary
to copy the text of the license in the TOML file as the value of the
Fedora package maintainers are responsible for regularly monitoring the upstream source code of their packages for any changes or additions to licenses. When a license changes upstream, or a new license is introduced, the following guidelines apply:
If the project adds material under a license that hasn’t yet been reviewed for inclusion in Fedora, then submit the new license for review following the process described above.
If the project adds material under a not-allowed license, then the package can no longer be included in Fedora Linux, unless you remove the material covered by the not-allowed license. FESCo has the authority to block upgrades of packages to versions with new licenses that are not allowed for Fedora.
If the new license is allowed by Fedora, update the appropriate spec file
License:field, unless there is some reason why the license does not have to be accounted for in the
Traditionally, Fedora package maintainers have been expected to announce upstream license changes that they become aware of on the Fedora devel list. This expectation was probably based on the assumption that any upstream license change would be a change to substantially all the code in the project, but this is not always the case.
If you are unsure about the status of a new license in a package, please ask on the Fedora legal list.
Want to help? Learn how to contribute to Fedora Docs ›