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). 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.There have been discussions about this project's license in the past (because "CC0-1.0 OR Artistic-2.0" is a very weird license for the Rust ecosystem, which almost exclusively uses "MIT", "Apache-2.0", or "MIT OR Apache-2.0" for projects).
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.
Thanks, Fabio
On Wed, Jul 19, 2023 at 8:16 AM Fabio Valentini decathorpe@gmail.com 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....).
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
On Wed, Jul 19, 2023 at 7:28 PM Richard Fontana rfontana@redhat.com wrote:
On Wed, Jul 19, 2023 at 8:16 AM Fabio Valentini decathorpe@gmail.com 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....).
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
On Thu, Jul 20, 2023 at 11:30 AM Fabio Valentini decathorpe@gmail.com wrote:
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.
Circling back to this: The discussion with upstream was very productive, and they have agreed to simplify the license terms of the project:
- notify: Was relicensed from "technically CC0-1.0 AND (CC0-1.0 OR Artistic-2.0 WITH X-foo-bar)" back to just "CC0-1.0" (i.e. back to the same license as older versions of the project) - the author has agreed to drop the kinda-Artistic-2.0 license from his contributions. Upstream is still discussing relicensing to a different license, but reverting back to just "CC0-1.0" was a simple first step. - notify-debouncer-mini / notify-debouncer-full: Was relicensed from "CC0-1.0" to "MIT OR Apache-2.0", as the respective authors have decided to align the project with the broader Rust ecosystem.
c.f. https://github.com/notify-rs/notify/issues/514
Fabio
-
Fabio Valentini -
Richard Fontana