-
Notifications
You must be signed in to change notification settings - Fork 11
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
please consider relicensing the hexf / hexf-parse crates #26
Comments
Sorry for late reply (I thank @youknowone for ping). And yeah, that sounds problematic. I'm very much okay to relicense---or additionally license---my contribution in other PD-equivalent licenses. Which one to adoptMy use of a PD-equivalent license was inspired of the SQLite public domain dedication, but I wanted to be more concrete when it comes to a legal matter. Therefore if it's just my own code, theoretically I can just state that CC0-1.0 section 4(a) is to be ignored. But that would be legally questionable to say the least. I personally didn't use the Unlicense (or WTFPL or other tongue-in-cheek licenses) because it is a polar opposite of a "concrete" license. Indeed, CC0 as a public domain dedication is so concrete that it prevents other interpretations including a patent grant. The Unlicense is the only PD-equivalent license besides from CC0-1.0 that has received an approval from FSF, but it's not like that FSF explicitly disapproved other PD-equivalent licenses, so I don't care about that much. I have also briefly considered two more options.
Therefore my option is to switch to the Zero-Clause BSD (SPDX identifier AgreementsThe crate has accumulated more code since my last major contribution though, so it's time to call everyone around. Judging from the diff, I think non-trivial changes can be classified as folllows:
It is arguable whether changes in 2 or 3 require relicensing, but for now I've pinged everyone. If you agree to relicense your work please copy and paste the following comment: * [ ] I agree to relicense my contributions to `hexf` in the terms of the [Zero-Clause BSD](https://opensource.org/license/0bsd/) license as published by the Open Source Initiative. ...and explicitly mark the check box. My own is as follows:
|
Good idea moving off of CC0. I've read about that being problematic for code before.
|
👍
|
|
4 similar comments
|
|
|
|
Thank you for confirmations, and sorry again for my procrastination! |
Awesome - thank you all for the quick turnaround here! 💯 |
The CC0-1.0 license is no longer considered to be a suitable license for code by some lawyers in the open-source licensing space (it is still considered a "good" license for content). For example, code licensed under the CC0-1.0 license is no longer allowed to be packaged for Fedora Linux since July 2022: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/message/RRYM3CLYJYW64VSQIXY6IF3TCDZGS6LM/
For context - I am currently working on packaging ruff (a very fast Python linter) for Fedora Linux, and one of its dependencies is the
hexf-parse
crate. Currently, providing a package for ruff would be blocked becausehexf-parse
cannot be packaged and / or distributed by us.Alternatives to CC0-1.0 that are still "good" licenses for code might be
Unlicense
,MIT-0
, or0BSD
. Note that of these three, only theUnlicense
appears to be considered a FOSS license by both the FSF and the OSI, whereasMIT-0
and0BSD
are only OSI-approved (c.f. https://spdx.org/licenses/).The text was updated successfully, but these errors were encountered: