[pydotorg-www] Licensing contributions (Was: Vanished link for AFL v2.1)
mfoord at python.org
Thu May 20 23:14:22 CEST 2010
On 20/05/2010 21:53, anatoly techtonik wrote:
> On Thu, May 20, 2010 at 10:22 PM, A.M. Kuchling<amk at amk.ca> wrote:
>> On Thu, May 20, 2010 at 09:47:33PM +0300, anatoly techtonik wrote:
>>> What is the trend about AFL?
>>> Isn't PSF the official license of all Python stuff?
>> Yes, the PSF uses its own license for material where the PSF holds the
>> But when a person signs a contributor form, which is saying "I grant
>> the PSF the right to use my code/patch/whatever under some license",
>> what license is the *person* -- not the PSF! -- using?
> Isn't it a common sense assumption that if you want contribution to be
> the part of this particular software you agree that it will be
> redistributed alike? If you want other terms - you need to say it
> explicitly. I can only see a point when you want to take GPL code from
> me and then make it Public Domain in the future. As in this case I may
> refuse to contribute, you need to bind me as developer with obscure
> license terms.
The PSF needs the source code (the intellectual property) of Python to
be secure. This means we need to *know* we have the legal right to
distribute it. To ensure this the core developers (all committers) sign
a contributor agreement explicitly licensing their contributions to the
PSF under a choice of two licenses that the PSF lawyers determined gave
the PSF the rights it needs to both redistribute and relicense the whole
of the Python source code. If any developer isn't willing to license
their contributions to the PSF under these well known and OSF recognised
open source licenses then they are free to not contribute to Python, but
that would be very odd - to want to contribute to an open source project
but not be willing to license your contributions under a compatible open
If you read the contributor agreement (which is not long or *overly*
legally worded) then you will see that contributors still own their
contributions and are free to relicense them under the GPL, declare them
public domain, or sell them commercially if they so desire. This is why
companies like google, canonical and Microsoft have been able to agree
to and sign the PSF contributor agreements.
>> They need to use a license that lets the PSF take the code and change
>> the license on it to be the PSF license. The PSF license doesn't
>> actually say re-licensing is allowed. The Apache 2.0 and Academic
>> Free licenses both explicitly allow re-licensing, so that's why
>> contributors need to pick one of them.
> Does the sentence that Apache 2.0 explicitly allow re-licensing really
> mean that I can drop it or replace with GPL, MIT or put in Public
> Domain at all?
> Why AFL?
> Why MIT or BSD is inappropriate?
> What about CC?
> Was there some discussion about it?
It was decided by the PSF under the advice of their lawyers quite some
time ago. Why do you care about this?
> Did you ask PSF contributors what license do they prefer (feel more
> comfortable) to see core Python stuff in?
Python core stuff is under the PSF license. This has some rather odd
terms as at various times parts of the source code have been owned by
several commercial entities. That imposes certain restrictions about the
license wording that the PSF is *able* (legally) to use. The only
important thing is that the PSF license is a GPL compatible OSF
recognised open source license allowing commercial and non-commercial
> Why PSF can't change license PSF License 2 to PSF License 3 that is
> simpler and allow contributions?
What are you talking about - the PSF license is the license that the
Python source code is *distributed* under. It is very liberal, but has
nothing to do with contributions to Python.
> What PSF is afraid of in 2010 to maintain such complex license?
> Can you specify in simple words what is required from developers and
> record it as extension to some simple license like
> Please do not give me links. I am not a lawyer and not an English
> native, so I'd like to know the official point of PSF in developer's
It is a restriction caused by the history of how Python was developed.
The obscure wording of the PSF license does not affect what users are
free to do with Python (beyond its specific licensing conditions) and
isn't related to the question of how contributions are made because we
don't use the PSF license for that.
> I bet many have question about licensing and AFL in
> particular, because I, for example, found AFL to be the most
> contradicting license at all:
Anyone with questions is free to ask. I've rarely heard any questions
though, it doesn't seem to be a problem in practise beyond the
beauracracy of getting potential contributors to sign an agreement in
the first place.
> quoting Wikipedia (the license text is too complex for me):
> AFL versions 1.2 and 2.1 are not compatible with the GNU GPL. The
> Free Software Foundation does not consider version 3.0 to be
> compatible with the GPL, though Eric S. Raymond (a co-founder of
> the OSI) contends it is GPL compatible. In late 2002, an OSI
> working draft considered it a "best practice" license. In mid
> 2006, however, the OSI's License Proliferation Committee found it
> "redundant with more popular licenses", specifically version 2 of
> the Apache Software License.
> If "The mission of the foundation is to foster development of the
> Python community" - it should listen to developers, or better allow
> them freedom to use, exchange and contribute. Demanding or confusing
> them only increases FUD factor with D standing for dissatisfaction.
> Licensing preferences in general are often personal and demotivating,
All those things are possible under the current licensing situation. If
you really want to claim it is *actually* a problem you will have to
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
More information about the pydotorg-www