-
Notifications
You must be signed in to change notification settings - Fork 84
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
license #49
Comments
I'll just chime in here that the CRAPL license is neither Free (by the FSF definition) nor Open (by the OSI definition), and thus represents a pretty harsh code reuse barrier - to the point that someone trying to be safe would have to treat it as "don't look, reverse engineer". It's not GPL-compatible (any version thereof), it's drafted by a computer scientist absent any legal assistance, it's quite frankly sloppy in its execution, it's so niche that SPDX doesn't even list it, and any "benefits" it provides over the MIT license are either 1.) toothless 2.) the cause of the aforementioned problems or 3.) both Note that IANAL, and TINLA, but the CRAPL is a really poor license even just on the face of it, for pretty obvious reasons when examined: In the terms:
Rights:
In short: The CRAPL lives up to its name, especially if you only expand the last letter of the acronym. If you want a solid permissive license that is well-understood, reliable, GPL-3 compatible, and drafted by experts, I'd suggest Apache-2 (but note that it includes a patent grant). If you want a solid permissive license that is well-understood, reliable, GPL-* compatible, and lacks the Apache patent grant, I'd suggest MIT. If you want a solid copyleft license that is well-understood, reliable, and drafted by experts, I'd suggest GPL-3. If you additionally want to ensure that SaaS platforms using it release code to users, and don't mind that many companies (such as Google) won't touch it with a ten-foot pole as a result, I'd suggest AGPL-3. If you want "Public Domain", I'd suggest CC0 (but note that it lacks a patent grant). Dual-licensing under these is entirely doable, though dual-licensing permissive and copyleft is somewhat pointless. The Rust project, for example, tends towards dual Apache-2/MIT. |
Here's my current thinking: I can issue additional more permissive licenses as time progresses, but cannot effectively withdraw existing ones. I like to use CRAPL as a conservative default for academic prototype code because it signals that it's fit for academic use only, but not fit for much else. I would next grant AGPL-3 which permits it to be used in other projects but is not suitable for most companies (since blockchains using honeybadger would likely be a "service", APGL vs GPL makes sense). Beyond that I'd choose MIT at which point it is nearly a free-for-all, but makes it usable by most companies. My current plan is to rerelease the Python version along with the next update (there will also be a compatible Go version) @ericbets sorry I missed this issue earlier! Please email me, I'd be likely to issue an MIT license if there's a good usage you have in mind. |
No worries! I'm emailing you now. |
Did that happen? |
This issue was moved to initc3/HoneyBadgerBFT-Python#37 |
I read your paper. I'm interested in testing out HoneyBadger for a project and was curious -
what are the chances for a dual Apache/CRAPL license?
The text was updated successfully, but these errors were encountered: