SPDX License Phase 3
Summary
The third phase of transition from using Fedora's short names for licenses to SPDX identifiers in the License: field of Fedora package spec files. This phase focuses on migrating the remaining packages. Although we still do not expect that all packages will be migrated in this phase.
Owner
- Email: msuchy@redhat.com, dcantrell@redhat.com, jlovejoy@redhat.com, rfontana@redhat.com
Current status
- Targeted release: Fedora Linux 40
- Last updated: 2023-10-25
- devel thread
- FESCo issue: to be filled by the wrangler
- Tracker bug: to be filled by the wrangler
- Release notes tracker: to be filled 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.
So far, package maintainers have been updating their packages in accordance with the guidance provided at https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ and filing issues in the fedora-license-data repo. Miroslav has been tracking how many packages that have been updated. Given the large number of packages in Fedora, this progress is good, but slow.
We are considering options for how to more quickly migrate, in terms of how much automation can be applied as opposed to taking this as an opportunity as a more thorough license review. Automated updating of Fedora legacy abbreviations to SPDX expressions is only possible to a limited extent due to different criteria used in each system, most notably the use of "category" short names in the Fedora legacy system. Also, the policy for populating the License: field has been clarified with a view to eliminating inconsistent guidance in past documentation, which may mean that a determination made in the past would be different today. Nonetheless, automated updates for a curated set of Fedora legacy abbreviations can help speed up the migration and serve as a reminder and helping hand to package maintainers who may have not started this process. If the automatic migration is not possible (e.g., needs clarification from legal), then a Bugzilla issue has to be created.
Plan:
- Hold a hackfest focusing on a limited set of Fedora packages. Feedback from the hackfest can then be used to improve documentation related to updating existing packages.
- Review of licenses for which there seems to be a one-to-one mapping from Fedora legacy abbreviations to SPDX identifiers to ensure reliable mapping. license-fedora2spdx will then be updated to use that curated set of mappings.
- Packages using legacy license expressions will be automatically converted if the package maintainer has not already taken care of it. 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.
- 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, ...). A pull request for the package spec file will be created as part of the conversion. If the maintainer does not respond to the pull-request within 14 days, the pull request will be merged by Change owners.
- As mentioned above and at https://docs.fedoraproject.org/en-US/legal/update-existing-packages/, automatic conversion is not possible for a lot of packages and will need direct review. For example, legacy license identifiers that cannot be automatically converted: BSD, MIT, with exceptions.
- Regular office hours will be held to help answer questions for package maintainers.
As of 2023-03-13 the automatic conversion can be done for approximately 8096 packages.
Around Fedora 39 Beta owners will file a BZ for any package that does not update the license tag. As of 2023-03-13 that would be 12206 packages. But owners expect a much lower number by that time.
This Change may be followed by Phase 3 where want to provide package maintainers with a service that will notify them when it is likely that the upstream license has changed. But such service is not part of this Phase 2 Change proposal.
Feedback
See feedback section of Phase 1
Discussions on mailing list:
Challenges:
- license-fedora2spdx tool uses mapping of legacy Fedora short names to SPDX identifiers using the fedora-license-data to suggest SPDX identifiers. Where there is an apparent one-to-one mapping, the package maintainer could simply update the License field: and move on.
- for many packages, particularly packages that use "umbrella" legacy short names that may refer to a large set of unrelated or loosely-related licenses, further inspection will be needed. Currently, Fedora documentation provides sparse advice on how to do this inspection and thus, a range of methods are used.
Benefit to Fedora
The use of standardized identifiers for licenses will align Fedora with other distributions and facilitates 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 information upstream (of Fedora).
Scope
- Change Owners:
- Continue adding newly found licenses to fedora-license-data and to SPDX.org list.
- Continue to report progress
- Focus on the ELN subset of Fedora.
- Other developers:
- All packages (during the package review) should use the SPDX expression. - this is redundant as this has already been approved since Phase 1, but it should be reminded.
- Migrate the existing License tag from a short name to an SPDX expression.
- Release engineering: nothing
- Policies and guidelines: all done in previous phases
- 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 are already beyond of point to return. We are heading to explore strange new worlds... to boldly go where no man has gone before.
- 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
Release Notes
In Fedora 39, RPM packages use SPDX identifiers as a standard. More than half of the packages have been migrated to SPDX identifiers. The remaining packages are estimated to be migrated in two upcoming releases of Fedora.