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

license #49

Open
ericbets opened this issue Nov 21, 2017 · 5 comments
Open

license #49

ericbets opened this issue Nov 21, 2017 · 5 comments

Comments

@ericbets
Copy link

ericbets commented Nov 21, 2017

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?

@ericbets ericbets changed the title http & license license Nov 21, 2017
@eternaleye
Copy link

eternaleye commented Apr 4, 2018

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:

  1. By reading this sentence, You have agreed to the terms and conditions of this License.
    • It's the first of the terms and we already have a problem. This is a "contract of adhesion" which is legally problematic in various jurisdictions.
    • It also undermines your README statement that other licenses are available - once someone's read this, whatever other license you offer is moot, unless this is toothless.
  2. If the Program shows any evidence of having been properly tested or verified, You will disregard this evidence.
    • Toothless
    • An "additional constraint" that makes it GPL-incompatible.
  3. You agree to hold the Author free from shame, embarrassment or ridicule for any hacks, kludges or leaps of faith found within the Program.
    • Ditto
  4. You recognize that any request for support for the Program will be discarded with extreme prejudice.
    • Toothless
    • Sloppy drafting ("with prejudice" has a legal meaning and it's not what the author is going for, "with extreme prejudice" is trying to be fancy and tripping on shoelaces).
  5. The Author reserves all rights to the Program, except for any rights granted under any additional licenses attached to the Program.
    • Incompatible with all Free/Open licenses
    • Nasty interaction with the first term
    • Sloppy drafting with regard to the rights later in the license.

Rights:

  1. You are permitted to use the Program to validate published scientific claims.
    • Sure, okay, though this is only needed if you don't meet the Free or Open definitions (since they give use permission).
    • It's also sloppy drafting - "validate scientific claims" is something you could drive a fleet of buses through, making it toothless.
  2. You are permitted to use the Program to validate scientific claims submitted for peer review, under the condition that You keep modifications to the Program confidential until those claims have been published.
    • The one truly academically-focused part of this license, and one that's completely GPL-incompatible.
    • It also has no benefit for this project, which is in public, on GitHub.
    • See also, "validate scientific claims" being toothless.
  3. You are permitted to use and/or modify the Program for the validation of novel scientific claims if You make a good-faith attempt to notify the Author of Your work and Your claims prior to submission for publication.
    • The "validation of scientific claims" sloppiness returns, with "novel" added to further confuse the issue.
    • "Good-faith attempt" also makes an appearance, which will surely be interpreted in a clear and reasonable way by any lawyers and/or judges.
  4. If You publicly release any claims or data that were supported or generated by the Program or a modification thereof, in whole or in part, You will release any inputs supplied to the Program and any modifications You made to the Progam. This License will be in effect for the modified program.
    • ...This isn't a permission, this is a term.
    • Moreover, it's a "further restriction" that's GPL-incompatible, and is even further potentially toothless. Copyright applies to derivative works, and comes into play on distribution of the original work or the derivative. It's deeply dubious that "any claims [...] supported [...] by the program" are derivative works of the program.
    • In addition, "Program" is misspelled "Progam" in another example of sloppy drafting.

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.

@amiller
Copy link
Owner

amiller commented Apr 4, 2018

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.

@ericbets
Copy link
Author

ericbets commented Apr 4, 2018

No worries! I'm emailing you now.

@aep
Copy link

aep commented Apr 17, 2018

Did that happen?

@sbellem
Copy link
Contributor

sbellem commented Aug 24, 2018

This issue was moved to initc3/HoneyBadgerBFT-Python#37

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

No branches or pull requests

5 participants