Relicense as dual Apache / BSD 2 clause

[alex]

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:

• Update LICENSE file appropriately
• Update setup.py classifiers
• Update __about__.py and cryptography_vectors/__about__.py
• Figure out what to do with copyright headers in every file
• Update contributing documentation
• Receive consent of all folks who have contributed to cryptography in the past.
• Changelog entry.

List of folks whose consent we need:

• Alex Gaynor
• Paul Kehrer
• David Reid
• Alex Stapleton
• Donald Stufft
• Ayrx
• Laurens Van Houtven
• Mohammed Attia
• Jean-Paul Calderone
• cyli
• Hynek Schlawack
• Julian Krause
• Richard Wall
• Ashwini Oruganti
• PhiBo
• Matthew Iversen
• Christian Heimes
• Chris Glass
• Chirag Jog
• Kubilay Kocak
• Konstantinos Koukopoulos
• timic
• ashfall
• Nic Young
• Jeff Tang
• Fedor Brunner
• Daniele Sluijters
• Cory Benfield
• skeuomorf
• Matt Iversen
• Kyle Kelley
• Kimmo Parviainen-Jalanko
• manuels
• kennwhite
• Wouter Bolsterlee
• Thomas Fenzl
• Taewook Kang
• Stephen Holsapple
• Sascha Peilicke
• Marcin Wielgoszewski
• Jonathan Giannuzzi
• Jay Parlar
• D.S. Ljungmark
• Arturo Filastò

[public]

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]

My permission is given. Go for it!

[sholsapp]

My permission is given.

[alex]

@Spindel embarrassing question, but which name are you?

[lvh]

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

[mrjefftang]

My permission is given.

[Lukasa]

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]

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]

@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]

@alex I see. Thanks.

[reaperhulk]

My permission is given. Checked myself.

[dstufft]

I give my permission.

[cipherself]

My permission is given.

[ashfall]

My permission is given.

[harleyk]

I give my permission.

[dlitz]

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:

• In February 2003, a bug was introduced in PyCrypto's setup.py that prevented the "winrandom" module from being built. (At that time, there was no os.urandom, and PyCrypto's RandomPool class seeded itself on a best-effort basis.) The result was that PyCrypto's random number generator was predictable on Windows in versions 1.9a5 through 2.0.1. This resulted in the paramiko library being insecure on Windows. Twice. The v2.1.0 release, which contained the fix, was released in December 2009---almost 7 years after the bug was introduced.
• In 2008-2009, I wrote a new RNG API and implementation for PyCrypto that was specifically designed to avoid the threading and forking bugs in the old version. In 2013, I stumbled upon a race condition in the fork-handling behavior while writing some example code. Nobody else had noticed in the intervening 5 years.
• In 2012, I merged a seemingly innocent change from one of PyCrypto's most active contributors. The change was ostensibly about "documentation" (it wrapped the C implementation with Python classes containing docstrings), but it also changed the behavior of the obscure 'IV' attribute on cipher objects. It's not clear whether any software relied on this attribute, but in theory it could have been used to implement block cipher modes-of-operation not yet natively supported by PyCrypto. The change silently turned assignment to this attribute into a no-op, which would result in a catastrophic security failure in an application that uses this feature. This bug made it into the PyCrypto 2.6 release, and has yet to be fixed: https://bugs.launchpad.net/pycrypto/+bug/1176482

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]

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

[Spindel]

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

[exarkun]

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]

Sounds good to me: My permission is given

[koobs]

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

[Ivoz]

Permission from me.

[Ayrx]

Go for it.

[manuels]

My permission is given. ;)

[public]

@dlitz Is that conversation with the Debian maintainer public?

[dlitz]

@public Sure, you can find the thread at:

• https://lists.dlitz.net/pipermail/pycrypto/2013q4/000721.html
• https://lists.dlitz.net/pipermail/pycrypto/2014q1/000771.html

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]

@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 :)

[wallrj]

Permission granted.
-Richard Wall

[lahwran]

I just want to say I'm disappointed that you're going to all this effort to allow use with the GPL, when the same effort could be going towards relicensing PyCrypto.

[dstufft]

Re licensing PyCrypto doesn't make it better for GPL applications who want to use cryptography.

[glyph]

So this means it is down to @tiran and @timic?

[alex]

That's correct.

On Tue Oct 28 2014 at 7:02:21 PM Glyph notifications@github.com wrote:

So this means it is down to @tiran https://github.com/tiran and @timic
https://github.com/timic?

—
Reply to this email directly or view it on GitHub
#1209 (comment).

[glyph]

@alex - thanks; I didn't really need the confirmation, I am just hoping that github will send @tiran and @timic more emails that will hopefully remind them to respond to this :).

[alex]

I've also personally sent them emails, hopefully we'll hear back shorlty.

On Tue Oct 28 2014 at 7:06:39 PM Glyph notifications@github.com wrote:

@alex https://github.com/alex - thanks; I didn't really need the
confirmation, I am just hoping that github will send @tiran
https://github.com/tiran and @timic https://github.com/timic more
emails that will hopefully remind them to respond to this :).

—
Reply to this email directly or view it on GitHub
#1209 (comment).

[tiran]

Oh d... :( I'm deeply sorry for the delay. The re-licensing mail got lost in my huge pile of to-do mails.

Of course I'm fine with re-licensing cryptography. Please go ahead!

[alex]

Just received an email from Timur granting his permission!

[Ayrx]

All set then!

[dlitz]

Awesome!

[alex]

Two things left! We need to make the contributing docs clear, and we need to replace all the license headers. I left the right text for hte headers at home (I'm travelling ATM), so I'll send that PR next week, will try to get the contributing docs done soonish.

[dlitz]

Woot! Thanks so much everyone!