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). "Wrong" by Fedora standards, at any rate (we've talked about that before in a couple of other threads). 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." > 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. 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. 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'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. :) 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)? Richard _______________________________________________ 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
