From Fedora Project Wiki
No edit summary
Line 201: Line 201:


<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* 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. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* 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. <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 


== Documentation ==
== Documentation ==

Revision as of 19:09, 10 May 2022

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


SPDX License Phase 1

Summary

Transition from Fedora's short name of licenses to standardized SPDX license formula.

Owner

  • 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-10
  • 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

In the past, Fedora decided to use short names for licenses. Although we documented the short names very well. The identifiers were never standard. In the meantime, SPDX identifiers become standard, and other SW vendors start using it.

In this phase, we want to provide documentation and tooling to allow maintainers to begin using SPDX license ids instead of the old Fedora short names. This move is opt-in. There will be Phase 2, where we identify the remaining packages and help them to migrate to the SPDX formula.

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:
    • Miroslav Suchý: license-fedora2spdx - done
    • Miroslav Suchý: allow license-validate to use spdx - TODO
    • 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
    • David Cantrell: separate licenses from rpminspect-data-fedora BZ 2077914 - TODO
    • Richard Fontana & Jilayne Lovejoy: review update all licensing info and legal pages in wiki - in process
    • Jilayne Lovejoy & Richard Fontana: create and populate new Docs pages for legal and licensing info - in process
    • David Cantrell: generate from license data to new Docs page similar to Licensing:Main
    • Jilayne Lovejoy: prepare PR for updates to packaging guidelines - in process [3]
    • SOMEBODY: help maintainers who want to proactively change license string to SPDX identifiers.
  • 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)

  • 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

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

Documentation

N/A (not a System Wide Change)

Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/SPDX_Licenses_Phase_1&oldid=643780"