search

pyca / cryptography

cryptography is a package designed to expose cryptographic primitives and recipes to Python developers.
https://cryptography.io
Other
6.65k stars 1.53k forks source link

Relicense as dual Apache / BSD 2 clause #1209

Closed alex closed 9 years ago

alex commented 10 years ago

This will allow folks with GPLv2 codebases to use us, and is a blocker for PyCrypto to be implemented on top of us. I've consulted with an IP lawyer to verify that this will allow more people to use Cryptography, while still giving us the protections of the Apache license.

Tasks:

List of folks whose consent we need:

public commented 10 years ago

I know you asked a real life human lawyer @alex but I am not entirely sure I understand why we need this. I know the FSF guidelines say that GPLv2 isn't compatible with APLv2, but AIUI this is due to the patent clauses in APLv2 and those only apply to contributors to this project and by extension derivatives. However APLv2 isn't viral so it's quite hard to qualify as a real derivative, why would this effect projects that just happen to use cryptography?

Spindel commented 10 years ago

My permission is given. Go for it!

sholsapp commented 10 years ago

My permission is given.

alex commented 10 years ago

@Spindel embarrassing question, but which name are you?

lvh commented 10 years ago

+0.0, as in mailing list. Checked myself off.

mrjefftang commented 10 years ago

My permission is given.

Lukasa commented 10 years ago

I'm happy for you to relicense. I'm also open to assigning the copyright to y'all if that makes your life easier in future.

anotherthomas commented 10 years ago

Dual-licensing means people can use the software under either license, right? Can somebody explain to me how the Apache license stays relevant if the other is BSD 2 clause? In any case, if you think that's a reasonable step, I give permission.

alex commented 10 years ago

@anotherthomas Yes, it means users will be able to use it under both licenses, but contributors will need to offer their contributions under both licenses, meaning we still have the patent and other protections from the Apache license.

anotherthomas commented 10 years ago

@alex I see. Thanks.

reaperhulk commented 10 years ago

My permission is given. Checked myself.

dstufft commented 10 years ago

I give my permission.

cipherself commented 10 years ago

My permission is given.

ashfall commented 10 years ago

My permission is given.

harleyk commented 10 years ago

I give my permission.

dlitz commented 10 years ago

Chiming in as PyCrypto maintainer, I'll outline the motivation behind this change, from my perspective:

There are too many FOSS crypto libraries and too few people with the knowledge, skills, and free time to maintain them. We saw this recently with OpenSSL, and PyCrypto suffers from the same problem. PyCrypto has millions of end-users, but there are only a couple of contributors working on it in our spare time. When we inevitably make mistakes, it's rare that anyone notices. Some of the larger examples of this include:

With this license change, the PyCrypto and Cryptography communities could begin to eliminate redundancies between the two projects. PyCrypto would provide its Crypto API within the framework provided by Cryptography, and the backend implementations would be shared between the two projects. To preserve PyCrypto's GPLv2 compatibility, we would still need to substitute a GPLv2-compatible backend for the current OpenSSL-based backend, but I understand that this is already planned. If there are any remaining gaps, we could perhaps transform PyCrypto's existing C code into a Cryptography-style backend.

@public While I understand that there is some debate as to whether APLv2 is truly incompatible with GPLv2, that's the position taken by the FSF and acknowledged by the ASF. Perhaps out of an abundance of caution, it has been raised as a concern by the maintainer of Debian's python-crypto package. This license change should eliminate any doubt and allow us to focus on the technical challenges ahead.

dstufft commented 10 years ago

Yea, arguing about whether it is or isn't compatible is for lawyers :)

Spindel commented 10 years ago

Ah, sorry. I'm listed as D.Spindel Ljungmark.

exarkun commented 10 years ago

I think this is a bad idea but given my minimal contributions to the project and the apparently widespread support I'm checking the checkbox next to my name anyway.

nryoung commented 10 years ago

Sounds good to me: My permission is given

koobs commented 10 years ago

My permission is given. FWIW, I'm not convinced though of the need for a dual-license (AL2).

Ivoz commented 10 years ago

Permission from me.

Ayrx commented 10 years ago

Go for it.

manuels commented 10 years ago

My permission is given. ;)

public commented 10 years ago

@dlitz Is that conversation with the Debian maintainer public?

dlitz commented 10 years ago

@public Sure, you can find the thread at:

There isn't a lot there. The discussion wasn't extensive. IIRC from shortly after the Apache License 2.0 was first released, it's a resolved issue in Debian that it's incompatible with GPLv2, so I didn't argue. There might be an old debian-legal thread somewhere, but I don't have the reference.

lvh commented 10 years ago

@ivoz (replying to original comment instead of edited one): it does work, because the ASLv2 protections kick in when contributors add code. Contributors have to agree to both licenses, users can pick either one. That way contributors can't use patent nukes, but users that can't use ASLv2 (instead can only use less restrictive licenses like BSD) use the BSD one :)

kouk commented 10 years ago

I give my permission.

public commented 10 years ago

@lvh The ASF say this about dual licenses

The ASF will not dual-license our software because such licenses make it impossible to determine the conditions under which we have agreed to collaborate on a collective product, and are thus contrary to the Apache spirit of open, collaborative development among individuals, industry, and nonprofit organizations.

The FSF say this…

This argument has merit in theory, but a consideration of the practice of this type of dual licensing suggests a different view. Common attempts by developers at stating dual license notices tend to be confusing, contradictory, and legally unclear. While there may be cases where it will make sense for a developer (with a knowledgeable lawyer’s assistance) to place a dual license on his code, we generally recommend that developers not use dual licensing if their goal is simply to allow recipients to use the code within larger GPL’d works as well as under permissive terms.

And the Apache 2.0 license text seems to say that the patent license you receive is only when the software is used under the Apache 2.0 terms. Although obviously my legal opinion is basically worthless.

I've asked the FSF what they think we should do. Do Apache provide any assistance for issues like this?

lvh commented 10 years ago

That's true, but we do have one of those knowledgeable lawyers :-) (A damn good one, too, and, unlike the ASF and FSF ones, an impartial one at that.)

The issues raised seem to be about trying to hack it yourself. For example, the first issue goes away provided that you make it emphatically clear to contributors that contributions are under both licenses (I don't know of a legal standard for doing so, but I imagine putting it in CONTRIBUTING.rst is fine.). Additionally, getting permission from all copyright holders (which we're doing).

The SFLC document you cited goes on to say that you shouldn't dual-license so if the "permissive" license is something like BSD or ISC, which is commonly understood to be GPL-compatible. That's not the situation we're in: we're ASLv2, and it's commonly understood to be GPL-_in_compatible.

public commented 10 years ago

You might but I am not a Rackspace employee and have no idea who this person is and have never seen any correspondence from them.

We haven't actually got any new license text yet so I have no idea exactly what I am apparently agreeing to. Is this lawyer going to write something up for us, or are we just going to glue it together ourselves?

Ivoz commented 10 years ago

@lvh I removed that comment after initially writing because interpreting license language while not being a lawyer is goddamn hard :/

But after re-reading the relevant ASL part again, if a User doesn't use the ASL in consuming the work, then the Contributors to the work never give that User a license to their patents, meaning they could nuke them all they wanted. In order to be protected you have to consume it under the ASL.

hynek commented 10 years ago

I give very grudgingly my consent.

I don’t want GPL-people to be able to use my software because they stop me from using theirs. But I’m allowing it for the greater good of a safer world and checked myself off.

lvh commented 10 years ago

@Ivoz That sounds about right, but given that the only reason you'd do that is to be compatible with a version of the GPL that doesn't give you any patent protections, you're not actually any worse off :)

lvh commented 10 years ago

IRC: @public would like some information explaining how the licenses interact both for users and contributors. I'm inclined to agree.

[12:06:44] <alexs> I am not OK with making the patent situation blurry.
[12:07:17] <alexs> Particularly as we want to add more recipes.
[12:07:20] <lvh> What do you mean by "blurry"? "It depends what license you pick"?
[12:07:25] <alexs> Yeah
[12:07:40] <alexs> Currently it's fairly obvious that you get a certain amount of patent protection
[12:08:26] <lvh> Would you feel more comfortable if a competent IP lawyer wrote something, which we put in our README, regarding this?
[12:08:33] <alexs> Yep.
[12:10:26] <alexs> I can't agree to dual licensing BSD/ASLv2 when we don't have *any* license text describing their interaction.
[12:10:42] <alexs> If that was written by an actual lawyer that would be very nice :)
lvh commented 10 years ago

Alas, my comment got lost because yay eventual consistency.

My apologies, I didn't realize we were trying to establish Van Lindberg as a competent IP lawyer. Two points that should hopefully convince you:

twkang commented 10 years ago

My permission is given.

chrisglass commented 10 years ago

I hereby consent to the change of license :+1:

kimvais commented 10 years ago

Permission granted.

jgiannuzzi commented 10 years ago

My permission is given.

daenney commented 10 years ago

Permission granted.

Ayrx commented 10 years ago

How are we doing with this? Maybe it's worth sending another email to the people that hasn't agreed yet in case they missed the previous one?

public commented 10 years ago

Regardless of any other reservations I have I don't feel I can agree to a license change without actually seeing the new license wording.

dstufft commented 10 years ago

It would be 2 clause bsd.

On Jul 26, 2014, at 8:29 AM, Alex Stapleton notifications@github.com wrote:

Regardless of any other reservations I have I don't feel I can agree to a license change without actually seeing the new license wording.

— Reply to this email directly or view it on GitHub.

public commented 10 years ago

AIUI it would be 2 clause BSD + Apache 2.0 + Some extra writing that explains the dual license situation. I have not seen what that extra writing is so how can I agree to it?

alex commented 10 years ago

I'll figure out what, if any, additional wording is necessary.

On Sat, Jul 26, 2014 at 8:27 AM, Alex Stapleton notifications@github.com wrote:

AIUI it would be 2 clause BSD + Apache 2.0 + Some extra writing that explains the dual license situation. I have not seen what that extra writing is so how can I agree to it?

— Reply to this email directly or view it on GitHub https://github.com/pyca/cryptography/issues/1209#issuecomment-50237146.

"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084

glyph commented 10 years ago

@alex, can you confirm or deny that Van is the lawyer you spoke to? @lvh said something about his credentials but I don't see a claim anywhere else in the discussion that he's the one you consulted.

glyph commented 10 years ago

Also, do I understand correctly that the legal theory here is that because project policy (no longer the license, since contributors, like anyone else, might elect to consume cryptography under BSD) requires contributions to be under Apache, and Apache obligates the licensor to do certain things, that's where the protections come from?

alex commented 10 years ago

Yes, Van was the lawyer I spoke with, and yes, I believe what you said is acccurate.

On Fri, Aug 1, 2014 at 6:27 PM, Glyph notifications@github.com wrote:

Also, do I understand correctly that the legal theory here is that because project policy (no longer the license, since contributors, like anyone else, might elect to consume cryptography under BSD) requires contributions to be under Apache, and Apache obligates the licensor to do certain things, that's where the protections come from?

— Reply to this email directly or view it on GitHub https://github.com/pyca/cryptography/issues/1209#issuecomment-50950213.

"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084

Ivoz commented 10 years ago

@glyph Apache demands the licensor do certain things only for people consuming the code under the Apache license.

If you consume cryptography under its BSD license, none of the Apache protections will apply to you (you never accepted the Apache license in the first place, which is what grants you those protections).