From ben+python at benfinney.id.au  Fri Apr 22 02:15:55 2016
From: ben+python at benfinney.id.au (Ben Finney)
Date: Fri, 22 Apr 2016 16:15:55 +1000
Subject: [Python-legal-sig] Making it possible to accept contributions
 without CLA
References: <85sigpiub8.fsf@benfinney.id.au> <5486C0BD.3020903@python.org>
 <85bnncind3.fsf@benfinney.id.au> <548761C9.5080508@python.org>
Message-ID: <85zismman8.fsf@benfinney.id.au>

Howdy M.A.,

I noticed that there were questions here you'd asked me that I hadn't
yet responded to.

"M.-A. Lemburg" <mal at python.org> writes:

> On 09.12.2014 21:23, Ben Finney wrote:
> > 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.

Yes. For that, though, no special powers need be granted to the PSF;
only a declaration from copyright holders.

> 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.

The justification to avoid carrying many distinct sets of license
conditions is a laudable one: proliferation of license conditions in a
code base is to be minimised.

That justification is met by requiring contributions to be licensed
under Apache License 2.0: any new code comes in licensed to all
recipients under that specific set of license conditions.

So I don't see that goal, laudable as it is, offers special
justification to require a CLA in any contributions.

> >> 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.

Thanks. What existing documentation is there on code in the Python code
base that is licensed incompatibly with the Apache License 2.0?

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

I don't see that question answered in what you wrote 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 ?

Because I choose not to grant the PSF special powers in my
contributions, and (absent legacy license conditions) I don't see that
the PSF needs special powers in those contributions.

> The only two extra things we ask constibutors in the CLA is to
> a) identify themselves as authorized to enter the agreement

This is equivalent to identifying oneself as copyright holder in the
contribution. This identification grants no special powers to any other
party, so is unobjectionable.

A ?Certificate of Origin? meets this need without granting any special
powers to anyone. See for example the Samba Project's DCO process
<URL:https://www.samba.org/samba/devel/copyright-policy.html>.

> b) allow the PSF to relicense their code under an open source
>    license.

Since the PSF has full permission under the Apache License 2.0 in the
contribution ? like any other recipient of that contribution ? this
additional power to the PSF does not appear justified by anything except
the legacy code licensed incompatibly.

So cleaning the code base of code under those legacy conditions (by
re-implementing and removing, or by re-licensing under compatible
conditions) would be a simplification of the license terms, and would
make feasible dropping the CLA requirement. Right?

> 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.

The paper trail you described ? which can be composed of Certificate of
Origin just as well as any special agreement document ? accomplishes
this. Is that right?

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

Not an agreement, no. Requesting from the contributor a Certificate of
Origin grants no special powers to anyone.

> 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.

That's the concern which I draw attention to. The PSF already has all
the same permissions in every contribution as every recipient of Python.
Extra powers in the work need to be justified, and I don't see it.

-- 
 \         ?I was arrested today for scalping low numbers at the deli. |
  `\                     Sold a number 3 for 28 bucks.? ?Steven Wright |
_o__)                                                                  |
Ben Finney


From mal at egenix.com  Fri Apr 22 09:27:38 2016
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 22 Apr 2016 15:27:38 +0200
Subject: [Python-legal-sig] Making it possible to accept contributions
 without CLA
In-Reply-To: <85zismman8.fsf@benfinney.id.au>
References: <85sigpiub8.fsf@benfinney.id.au> <5486C0BD.3020903@python.org>
 <85bnncind3.fsf@benfinney.id.au> <548761C9.5080508@python.org>
 <85zismman8.fsf@benfinney.id.au>
Message-ID: <571A26CA.3070608@egenix.com>

On 22.04.2016 08:15, Ben Finney wrote:
> Howdy M.A.,
> 
> I noticed that there were questions here you'd asked me that I hadn't
> yet responded to.

Wow, after 1.5 years :-)

> "M.-A. Lemburg" <mal at python.org> writes:
> 
>> On 09.12.2014 21:23, Ben Finney wrote:
>>> 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.
> 
> Yes. For that, though, no special powers need be granted to the PSF;
> only a declaration from copyright holders.

This wouldn't allow the PSF to defend those copyrights, though,
and so would fall short of the intent.

>> 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.
> 
> The justification to avoid carrying many distinct sets of license
> conditions is a laudable one: proliferation of license conditions in a
> code base is to be minimised.
> 
> That justification is met by requiring contributions to be licensed
> under Apache License 2.0: any new code comes in licensed to all
> recipients under that specific set of license conditions.
> 
> So I don't see that goal, laudable as it is, offers special
> justification to require a CLA in any contributions.

This would add the Apache License to our license stack. I don't
think that's in the interest of our users or developers who
have signed the CLA to make it possible for the PSF license
to be used on the code.

Also note that the Apache License include a patent clause
which we currently don't have in the PSF license, so it's not
clear whether we could put the Apache License on the stack,
since it would only be valid for part of the code base (those
parts for which the PSF did a receive a CLA using the Apache
License).

>>>> 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.
> 
> Thanks. What existing documentation is there on code in the Python code
> base that is licensed incompatibly with the Apache License 2.0?

Apart from the notices in the code, we only have the repository history.

If you combine this with existing CLAs and older CLAs granted in other
forms, this should allow documenting which licenses apply to which parts
and where the original copyright lies.

In several cases, the copyright will be split between multiple authors,
though, so you may still have multiple licenses apply to various parts.

>>>> 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 :-)
> 
> I don't see that question answered in what you wrote above.

I was referring defending of the IP rights in Python.

If the PSF does not have any rights in Python, apart from being
a user of the Apache License, then the PSF wouldn't be able
to defend any rights :-)

>>>> 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 ?
> 
> Because I choose not to grant the PSF special powers in my
> contributions, and (absent legacy license conditions) I don't see that
> the PSF needs special powers in those contributions.
> 
>> The only two extra things we ask contributors in the CLA is to
>> a) identify themselves as authorized to enter the agreement
> 
> This is equivalent to identifying oneself as copyright holder in the
> contribution. This identification grants no special powers to any other
> party, so is unobjectionable.
> 
> A ?Certificate of Origin? meets this need without granting any special
> powers to anyone. See for example the Samba Project's DCO process
> <URL:https://www.samba.org/samba/devel/copyright-policy.html>.
> 
>> b) allow the PSF to relicense their code under an open source
>>    license.
> 
> Since the PSF has full permission under the Apache License 2.0 in the
> contribution ? like any other recipient of that contribution ? this
> additional power to the PSF does not appear justified by anything except
> the legacy code licensed incompatibly.
> 
> So cleaning the code base of code under those legacy conditions (by
> re-implementing and removing, or by re-licensing under compatible
> conditions) would be a simplification of the license terms, and would
> make feasible dropping the CLA requirement. Right?

No, we would never be able to adapt the Python license to
new developments and be forever stuck with the
Apache License 2.0.

>> 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.
> 
> The paper trail you described ? which can be composed of Certificate of
> Origin just as well as any special agreement document ? accomplishes
> this. Is that right?

I'm not sure what you are asking here (I seem to have commented
on something that is cut away).

>>> 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 :-)
> 
> Not an agreement, no. Requesting from the contributor a Certificate of
> Origin grants no special powers to anyone.
> 
>> 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.
> 
> That's the concern which I draw attention to. The PSF already has all
> the same permissions in every contribution as every recipient of Python.
> Extra powers in the work need to be justified, and I don't see it.

The PSF was originally formed to provide a legal body to protect the IP
rights in Python. It's initial members consisted mostly of the Python
core developers at the time. We wanted our contributions to be
protected by the PSF, which is why we founded it and assigned
rights over to the PSF for this purpose.

I keep getting a feeling that you see the PSF as some 3rd party
in the game which really shouldn't have anything to do with the
Python code base.

This is a reasoning I cannot follow, since it simply doesn't correspond
to why we created the PSF in the first place. Python had gotten
important enough in many of our lives that we wanted to make sure we
increase the bus factor on the IP rights. The PSF serves exactly this
role.

If you don't trust the PSF, that's fine, and there's probably
nothing much I can do to change this :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Apr 22 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
________________________________________________________________________

::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
                      http://www.malemburg.com/