F39 proposal: SPDX License Phase 2 (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_2

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==

Second phase of transition from using Fedora's short names 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.

== Owner ==

* Name: [[User:msuchy| Miroslav Suchý]], [[User:jlovejoy| Jilayne
Lovejoy]], [[User:ngompa| Neal Gompa]], [[User:dcantrell| David
Cantrell]], [[User:ref| Richard Fontana]], [[User:mattdm| Matthew
Miller]]
* Email: msuchy@xxxxxxxxxx, dcantrell@xxxxxxxxxx, jlovejoy@xxxxxxxxxx,
ngompa13@xxxxxxxxx, rfontana@xxxxxxxxxx


== Detailed Description ==
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.

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
[https://gitlab.com/fedora/legal/fedora-license-data
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
[https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_updating_existing_packages_callaway_short_name_categories
"category" short names in the Fedora legacy system]. Also, the
[https://docs.fedoraproject.org/en-US/legal/license-field/ 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 [[Changes/SPDX_Licenses_Phase_1#Feedback|feedback section of Phase 1]]

Discussions on mailing list:
* [https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/EXGT34EJPG3G4FJZ4R2SRAI342QDHFOF/
SPDX Statistics]
* [https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/NZIFT62REORSNS6MMES446PMCOOSEPSA/
SPDX Change Update]
* [https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/3TGCSROJTSX5PXZLKOHCOMVIBTZDORNS/
SPDX - How to handle MIT and BSD]

Challenges:
* license-fedora2spdx tool uses mapping of legacy Fedora short names
to SPDX identifiers using the
[https://gitlab.com/fedora/legal/fedora-license-data/-/tree/main|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 ==
* 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: [https://pagure.io/releng/issues #Releng issue number]

* Policies and guidelines: Licensing page will need to be altered. But
almost all the work has been done in Phase 1.
* 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 [[Changes/SPDX_Licenses_Phase_1#How_To_Test|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 ==
[https://docs.fedoraproject.org/en-US/legal/allowed-licenses/|Allowed Licenses]

[https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_process_used
Update existing packages]

== Release Notes ==
In Fedora 39, RPM packages use SPDX identifiers as a standard. Almost
all packages have been migrated to SPDX identifiers. The remaining
packages are tracked in this tracking Bugzilla issue. LINK TO BE ADDED



-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux