On Wed, Aug 24, 2022 at 1:00 PM Jilayne Lovejoy <jlovejoy@xxxxxxxxxx> wrote: > > > > On 8/24/22 8:56 AM, Richard Fontana wrote: > > Cross-posting this to the devel list. > > > > On Tue, Aug 23, 2022 at 11:41 PM Maxwell G <gotmax@e.email> wrote: > >> Hi Legal folks, > >> > >> Can you please consider removing the following rule? > >> > >>> Fedora package maintainers are expected to announce upstream license > >>> changes that they become aware of on the Fedora devel list. > >> -- https://docs.fedoraproject.org/en-US/legal/license-review-process/#_what_if_the_license_for_a_fedora_package_changes > >> > >> This creates unnecessary friction for packagers that simply wish to have > >> correct License fields. I'm also not sure what purposes it serves. > >> Richard explicitly said that Fedora does not concern itself with > >> cross-package license compatibility. > > That's typically been the case, yes (and for other Linux distributions too). > > > >> And even if it did, a "GPLv3+" to > >> "GPL-3.0-or-later AND MIT" license change shouldn't cause any new > >> license compatibility issues. > > I am inclined to agree with Maxwell here. I'm guessing this > > expectation must have originated pretty early on and mainly out of > > concerns about identifying cross-package license incompatibility > > situations (I can't really see what other practical purpose the > > announcement would serve). While Fedora package maintainers need to be > > on alert to any upstream license changes, I think this rule is sort of > > out of step with how such upstream license changes may often occur and > > is also out of step with how we are now focusing somewhat more closely > > on the details of upstream source code licensing. > > > > However, maybe there is some benefit to this announcement rule I am > > not seeing. Has an announcement of an upstream license change on the > > devel list (assuming the license change is to some other license known > > to be allowed in Fedora) ever led to some action on the part of > > maintainers of other packages? > I think this is sort of why we simply kept this policy as-is for the > time being - in case there was some benefit we hadn't thought of. I > recall questioning this was to devel instead of legal mailing list but I > think we presumed that was due to the larger audience on devel. > In any case, the one benefit I see at the moment is during this > transition to SPDX, it raises awareness and visibility in case people > need some guidance and may not realize it. Over the long haul, I could > see dropping it though. If the main concern is guidance around the transition to SPDX, then the better audience is the legal list, not the devel list. But I think it might be better to encourage people with questions relating to the transition to SPDX to submit issues to https://gitlab.com/fedora/legal/fedora-license-data. One concern I have about the traditional rule is that it seems to encourage a view that 'small upstream license changes don't really matter' (because in practice no one generally interpreted the rule to apply to such changes, I'm pretty sure) -- which might very well not be the case. By 'small' I mean 'only covers a small portion of the upstream project source code' as opposed to some major global project license change. To take a fairly random recent example, from a Fedora policy standpoint the license change noted in this ticket https://bugzilla.redhat.com/show_bug.cgi?id=2116859 is pretty significant, but compliance with the 'announce license changes' rule would probably never have caught it. As it happens, that license change was brought up on the legal list by someone other than the maintainer of the relevant package(s). Instead the kinds of license changes that I've seen announced on the devel list over the years seem fairly insignificant, like GPLv2+ to GPLv3+. Richard _______________________________________________ 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
