Changes/SPDX Licenses Phase 1

SPDX License Phase 1

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

Introduce tooling and data allowing package maintainers to transition from Fedora's existing short license names to standardized SPDX license expressions.

Owner

• Name: Miroslav Suchý
• Name: Jilayne Lovejoy
• Name: Neal Gompa
• Name: David Cantrell
• Name: Richard Fontana
• Name: Matthew Miller

• Email: msuchy@redhat.com, dcantrell@redhat.com, jlovejoy@redhat.com, ngompa13@gmail.com, rfontana@redhat.com

Current status

• Targeted release: Fedora Linux 38
• Last updated: 2022-05-31
• devel thread
• FESCo issue: #2799
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

In the past, Fedora decided to represent licenses using short abbreviations in the License field of spec files. Although we documented the short names very well, the identifiers were never standard. In the meantime, SPDX identifiers have emerged as a new standard, and other vendors and developers have started using them.

In this change, we want to provide documentation and tooling to allow maintainers to begin using SPDX license expressions instead of the existing Fedora short names. The existing Fedora abbreviations will still be honored as the move to SPDX expressions will be opt-in. In Phase 2, we will identify the packages and help them to migrate to SPDX expressions.

Questions from the mailing list discussion:

• Can we use SPDX expressions in older Fedora branches?

Once this change is approved and the Packaging Committee accepts the packaging policy change for SPDX expressions, we see no reason not to allow the change on older supported branches. We may want to make the fedora-license-data package available on those branches so that tools like rpminspect and rpmlint will be able to validate the License tag value if necessary.

• How do we convert existing Fedora abbreviations to SPDX expressions?

The fedora-license-data upstream project contains licenses and their approval status in Fedora. Where applicable, the existing Fedora short abbreviation is noted in the file as well. You can use this information to cross-reference the existing Fedora abbreviations to SPDX abbreviations. This information will also be published in more human-readable form as part of the Fedora Legal Documentation.

As an example, let's say your package has "License: GPLv2+" in the spec file. A grep of the TOML files in the fedora-license-data project will point you to GPL-2.0-or-later.toml and if you look at that file, you will see the expression field under the [license] section says GPL-2.0-or-later. A description of the TOML file format is in the TEMPLATE.toml file at the top level of the project.

Some maintainers may find it a good time to check the source code for the package and construct a new SPDX expression.

• I have a package with BSD or MIT in the License field, how do I convert that?

In this case, you will need to dig in to the source a bit more. SPDX differentiates between the various BSD licenses whereas the Fedora abbreviations called them all BSD. The common ones are BSD-2-Clause and BSD-3-Clause.

For MIT, it's similar however note that there is an SPDX abbreviation called MIT. Ensure you are choosing the correct one for your package.

• With Fedora abbreviations we could use and, or, and parentheses when constructing expressions. Can we do that with SPDX?

Yes, but SPDX spells it AND and OR. Parentheses are allowed in the same manner as Fedora expressions.

• What if my License field is already SPDX-compatible?

Well, you are ahead of the change proposal then. Thanks!

• Can we combine Fedora abbreviations and SPDX abbreviations?

No. If you want to use SPDX abbreviations, you have to convert the entire expression to SPDX syntax.

• I maintain a firmware package, what do I use for the SPDX expression?

There are a number of cases that require the fedora-license-data package to define new SPDX-compatible abbreviations. If the fedora-license-data project does not yet have a LicenseRef- file for your particular license, then Fedora Legal is still working on what that will look like. You may want to wait on the SPDX change until the next change proposal.

• What tools validate the License field?

There is license-checker noted below. There is also rpminspect and rpmlint which will validate the License tag value against the data that comes from the fedora-license-data RPM.

• Can new packages use the older Fedora license abbreviations?

No. All new packages will need to use SPDX expression syntax in the License field of the spec file.

Old to New Examples

This table shows some examples of existing License fields in Fedora packages and what they would look like with SPDX syntax. Note that this is just an example and should not be taken as the actual answer.

Example License tag values

Package	Fedora abbreviations	SPDX expression
glibc	LGPLv2+ and LGPLv2+ with exceptions and GPLv2+ and GPLv2+ with exceptions and BSD and Inner-Net and ISC and Public Domain and GFDL	(unable to convert now because of "Public Domain")
zsh	MIT	MIT
tmux	ISC and BSD	ISC AND BSD-3-Clause AND BSD-2-Clause
libX11	MIT	MIT
htop	GPLv2+	GPL-2.0-or-later
emacs	GPLv3+ and CC0	GPL-3.0-or-later AND CC0-1.0
firefox	MPLv1.1 or GPLv2+ or LGPLv2+	MPL-2.0
coreutils	GPLv3+	GPL-3.0-or-later
openssh	BSD	SSH-OpenSSH
openssl	ASL 2.0	Apache-2.0
gcc	GPLv3+ and GPLv3+ with exceptions and GPLv2+ with exceptions and LGPLv2+ and BSD	GPL-3.0-or-later AND (GPL-3.0-or-later WITH Classpath-exception-2.0) AND (GPL-2.0-or-later WITH Classpath-exception-2.0) AND LGPL-2.1-or-later AND BSD-3-Clause AND BSD-2-Clause

For firefox, it appears the source tree refers to MPL version 2.0 now and there no explicit mention of dual licensing with the GPL or LGPL. The maintainer(s) of this package should verify that before changing the License tag value.

OpenSSH carries a BSD license, but SPDX has its own entry for it. As of this writing, that entry is not yet in fedora-license-data.

Feedback

Ancient feedback from SPDX organization.

Summary from fedora-legal mailing list: we want this to happen, but this is big scope and likely will happen over more than one release.

Summary from packaging-committee:

• [1]: older PR to change packaging guidelines
• [2]: present PR that needs more updating

Summary from devel-list: TBD

Benefit to Fedora

The use of a standardized identifier for license will align Fedora with other distributions. And allows efficient and reliable identification of licenses.

Scope

• Proposal owners (things sorted by done/todo and by priorities):
  • Miroslav Suchý: license-fedora2spdx - done
  • Jilayne Lovejoy: map rest of Fedora licenses to SPDX ids - done
  • David Cantrell: create machine-readable format and new repo - done
  • David Cantrell: merge mapping of Fedora licenses to SPDX ids to new data format/repo - done
  • Richard Fontana & Jilayne Lovejoy: review update all licensing info and legal pages in a wiki - in process
  • Jilayne Lovejoy & Richard Fontana: create and populate new Docs pages for legal and licensing info - in process
  • Miroslav Suchy - create fedora-license-data package (with data from rpminspect-data-fedora) - Package Review
  • David Cantrell: separate licenses from rpminspect-data-fedora BZ 2077914 - TODO
  • Miroslav Suchý: allow license-validate to use spdx - TODO
  • David Cantrell: generate from license data to new Docs page similar to Licensing:Main
  • SOMEBODY: create a webhook that updates the Docs page after the merge to fedora-license-data - TODO
  • Jilayne Lovejoy: prepare PR for updates to packaging guidelines - in the process [3]
  • SOMEBODY: help maintainers who want to change license string to SPDX identifiers proactively.

• Out of Scope: In this phase, we do not target to move **all** packages to SPDX identifiers. That will be done in Phase 2. In Phase 2 we will identify the remaining packages and open BZ or PR.

• Other developers:

Early adopters can migrate their License tag to the SPDX identifiers. Proposal owners will gather feedback and will work on potential problems.

We want to have all bits ready so that maintainers can start changing the spec files just after Fedora 37 branching (summer 2022).

• Release engineering: #Releng issue number

• Policies and guidelines: Licensing page, packaging guidelines has to be altered.

• Trademark approval: N/A (not needed for this Change)

• Alignment with Objectives:

Upgrade/compatibility impact

License strings are not used anything in run time. This change will not affect the upgrade or runtime of Fedora.

During the transition period, developer tools like rpminspect, licensecheck, etc. may produce false negatives. And we have to define a date where we flip these tools from old Fedora's short names to the SPDX formula.

How To Test

Users should not need any testing. These steps are for package maintainers:

• Fetch your license string from License tag in SPEC file.
• Test that your current Fedora's short name is correct. E.g.

   $ license-validate -v 'MIT or GPLv1'
   Approved license

• Convert license string to SPDX formula:

   $ license-fedora2spdx 'MIT or GPLv1'
   Warning: more options how to interpret MIT. Possible options: ['Adobe-Glyph', 'MIT-CMU', 'MIT-CMU', 'HPND', 'HPND', 'no-spdx-yet (MIT license (also X11))', 'SGI-B-2.0', 'SGI-B-2.0', 'SMLNJ', 'MIT-enna', 'MIT-feh', 'mpich2']
   mpich2 or GPL-1.0-only

In this example, the short name GPLv1 can be converted straight to GPL-1.0-only. But short name MIT stands for several licenses with different SPDX identifiers. You have to examine what license is package actually using. license-fedora2spdx will try to convert the formula and use one of the options but without any heuristics. You need to manually review the license.

You can check if SPDX formula is correct using:

 $ license-validate -v --file FIXME "MIT-CMU or GPL-1.0-only"

User Experience

Users should be able to use standard software tools that audit licenses. E.g. for Software Bills of Materials.

Dependencies

No other dependencies.

Contingency Plan

• Contingency mechanism: In this first phase, if something goes wrong, we can 'git revert' each change in dist-git. It is expected that in the first phase, there will be only a few packages altered. It may be a few hundred, but it is still doable to revert.
• Contingency deadline: Beta freeze. But it is expected that not all packages will be converted by that time and the change will continue in the next release.
• Blocks release? No. This change has no impact on runtime of any package.

Documentation

N/A (not a System Wide Change)