Changes/SPDX Licenses Phase 1

SPDX License Phase 1

Summary

Introduce tooling and data allowing package maintainers to transition from Fedora's existing short license names to standardized SPDX license expressions. Update and improve Fedora-legal documentation related to licensing, and move off of wiki.

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: 2023-01-17
• devel thread
• FESCo issue: #2799
• Tracker bug: #2096410
• Release notes tracker: #846

• Current status of migration

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. I want to especially highlight adoption by kernel, Debian, openSUSE, and FreeBSD.

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.

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

Questions from the mailing list discussion

Can we use SPDX expressions in older Fedora branches?

Yes.

How do we convert existing Fedora abbreviations to SPDX expressions?

You can use the tool license-fedora2spdx(1) from the package license-validate. E.g.

license-fedora2spdx 'MIT or GPLv1'

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.

The license-fedora2spdx tool should only be used as a starting point. Maintainers are encouraged to use this as an opportunity to check the source code for the package and construct a new, more accurate SPDX expression. The new Fedora legal documentation provides specific guidance and expectations on how to populate the License: field that somewhat differs from or is more consistent than past Fedora guidelines.

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. An excellent tool to help in this way is the SPDX License Diff tool (a browser plugin) The common ones are BSD-2-Clause and BSD-3-Clause.

For MIT, it's similar: Fedora has previously used 'MIT' to refer to a large number of different licenses. However, note that unlike the BSD case, there is an SPDX identifier 'MIT', which refers only to the license that today is most commonly thought of as the MIT license. Ensure you are choosing the correct SPDX identifier(s) for your package.

You can also use the tool askalono crawl $DIRECTORY. This tool is in the package askalono-cli.

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. See https://docs.fedoraproject.org/en-US/legal/license-field/ for more information.

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, or else submit an issue to the Fedora License Data project.

What tools validate the License field?

There is license-validate 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.

How do I know if the spec file has been converted?

During the transition period, there will be some spec files that will use the new SPDX format and some spec files will use the old short names. In the second phase, we will try to identify a package that has not been migrated yet. To identify what has and what has not been migrated, please do one of the following:

• comment in spec file changelog entry. E.g., comment contains "SPDX migration". This is the most preferred way.
• comment in dist-git in some format. E.g., comment contains "SPDX migration".

Old to New Examples

This table shows some examples of existing License fields in Fedora packages and what they might look like with SPDX syntax. Note that these examples assume that a simple, straightforward conversion is possible, which will not be true in all cases (and may not be accurate for these specific packages). There may not be a one-to-one correspondence between a legacy Fedora license tag and an SPDX expression, because the assumptions around what the license abbreviations are supposed to represent or convey have changed or have been made more consistent. See https://docs.fedoraproject.org/en-US/legal/license-field/ for more information. Maintainers should use this change as an opportunity to check the source code of their package and improve the accuracy of the license tag.

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.

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 wiki - Done
  • Jilayne Lovejoy & Richard Fontana: create and populate new Docs pages for legal and licensing info - Done
  • Neal Gompa - create description of various tooling used by Fedora in relation to license data (need to decide where to put this) - TODO
  • Miroslav Suchy - create fedora-license-data package (with data from rpminspect-data-fedora) - Package Review - done
  • David Cantrell: separate licenses from rpminspect-data-fedora BZ 2077914 - DONE
  • Miroslav Suchý: allow license-validate to use spdx - done
  • David and Miroslav: generate from license data to new Docs page similar to Licensing:Main - Done
  • 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 - DONE [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.

• notified pyp2spec maintainers
• notified gem2rpm maintainers

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:

Status of licenses in Fedora

I tried to automatically convert all licenses in the current Fedora using license-fedora2spdx. And the results is:

• 28478 - number of all lines with License tag in spec files
• 2176 - errors in parsing the license. I estimate that about a hundred packages do not use correct short name identifiers. The rest of this is likely a result of this issue in fedora-license-data.
• 14931 - there is more than one option on how to convert the short name to SPDX (i.e., the cases of MIT, BSD, etc.)

That means that 11371 license strings can be automatically converted.

As of 2022-10-27:

• There are 23302 spec files in Fedora
• 264 mentions "spdx" in the spec changelog
• out of the remaining, 173 packages mention "spdx" in dist-git log
• 22865 packages needs to be migrated yet.

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 --old '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 "MIT-CMU or GPL-1.0-only"

Note: license-validate should be in version 8-1 (present in F37+) otherwise it does not recognize the --old argument.

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

Licenses

Update existing packages

Release Notes

In Fedora 38, we initiated the migration of license tags in RPMs to the SPDX identifier. The work has been done in more than 20 % of packages and will continue in the next Fedora release.