Changes/SPDX Licenses Phase 2 alt

Guidance
For details on how to fill out this form, see the documentation.

SPDX License Phase 2

Summary

The second phase of transition from using Fedora's short identifiers for licenses to SPDX expressions in the License: field of Fedora package spec files. This phase addresses specific guidance on how to find licenses in a package, how to update the License: field for existing packages, and the addition of a tool in Zuul that is visible via the Bodhi updates system that provides ongoing license scanning for packages.

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 39
• Last updated: 2022-11-28
• FESCo issue: <will be assigned by the Wrangler>
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

This is follow-up of Phase 1. During this phase, tools and processes will be implemented to aid in converting the remaining packages in Fedora to use SPDX expressions in the License: field in the spec file. This phase consists of the following parts:

License Matching Guidance

The Fedora Legal documentation and Fedora Packager documentation will be updated, where appropriate, to include specific guidance on how to match the license(s) used in a software package to an SPDX expression. SPDX defines matching rules as well as identifiers. The guidance should explain the matching rules and process, identify tools that can help packagers, and explain the resolution procedure for non-conclusive matching (e.g., a new license is found or a variant of an existing license is found that invalidates existing matching). This process is largely established right now around the fedora-license-data project on GitLab and the legal@lists.fedoraproject.org mailing list.

Document How To Update Existing Packages

The Fedora Packager documentation will be updated to instruct package maintainers how to convert a package and log it in the %changelog consistently.

License Scanning Tool

As part of an ongoing check for the distribution, this change will introduce a program that Zuul can invoke as part of Fedora CI that will scan the package's source code to generate a candidate SPDX expression. The idea here is to continue checking licensing information for the life of a package and present the scanning tool's findings to the package maintainer. This tool should run as part of Fedora CI and present the information via the Bodhi updates interface. The intent is for this tool to provide information and not decide is the package passes or fails a test. License checking does require human intervention at some point and tools are never perfect, but this will provide licensing information to the maintainer in an ongoing manner.

Modify rpminspect To Reject Legacy Identifiers Via Configuration File Change

The goal is for Fedora to be using SPDX expressions exclusively, but it will take package maintainers some time to learn about SPDX and migrate their packages. This time also allows us to audit the software to ensure the license presented in the spec file actually matches the source code. This change will announce to developers a future deadline to be using SPDX. The tooling implemented will help maintainers convert packages. rpminspect will be modified to allow a configuration file change to make it reject the legacy Fedora identifiers. For the lead up period, rpminspect will accept both Fedora legacy identifiers and SPDX expressions (but not a combination of the two). We also need this time period to handle Fedora-specific SPDX-compatible IDs that we will be unable to submit to upstream SPDX. Things that we will declare using the LicenseRef- notation.

SPDX Change Report

This change will introduce weekly reporting emails to the Fedora devel list noting how many packages have moved to SPDX expressions and how many remain to convert.

Feedback

See feedback section of Phase 1

Discussions on mailing list:

• Statistics
• Change Update
• - How to handle MIT and BSD

Challenges:

• Educating package maintainers about SPDX expressions
• Submission and acceptance of any new licenses we find to upstream SPDX (unknown if there are any, but if there are we will need to do this)
• Gaining consistent license auditing information. Package maintainers will likely use scanning tools (e.g., scancode-toolkit) but some may read source directly. Is this sufficient for the reliability of the licensing information in Fedora?

Benefit to Fedora

Fedora has been well-served by the self-established short identifiers. These identifiers were established before SPDX existed. Now that SPDX exists and is in use by many upstream projects, other distributions, and within industry reporting systems, it is to Fedora's advantage to adopt these expressions. Depending on the level of diligence done in this transition, Fedora could be positioned as a leader and contributor to better license info upstream (of Fedora).

Scope

• Prep work:
  • Outline changes for the Fedora Legal and Fedora Packager documentation changes
  • Select license scanning tool for ongoing use
  • Create upstream RFE for rpminspect (the config file change)
  • Create a list of needed downstream SPDX-compatible IDs (our LicenseRef- stuff)
  • Figure out what to do about "Public Domain"

• Proposal owners (things sorted by done/todo and by priorities):
  • Assign Fedora Legal docs update to a proposal owner and complete the changes
  • Assign Fedora Packager docs update to a proposal owner and complete the changes
  • Assign ongoing license scanning tool to a proposal owner and complete the changes
  • See that the rpminspect RFE is completed
  • Create MRs for all of our needed downstream SPDX-compatible IDs
  • Create MR for whatever we're doing for "Public Domain"
  • Announce the conversion process on devel@lists.fedoraproject.org and where maintainers can find documentation, tools, and how to read ongoing license scanning information in Bodhi. Announcement should note future deadline for SPDX conversion
  • Ensure weekly license conversion reports continue going to devel@lists.fedoraproject.org

• Other developers:
  • Will need help from the Zuul team for integration of license scanning tool and reporting. This may involve the Bodhi team as well.

• Release engineering: #Releng issue number

• Policies and guidelines: Licensing page, packaging guidelines has to be altered.
  • Fedora Legal docs will include guidance on how to audit source code and match licensing information to SPDX IDs and build an SPDX expression.
  • Fedora Packager docs will include information on how to migrate an existing package to an SPDX expression and how to note it in the %changelog

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

• Alignment with Objectives:

Upgrade/compatibility impact

License strings are not used by anything at runtime. 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 (see Details above).

How To Test

See How to test section of Phase 1

User Experience

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

Dependencies

No other dependencies.

Contingency Plan

• Contingency mechanism: There will be no way back. We either rollback in Phase 1. Once we will start Phase 2 we will be beyond of point with no return.
• 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)