License Review Process
If you find a license that covers all or 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, as explained below. Licenses are classified as allowed, allowed for certain types of material, or not allowed for inclusion in Fedora as discussed in License Approval.
To request review of a license, you must be a Fedora contributor and become part of the Fedora Gitlab group.
Create a new issue in 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.
The license review issue template will ask you to include 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 and based on the Fedora license approval criteria will be on the issue thread and a decision will be noted there. A decision may sometimes be noted solely by application of an appropriate scoped label referring to the license classification.
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 requesting inclusion of
the license text in the SPDX License List.
|If the license does not seem to match an identifier already on the SPDX License List, you can create an SPDX License List issue before the Fedora License Data maintainers reach a decision regarding whether the license is allowed for Fedora.|
|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).
Fedora uses SPDX expressions to represent allowed and not-allowed
licenses in the Fedora License Data repository and in the license
lists that are generated from it. This is why our review process
requires creation of a SPDX License List issue (in cases where the
license under review does not already match to an SPDX License List
identifier). More specifically, the Fedora License Data 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 GPL-2.0-or-later.toml file is "GPL-2.0-or-later").
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, u se 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 create a
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 will likely be the case for most allowed-firmware licenses, for example.
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 rare (and has not happened yet).
The license qualifies to be covered by the umbrella license identifiers
The license could possibly be represented using a complex composite SPDX expression making use of an SPDX 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 no longer found in 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 record the text of the license in the TOML file as the value of the
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.
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 ›