License Review Process

This page describes how to request the review of a license for inclusion in Fedora and other related processes.

Licenses are determined to be allowed, allowed for certain types of material, or not-allowed for inclusion in Fedora as described in License Approval.

Request review of a new license

If you find a license that is included in Fedora, and that license is not listed on the allowed or not-allowed license lists, please follow the process described below to submit the license for review.

You must be a Fedora contributor and become part of the Fedora Gitlab group.

  1. Create a new issue in Fedora License Data using the license-review issue template. Please create one issue per license. Do not submit an issue referencing multiple licenses for review.

    1. Title the issue License Review: <SPDX id, if exists or proposed abbreviation>. (The license template function in Gitlab does not provide for an automatic issue title.)

    2. The license-review issue template will prompt you to include the following information:

      • License name (required) — use same license id or abbreviation as in title, if there is no known license name.

      • Text of license (required) — provide a link to the license text, or, if that is not convenient, include the text in an issue comment.

      • Fedora package name and link to upstream source code of the package (required)

      • Is the license on the SPDX License List? (required) — if yes, then include the applicable SPDX license expression (see below for helpful information for determining whether a license is already on the SPDX License List)

      • Reason for the license review (optional) — for example, a link to the Bugzilla ticket for the package review

  2. All discussion related to the license review based on the Fedora license approval criteria will be on the issue thread and a decision will be noted there.

  3. If the license is not on the SPDX License List (or you are not sure), then submit the license to the SPDX-legal team following this process. In addition to the required information, add a comment that it is under review for Fedora and a link to the related Fedora License Data issue and whether or not the license is allowed for Fedora, if known.

    Please use the same abbreviation in the SPDX submission as you use in the Fedora Gitlab issue title, this makes it much easier to see where something needs attention in both places.
    1. If the license is approved for inclusion on the SPDX License List, please help create the files for your submission in according the SPDX license list process. You can safely start using the SPDX identifier once a pull request for your license submission has been created and merged in the SPDX License List repo

    2. If the license is ultimately determined to be not-allowed for Fedora, you should offer to withdraw the SPDX-legal request if it is still pending.

  4. Once Fedora has made a decision to allow or not allow the license, create a merge request to add the license to Fedora License Data using the TOML file format according the determined status (allowed, not-allowed, allowed-fonts, allowed-documentation, allowed-content, allowed-firmware).

    1. If the license is determined to be not-allowed for Fedora use the SPDX LicenseRef- format for the SPDX id, unless an SPDX license identifier is already available for that license. The license text for the not-allowed license must be captured in the TOML file, in accordance with the TOML template format. As noted above, if a license has been determined to be not-allowed, and you have already submitted the license to the SPDX-legal team, you should offer to withdraw the submission.

  5. Merge requests will be reviewed and merged by the Fedora License Data maintainers.

What is a "license" for purposes of the review process?

For now, we are interpreting "license" fairly broadly. A license could be, for example:

  • A complete license text

  • An informal statement about how something is licensed

  • A reference to an applicable license or permission terms published externally to the upstream project

  • A license notice in a source file

  • Minimalist grants of relatively broad legal permission (including public domain dedications)

As we gain experience with administering the new process, we may refine this view of what a "license" is in the interests of efficiency and practicality.

How to determine if a license or exception is on the SPDX License List

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. There are some open source tools that can help detect and match licenses to those on the SPDX License List listed below. If you know of other helpful tools, please create an issue to add it to these pages!

  • If a license or exception is identified as a match, you can then use the SPDX identifier to search in the allowed and not-allowed license lists for Fedora.

  • If a license comes up as a close match to an SPDX identifier, and it does not match in the sense meant in the SPDX matching guidelines or you are not sure, note this in the Fedora-license-data issue and consider consulting with SPDX-legal to see whether the license should be submitted as a new license for inclusion in the SPDX License List.

What if a license is allowed for Fedora but is not on the SPDX License List?

To help Fedora switch from using "Callaway" license tags to SPDX license expressions, members of SPDX-legal undertook a comparison of all Fedora "good" and "bad" license texts in order to map Callaway licenses to SPDX license expressions. This data was later converted into the Fedora License Data TOML file format.

However, a full SPDX mapping of all Callaway licenses was not possible. It is important to understand that the Callaway system had no counterpart to the SPDX matching concept. Some Callaway licenses are umbrella categories referring to a set of substantively different license texts (e.g., "BSD", "MIT", "exceptions"). In some of these cases, the license text was not captured in the Fedora licensing wiki. In other cases, it wasn’t clear that some of the older "good" licenses were even still used in Fedora Linux, in which case it did not make sense to add them to the SPDX License List. We have decided to leave these cases out of the Fedora License Data for the time being. If they are encountered in Fedora packages later, then they can be added (to the Fedora License Data and SPDX License List, as appropriate) at that point.

What is LicenseRef-?

The SPDX Specification defines a way to create a license identifier for licenses that are not on the SPDX License List using the LicenseRef- prefix. For continuity and ease of identification in the data, Fedora uses the LicenseRef- convention where necessary.

Licenses in Fedora License Data that use LicenseRef- include:

  • licenses that are not-allowed for Fedora and don’t happen to already have an SPDX id

  • licenses that are allowed for Fedora, but so old that they are no longer found in Fedora

  • licenses that are allowed for Fedora but to not meet the SPDX inclusion guidelines (this may include allowed-firmware)

  • the Fedora-specific LicenseRef-Fedora-UltraPermissive or LicenseRef-Fedora-Public-Domain. Note: these may later be added to the SPDX License List upon collaboration with SPDX-legal as described in bulk review

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.

What if the license for a Fedora package changes?

Sometimes the upstream package you are maintaining will change the license of all or part of the project. In this case, the following guidance apply:

  • If the license changes from an allowed license to 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 license changes from an allowed license to 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.

  • Assuming the new license is allowed, you will have to update the spec file License: field (unless the License: field guidelines indicate otherwise --- for example, if the upstream license change only covers code that is not included in a Fedora binary RPM).

  • Fedora package maintainers are expected to announce upstream license changes that they become aware of on the Fedora devel list.

If you are unsure about the status of a new license in a package, please ask on the Fedora legal list.