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

Relicense as dual Apache / BSD 2 clause #1209

Closed
alex opened this Issue Jul 2, 2014 · 72 comments

Comments

Projects
None yet
@alex
Member

alex commented Jul 2, 2014

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ò

@alex alex added this to the Fifth Release milestone Jul 2, 2014

@alex alex added the administrative label Jul 2, 2014

@alex alex self-assigned this Jul 2, 2014

@public

This comment has been minimized.

Member

public commented Jul 2, 2014

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

This comment has been minimized.

Spindel commented Jul 2, 2014

My permission is given. Go for it!

@sholsapp

This comment has been minimized.

Contributor

sholsapp commented Jul 2, 2014

My permission is given.

@alex

This comment has been minimized.

Member

alex commented Jul 2, 2014

@Spindel embarrassing question, but which name are you?

@lvh

This comment has been minimized.

Member

lvh commented Jul 2, 2014

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

@mrjefftang

This comment has been minimized.

Contributor

mrjefftang commented Jul 2, 2014

My permission is given.

@Lukasa

This comment has been minimized.

Member

Lukasa commented Jul 2, 2014

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

This comment has been minimized.

Contributor

anotherthomas commented Jul 2, 2014

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

This comment has been minimized.

Member

alex commented Jul 2, 2014

@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

This comment has been minimized.

Contributor

anotherthomas commented Jul 2, 2014

@alex I see. Thanks.

@reaperhulk

This comment has been minimized.

Member

reaperhulk commented Jul 2, 2014

My permission is given. Checked myself.

@dstufft

This comment has been minimized.

Member

dstufft commented Jul 2, 2014

I give my permission.

@muattiyah

This comment has been minimized.

Contributor

muattiyah commented Jul 2, 2014

My permission is given.

1 similar comment
@ashfall

This comment has been minimized.

Contributor

ashfall commented Jul 2, 2014

My permission is given.

@harleyk

This comment has been minimized.

Contributor

harleyk commented Jul 2, 2014

I give my permission.

@dlitz

This comment has been minimized.

dlitz commented Jul 2, 2014

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

This comment has been minimized.

Member

dstufft commented Jul 2, 2014

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

@Spindel

This comment has been minimized.

Spindel commented Jul 2, 2014

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

@exarkun

This comment has been minimized.

Member

exarkun commented Jul 2, 2014

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

This comment has been minimized.

Contributor

nryoung commented Jul 2, 2014

Sounds good to me: My permission is given

@koobs

This comment has been minimized.

Contributor

koobs commented Jul 3, 2014

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

@Ivoz

This comment has been minimized.

Contributor

Ivoz commented Jul 3, 2014

Permission from me.

@Ayrx

This comment has been minimized.

Contributor

Ayrx commented Jul 3, 2014

Go for it.

@manuels

This comment has been minimized.

Contributor

manuels commented Jul 3, 2014

My permission is given. ;)

@public

This comment has been minimized.

Member

public commented Jul 3, 2014

@dlitz Is that conversation with the Debian maintainer public?

@dlitz

This comment has been minimized.

dlitz commented Jul 3, 2014

@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

This comment has been minimized.

Member

lvh commented Jul 3, 2014

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

@Ayrx Ayrx referenced this issue Oct 28, 2014

Closed

What should our license be? #57

5 of 5 tasks complete

@hynek hynek referenced this issue Oct 28, 2014

Closed

Relicense under dual Apache2/MIT #28

6 of 6 tasks complete
@wallrj

This comment has been minimized.

Contributor

wallrj commented Oct 28, 2014

Permission granted.
-Richard Wall

@lahwran

This comment has been minimized.

lahwran commented Oct 28, 2014

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

This comment has been minimized.

Member

dstufft commented Oct 28, 2014

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

@glyph

This comment has been minimized.

Contributor

glyph commented Oct 29, 2014

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

@alex

This comment has been minimized.

Member

alex commented Oct 29, 2014

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

This comment has been minimized.

Contributor

glyph commented Oct 29, 2014

@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

This comment has been minimized.

Member

alex commented Oct 29, 2014

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

This comment has been minimized.

Contributor

tiran commented Oct 29, 2014

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

This comment has been minimized.

Member

alex commented Oct 31, 2014

Just received an email from Timur granting his permission!

@Ayrx

This comment has been minimized.

Contributor

Ayrx commented Oct 31, 2014

All set then!

alex added a commit to alex/cryptography that referenced this issue Oct 31, 2014

reaperhulk added a commit that referenced this issue Nov 1, 2014

Merge pull request #1457 from alex/new-license
Added new license files. Refs #1209
@dlitz

This comment has been minimized.

dlitz commented Nov 5, 2014

Awesome!

@alex

This comment has been minimized.

Member

alex commented Nov 6, 2014

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.

alex added a commit to alex/cryptography that referenced this issue Nov 6, 2014

reaperhulk added a commit that referenced this issue Nov 7, 2014

Merge pull request #1460 from alex/document-contributing
Refs #1209 -- clearly state the licensing requirements in the docs

alex added a commit to alex/cryptography that referenced this issue Nov 7, 2014

reaperhulk added a commit that referenced this issue Nov 7, 2014

Merge pull request #1461 from alex/changelog-license
Refs #1209 -- added a changelog entry for our license change

alex added a commit to alex/cryptography that referenced this issue Nov 16, 2014

@dlitz

This comment has been minimized.

dlitz commented Nov 17, 2014

Woot! Thanks so much everyone!

spang added a commit to nylas/nylas-production-python that referenced this issue Aug 18, 2015

Dual license under Apache 2 and MIT
Seems to be best practice in the Python community for licensing
libraries. See e.g:

pyca/cryptography#1209
https://structlog.readthedocs.org/en/stable/license.html

@dstufft dstufft referenced this issue Oct 14, 2015

Closed

Relicense as dual Apache / BSD 2 clause #42

6 of 13 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment