Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(even more) license clarifications: non-standard Artistic-2.0 license #514

Closed
decathorpe opened this issue Jul 30, 2023 · 6 comments · Fixed by #520
Closed

(even more) license clarifications: non-standard Artistic-2.0 license #514

decathorpe opened this issue Jul 30, 2023 · 6 comments · Fixed by #520

Comments

@decathorpe
Copy link

I'm responsible for maintaining packages for the "notify" crate in Fedora Linux, and am also currently in the process of adding "notify-debouncer-mini/full", as more Rust applications start depending on them. Reviewing the project, I noticed that the situation around the license of this project is still a bit unclear.

I asked for advice on the Fedora Project's mailing list for questions like these (included here for reference), and according to a lawyer who specializes in Open Source, there's two potential issues that would require clarifications:

  1. The SPDX license in the crate's metadata is not wrong, but technically can be considered to be incomplete. Since old code remains "CC0-1.0 only" and new code is "CC0-1.0 OR Artistic-2.0", the SPDX expression for this situation would be "CC0-1.0 AND (CC0-1.0 OR Artistic-2.0)".

  2. The license text for the Artistic-2.0 license (originally added in this commit) has an additional "choice of venue" clause, which is both "unusual" and potentially would disqualify the license terms (combined Artistic-2.0 plus the attached clause) from being considered FOSS in some contexts.

The relevant part from the lawyer's response:

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.

(from this mailing list post)

So for now, we will likely opt for using this project under the CC0-1.0 license only (since all code remains available under this license), but it would be great to have a definitive answer, especially concerning the second point.

@0xpr03
Copy link
Member

0xpr03 commented Jul 30, 2023

cc @passcod - you originally started the transition and I honestly can't say anything about it, at least not for reasons of decency

Edit: Also thanks for trying to unravel the mess that is notifies license (stuck in transition) state.

@passcod
Copy link
Member

passcod commented Jul 30, 2023

100% fine if the transition is halted and reverts to CC0 only.

The basis for applying Artistic in the first place was when I rewrote all of the code from scratch, thus in my view became sole author again. However, two things happened:

  • I moved away from the project;
  • The ambitious full-rewrite rearchitecture was, at least in part, canned.

I can't in good conscience make any claim of authorship (save for initial-founding "bragging rights") on the current codebase, regardless of how much code is or is not my contribution in a pure source origin analysis.

There is also no point in leaving the choice of venue clause, given it was meant for two purposes (venue first, and second to avoid any potential software patent issues, not that I know of any applying to this project) and that the primary is no longer even marginally useful.

I therefore disclaim that clause from all of my contributions to this project under this license. Given they're also all under CC0, it doesn't really effectively mean much anyway.

@decathorpe
Copy link
Author

Thank you, simplifying to just "CC0-1.0" would be very helpful! 💯

@0xpr03
Copy link
Member

0xpr03 commented Aug 2, 2023

I can just change the debouncer-mini stuff, as it's 100% from me.
cc @dfaust for -full. And then change notify from the dual license to only CC0 ?

@dfaust
Copy link
Collaborator

dfaust commented Aug 4, 2023

Sure, fine by me!

@decathorpe
Copy link
Author

Thanks everybody! This will make my work as a distro package maintainer much easier in the future :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants