From Fedora Project Wiki
No edit summary
Line 7: Line 7:
== Summary ==
== Summary ==
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". -->
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". -->
Second phase of transition from Fedora's short name of licenses to standardized [https://spdx.org/licenses/ SPDX license] [https://spdx.dev/specifications/ formula].
Second phase of transition from using Fedora's short name for licenses to [https://spdx.org/licenses/ SPDX identifiers] in the License: field of Fedora package spec files. This phase addresses how to update the License: field for existing packages, including documenting more specific guidance on how to find licenses in a package.  




Line 55: Line 55:
== Detailed Description ==
== Detailed Description ==
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
This is follow-up of [[Changes/SPDX_Licenses_Phase_1|Phase 1]]. During this phase, all remaining packages should be migrated to the SPDX license identifier. If the migration is not possible (e.g. needs clarification from legal), then a Bugzilla issue has to be created.
This is follow-up of [[Changes/SPDX_Licenses_Phase_1|Phase 1]]. During this phase, all remaining packages should be migrated to use SPDX license identifiers in the License: field of the package spec file. If the migration is not possible (e.g. needs clarification from legal), then a Bugzilla issue has to be created.


== Feedback ==
== Feedback ==
Line 90: Line 90:
     https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
     https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
-->
-->
The use of a standardized identifier for license will align Fedora with other distributions. And allows efficient and reliable identification of licenses.
The use of a standardized identifier for license will align Fedora with other distributions. And allows efficient and reliable identification of licenses. 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 ==
== Scope ==

Revision as of 16:59, 18 November 2022

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


SPDX License Phase 2

Summary

Second phase of transition from using Fedora's short name for licenses to SPDX identifiers in the License: field of Fedora package spec files. This phase addresses how to update the License: field for existing packages, including documenting more specific guidance on how to find licenses in a package.


Owner

  • 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-18
  • 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, all remaining packages should be migrated to use SPDX license identifiers in the License: field of the package spec file. If the migration is not possible (e.g. needs clarification from legal), then a Bugzilla issue has to be created.

Feedback

See feedback section of Phase 1

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. 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

  • Proposal owners (things sorted by done/todo and by priorities):
    • Identify all remaining packages.
    • Notify owners of these packages.
    • After a grace period, submit PR to a package where the transition is easy.
    • Create tracking BZ for packages with unclear transition path
    • Submit BZ for packages that cannot migrate in time.

Owners will start doing this after Fedora 38 branching. I.e. after 2023-02-07.

  • Other developers:
    • All packages (during the package review) should use the SPDX expression.
    • Migrate the existing License tag from a short name to an SPDX expression.
  • 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

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 Bills 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)

Release Notes