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

[Ben Finney]

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