[Python-legal-sig] Making it possible to accept contributions without CLA

[M.-A. Lemburg]

On 09.12.2014 21:23, Ben Finney wrote:
> "M.-A. Lemburg" <mal at python.org> writes:
> 
>> The purpose of the contrib forms is to allow the PSF to relicense the
>> work under an open source license we see fit (at the moment the PSF v2
>> license).
> 
> I'm going to assume, then, that if this need to relicense contributions
> under the PSF license did not exist, the CLA would not be required. Is
> that right?

No. In order for the PSF to be able to defend the IP in court,
we have to have a paper trail for all IP in the Python
distribution.

Note that IP that's well separated such as a single module, or
a library, can be handled in a different way, if there's no alternative,
but our preference generally is to be able to relicense all
contributions in order to avoid having to carry along too many
licenses.

>> This was done in order to avoid adding more licenses to the Python
>> distribution.
> 
> Okay. What about removing existing license conditions? In particular,
> those incompatible with the incoming (Apache License 2.0) license?

That's only possible by identifying and reimplementing the code in
question.

>>> That license is a collection of terms and conditions from software
>>> components in Python. Which specific components would be
>>> incompatible with contributions licensed simply under Apache 2.0
>>> license, without any CLA?
>>
>> That's really the wrong question to ask. As you know, one of the
>> contrib form licenses is the Apache 2.0 license, so as contributor you
>> can license the code under the Apache 2.0 license to the PSF and
>> additionally give the PSF the right to relicense the code under
>> different terms.
> 
> If there were no longer any code incompatible with Apache License 2.0 in
> Python, then contributors would not need to give PSF that special power.
> Right?

No; see above :-)

>> To be clear: We currently have no motivation to change the Python
>> license terms to Apache 2.0 (or rather add the Apache 2.0 license to
>> the stack).
> 
> I'm presenting such a motivation: the ability to accept contributions
> licensed under Apache License 2.0, without needing to obtain a CLA from
> the contributor.

Why would you not want to sign a CLA if your code is under the
Apache 2.0 license already ?

The only two extra things we ask constibutors in the CLA is to
a) identify themselves as authorized to enter the agreement, and
b) allow the PSF to relicense their code under an open source
   license.

Note that the contributor does not lose the copyright to the
code. The CLA is not a copyright transfer.

>>> If some persons were to do the work of replacing code licensed under
>>> such incompatible terms (such as the CNRI terms) with code licensed
>>> to everyone under Apache 2.0 terms, would that be sufficient to then
>>> drop the PSF's requirement for a CLA?
>>
>> No, because we don't want to be stuck with this single license choice
>> forever and we don't want to have to contact each an every contributor
>> when changing the license.
> 
> The Apache License 2.0 is compatible with a wide range of free-software
> license conditions, including the conditions of many licenses in works
> already in Python (such as ‘http.cookie’ and others).
> 
> If all the code in Python were under such licenses, the PSF could choose
> to license Python as a whole under any license conditions compatible
> with that set, without needing to contact any contributor.

Right, but that way we'd lose the possibility to defend the IP
in court, since all the Apache license does is mention that
each individual contributor gives a copyright license.

As a result, we'd have to get the contributors to defend the IP,
which would greatly weaken the position in court.

>> Also note that the CLAs make sure that the contributor is actually
>> licensing code that he or she owns to the PSF. This is different from
>> just adding a license to a code repository.
> 
> That is different, yes. The PSF does not need any special powers for
> that; the contributor can be asked merely for some certification they
> have the authority to grant Apache License 2.0 in their contribution.
> 
> So that's a separate need from the CLA, and no CLA is needed for that.

Well, it's an agreement which a contributor would have to sign
before having the contribution accepted in the code base, so
it's a CLA as well :-)

>> I don't see how this could happen, simply because the Apache 2.0
>> license does not give us the right to relicense the code under a
>> different license.
> 
> Yes, it does: Apache License 2.0 §2 explicitly grants the recipient
> (PSF, in this case) the freedom to sublicnese the work.

Sublicense yes, but not relicense under different terms.

A sublicense always has to be at least as restrictive as the
original license, so e.g. we could not remove the requirement
to include a NOTICE file (if the contribution contains such
a file).

We could, for example, not relicense such code under the PSF
license v2, because it doesn't have any such requirements
or the patent license. The latter is one of the reasons why
the CLA does not include the PSF license as initial license.

> So, subject to the other terms in Apache License 2.0, PSF is free to
> grant some other license compatible with Apache License 2.0, such as
> GPLv3 or Expat or BSD 2-clause, etc.

See above.

>> The PSF needs to be able to defend the IP rights in Python and
>> without proper legal setups, we cannot fulfill this role.
> 
> Given that contributions under Apache License 2.0 explicitly grant PSF
> the freedom to choose a different, compatible license for
> redistribution, I think this is already addressed.
> 
> If I understand correctly, the only barrier to actually doing this is
> some existing components in Python that are under license conditions
> incompatible with Apache License 2.0.

This is true for all the code that was not contributed under the
CLA. All code submitted under CLA can be freely relicensed under
e.g. the Apache 2.0 license, should the PSF decide to do so.

However, even with Python completely under the Apache 2.0 license,
we'd most likely still want to keep the CLA process, because it
gives us more flexibility for the future.

By being able to relicense the code, we can change the license to a
more modern one without having to reach out to all contributors, so
a major pain in open source relicensing is solved by the CLAs.

Nowadays, signing a CLA can be done electronically, so it's not
much of a burden on the contributors anymore. In the early days,
you had to wet sign it, fax and/or postal mail it :-)

-- 
Marc-Andre Lemburg
Director
Python Software Foundation
http://www.python.org/psf/