On Wed, Jul 19, 2023 at 7:28 PM Richard Fontana <rfontana@xxxxxxxxxx> wrote: > > On Wed, Jul 19, 2023 at 8:16 AM Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > > > > Hi all, > > > > I've been working on updating a few Rust applications that are > > packaged for Fedora, and one of them (gitui) has added a new > > dependency on the "notify-debouncer-mini" crate. > > > > (GitHub project: https://github.com/notify-rs/notify) > > > > However, I think the license of both the "notify-debouncer-mini" crate > > (which is not packaged yet) and the "notify" crate as currently > > packaged are possibly problematic: > > > > The project was initially licensed "CC0-1.0", but was relicensed to > > "CC0-1.0 OR Artistic-2.0" with recent releases. This is reflected in > > the project's metadata, which claims "license = CC0-1.0 OR > > Artistic-2.0". However, reading the project's README, this is not > > accurate - old code was not relicensed, so it is still "CC0-1.0"-only, > > and only new code is dual-licensed as "CC0-1.0 OR Artistic-2.0": > > > > https://github.com/notify-rs/notify#license > > > > So if I understand this correctly, the SPDX identifier in the project > > metadata is wrong (should be "CC0-1.0 AND Artistic-2.0" instead). Hi Richard, Thanks for the quick response! > "Wrong" by Fedora standards, at any rate (we've talked about that > before in a couple of other threads). Right, upstream projects might have (and do have) different notions about what's "correct" here ... > Actually, wouldn't it be `CC0-1.0 AND (CC0-1.0 OR Artistic-2.0)` (if > this were actually Artistic 2.0, more on that below)? Fedora legal > docs: "The license expression must reflect the disjunctive license > choice even if one or both of the license identifiers in the OR > expression also appear separately in the composite license > expression." You're right, I took a shortcut when I wrote this paragraph. > > It looks like this was not noticed when the "notify" crate in Fedora was > > updated to this version, and as a result, the license tag of the > > package is currently inaccurate (i.e. "Artistic-2.0"). > > > > Additionally, the file that includes the license text for the > > Artistic-2.0 license contains this additional amendment from the > > project's author: > > > > """ > > Copyright © 2018 Félix Saparelli > > Any action relating to this license may only be brought in New Zealand. > > """ > > > > ref. https://github.com/notify-rs/notify/blob/main/LICENSE.ARTISTIC#L1-L2 > > > > I have no idea if this is a valid thing to do, but it looks at least > > potentially problematic. > > I think it is potentially problematic from a license policy standpoint > but the answer isn't immediately obvious. This is a choice of venue > clause. A small number of licenses generally recognized as FOSS have > them, but they are controversial in an open source context and I think > there is a growing recognition that they should probably preclude a > license from being considered FOSS (I think there was a > recently-submitted OSI license that had such a feature). Since Fedora > doesn't have a clear policy on this, you could submit an issue at > fedora-license-data. We would not treat this as identical to > `Artistic-2.0` (at least, I don't think we would/should) so if it were > allowed it would be something like `Artistic-2.0 WITH > AdditionRef-NZ-action` or something like that, using the recently > adopted SPDX 'AdditionRef-' construct for custom-defined identifiers > for additional terms. Ok, that seems doable. > I'd also note that it is unclear whether that term is supposed to > apply only to the contributions of Félix Saparelli (who apparently is > in New Zealand) or to all other contributors. In some other context > that might just be annoying but here it possibly affects whether the > license is FOSS and it probably affects how you properly represent the > license as an SPDX expression. I.e. perhaps one would say it is > `Artistic-2.0 WITH AdditionRef-NZ-action AND Artistic-2.0`. It is > *not* common at all in open source to see people tacking on choice of > venue clauses to standard licenses and I think it ought to be viewed > as inappropriate even if the resultant license should be treated as > FOSS. I was wondering the same thing. The project on GitHub lists 79 contributors (which counts only people who actually contributed commits) ... > If I'm not mistaken, the CC0 code in the Fedora package would qualify > for the grandparenting exception > (https://gitlab.com/fedora/legal/fedora-license-data/-/blame/main/data/CC0-1.0.toml#L11-L13). I think it would (see below). > > I'm unsure how to proceed here. The "notify" crate has already been > > packaged for a while, so it was not covered by the "no packages must > > use the 'CC0-1.0' license" rule yet, but the "notify-debouncer-mini" > > crate was essentially split off from the main "notify" crate, so it > > shares its license. > > > > If the license terms of this project are indeed problematic, what > > would be the way to proceed? There is one existing application > > (alacritty) in Fedora that depends on this library, and the latest > > version of gitui (not updated yet) also added a dependency on it. It's > > the only popular cross-platform library for watching filesystem > > events, with over 700K downloads - no alternatives comes close to > > that, so I'm not sure if recommending upstream projects to migrate to > > a different library would be possible. > > It would be helpful if someone could persuade the upstream project to > get rid of the New Zealand clause. :) I can ask upstream about that ... but looking through old tickets, it seems they are sticking to their armchair-lawyering analysis :( > Is there an argument that notify-debouncer-mini should qualify for the > grandparenting exception for CC0 by virtue of having originally been > part of notify-rs (or did I misunderstand that part)? No, that's exactly right. The "debouncer" functionality was part of the "notify" crate until version 4, but was split off into separately published crates ("notify-debouncer-mini", "notify-debouncer-full") with version 5 - but they are all developed in the same project on GitHub, and covered by the same license. So ... what would the "action plan" look like here? I see two options: Option 1: Would it be OK to say "we opt for using this software under the terms of the "CC0-1.0" license and not the "not-quite-Artistic-2.0" license"? Option 2: I can file an upstream ticket asking them to consider removing the non-standard "choice of venue clause" from the license terms. However, since I would like to avoid lengthy license terms discussions with upstream (since not having "notify-debouncer-mini" packaged for Fedora is blocking updates for some applications), I would prefer Option 1, if possible. Fabio _______________________________________________ legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to legal-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/legal@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
