On Wed, Jul 19, 2023 at 8:16 AM Fabio Valentini <decathorpe(a)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...).
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