(link burndown chart) |
(→Scope) |
||
Line 137: | Line 137: | ||
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
** All packages (during the package review) should use the SPDX expression. | ** All packages (during the package review) should use the SPDX expression. - this is redundant as this is already approved since Phase 1, but should be reminded. | ||
** Migrate the existing License tag from a short name to an SPDX expression. | ** Migrate the existing License tag from a short name to an SPDX expression. | ||
Revision as of 20:41, 17 January 2023
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
- 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: 2023-01-17
- 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.
Options for how to best migrate still need to be specified in terms of how much automation can be applied versus taking this as an opportunity as a more thorough license review. Some initial guidance and identification of challenges has been identified at Existing Packages but more details are needed, especially in regard to Fedora "category" short names.
If the migration is not possible (e.g., needs clarification from legal), then a Bugzilla issue has to be created.
Plan:
- Packages with legacy license expressions that can be mapped to new fedora-license-data expressions will be automatically converted if the package maintainer has not already taken care of it. Automatic conversion is not possible for a lot of packages and will need direct review. Legacy license identifiers that cannot be automatically converted:
- BSD
- MIT
- Legacy identifiers that are not in SPDX and do not yet have a LicenseRef- identifier in fedora-license-data (this may include Public Domain, Distributable, and many licenses used for firmware packages)
- Packages with compound legacy license expressions will only be converted if all included identifiers can map to fedora-license-data. That is, there is no mixing of SPDX and legacy Fedora identifiers.
- Regular office hours will be held to help answer questions for package maintainers.
. As of 2023-01-17 the automatic conversion can be done for 8986 packages. The conversion will be done in waves to minimize errors in automation (e.g., 100 packages in the first week, 200 packages in another week, ...). When the maintainer does not respond in pull-request within 14 days, the pull request will be merged by Change owners.
Around Fedora 39 Beta owners will file a BZ for any package that does not update the license tag. As of 2023-01-17 that would be 13780 packages. But owners expect a much lower number by that time.
Feedback
See feedback section of Phase 1
Discussions on mailing list:
Challenges:
- license-fedora2spdx tool uses mapping of Fedora shortnames to SPDX ids using the [1] to suggest SPDX ids. Where there is a one-to-one mapping, the package maintainer could simply update the License field: and move on.
- for many packages, the use of Fedora shortnames that represent multiple licenses, further inspection will be needed. Currently, Fedora documentation provide sparse advice on how to do this inspection and thus, a range of methods are used.
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
- Prep work:
- poll package maintainers on methods and tools used for license inspection
- create additional guidance (using info from above)
- planning/brainstorming on most efficient way to update packages, especially those that do not have one-to-one identifier update and will need closer inspection
- 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.
- Other developers:
- All packages (during the package review) should use the SPDX expression. - this is redundant as this is already approved since Phase 1, but should be reminded.
- Migrate the existing License tag from a short name to an SPDX expression.
- 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
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)