On Thu, Mar 16, 2023 at 03:16:29PM -0400, Ben Cotton wrote: > 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. This paragraph is ambiguously worded. Does this imply that packages for which automatic conversion is impossible are out of scope for conversion during phase 2 ? or Does this imply that there is a group of people who are actively going to do manual review and conversion as prt of phase 2 ? or something else again ? > * 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. Does that 12206 count exclude or include the 8096 for which automatic conversion is possible ? I'm presuming it should exclude it, since we shouldn't need to be filing bugs for packages which are automatically converted. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
