Stefan Behnel, 10.08.2013 06:32:

Tal Einat, 09.08.2013 23:24:

...

It would be helpful if those who follow this list (and perhaps other forums, e.g. python-dev which I don't read) could point out (even just by headline) some often discussed and rejected proposals. I'll go over the archives later, but a list of things to look for would help.

This is relevant:

http://www.python.org/dev/peps/pep-3099/

BTW, the FAQ should go into wiki.python.org, I'd say. Stefan

Tshepang Lekhonkhobe, 10.08.2013 12:36:

On Sat, Aug 10, 2013 at 10:41 AM, Stefan Behnel wrote:

...

BTW, the FAQ should go into wiki.python.org, I'd say.

Official docs look a lot better than the (super-ugly) wiki. rST is also a lot nicer to work with (or I'm just used to it).

Anyways, what's the advantage of moving stuff to the wiki?

That it can be edited by "normal" people? Stefan

Tshepang Lekhonkhobe writes:

On Sat, Aug 10, 2013 at 12:39 PM, Stefan Behnel wrote:

...

Tshepang Lekhonkhobe, 10.08.2013 12:36:

...

Anyways, what's the advantage of moving stuff [from official Python documentation] to the wiki?

That it can be edited by "normal" people?

So, "normal" people are those who can't be bothered to report the issue, and propose an entry (or a fix)?

Normal people are also those who want to avoid the requirement for reading and signing a legal document assigning special rights to the PSF, just to propose a fix. -- \ “It's up to the masses to distribute [music] however they want | `\ … The laws don't matter at that point. People sharing music in | _o__) their bedrooms is the new radio.” —Neil Young, 2008-05-06 | Ben Finney

"Stephen J. Turnbull" writes:

Ben Finney writes:

...

Normal people are also those who want to avoid the requirement for reading and signing a legal document assigning special rights to the PSF, just to propose a fix.

Ben, you are welcome to dislike signing CAs, but please stop spreading FUD about the PSF's CA.

My claim is factual, not FUD, and is entailed within the terms of the contributor agreement.

The rights explicitly specified in the CA actually constitute *restrictions* on the PSF compared to the rights granted by the licenses themselves.

The contributor agreement grants to PSF the unilateral power to redistribute the contribution under “any other open source license approved by [the PSF]”, a power not granted to other recipients of the contribution. So yes, it arrogates special rights to the PSF. Does this make the PSF awful? No, of course not. But I can't pretend it is acceptable to grant special terms to one party in the community. Antoine Pitrou writes:

On Sun, 11 Aug 2013 11:25:41 +1000 Ben Finney wrote:

...

Normal people are also those who want to avoid the requirement for reading and signing a legal document assigning special rights to the PSF, just to propose a fix.

I don't think we ask for a CLA when someone submits a 10-line patch.

Not true, at least in my experience. I have been asked to submit a contributor agreement for small patches to the documentation. Since I cannot in good conscience accept the PSF's requirements, they reject such contributions even under an acceptable all-parties-equal license. -- \ “As soon as we abandon our own reason, and are content to rely | `\ upon authority, there is no end to our troubles.” —Bertrand | _o__) Russell, _Unpopular Essays_, 1950 | Ben Finney

On 8/11/2013 7:19 PM, Ben Finney wrote:

"Stephen J. Turnbull"

...

Ben, you are welcome to dislike signing CAs, but please stop spreading FUD about the PSF's CA.

The PSF has 2 Agreements. One for uploading packages to be redistributed as separate packages on PyPI. The other for accepting contributions to the collective work known CPythonx.y. I do not like parts of the package hosting license, but I agree that Ben's complaints about the contribution license are FUDlike.

My claim is factual, not FUD, and is entailed within the terms of the contributor agreement.

I will disagree below.

...

The rights explicitly specified in the CA actually constitute *restrictions* on the PSF compared to the rights granted by the licenses themselves.

The contributor agreement grants to PSF the unilateral power to redistribute the contribution under “any other open source license approved by [the PSF]”, a power not granted to other recipients of the contribution. So yes, it arrogates special rights to the PSF.

This is deceptive at best. 1. To the extent that a contribution is substantial enough to have copyright, the copyright explicitly remains with the contributor. This is fairly rare for contributions to collective works. 2. A grant of rights in the contribution to PSF only grants those rights to the PSF. WOW. It cannot be otherwise. But since the grant is explicitly not exclusive, the copyright holder is free to grant the same rights in the contributed word to everyone else in the world. It is the choice of the copyright holder whether to grant special rights to the PSF or to grant the same rights to everyone. If you want, write a generic version of the Academic License version whatever, sign it, and post it and a notice on python list that all your contributions to Python via bugs.python.org are available to anyone under the same conditions. Then PSF will definitely not have any special rights to your words. Of course, your generic license can only apply to your words and not anyone else's. 3. The PSF is the copyright holder of the *collective* work and to that extent, it must, as a practical matter. have 'special rights', just as you have special rights to the words you write. If you want to find unfair-to-author's licenses, look everywhere but the open-source software world. -- Terry Jan Reedy

On 11 Aug 2013 19:20, "Ben Finney" wrote:

"Stephen J. Turnbull" writes:

...

Ben Finney writes:

...

Normal people are also those who want to avoid the requirement for reading and signing a legal document assigning special rights to the PSF, just to propose a fix.

Ben, you are welcome to dislike signing CAs, but please stop spreading FUD about the PSF's CA.

My claim is factual, not FUD, and is entailed within the terms of the contributor agreement.

...

The rights explicitly specified in the CA actually constitute *restrictions* on the PSF compared to the rights granted by the licenses themselves.

The contributor agreement grants to PSF the unilateral power to redistribute the contribution under “any other open source license approved by [the PSF]”, a power not granted to other recipients of the contribution. So yes, it arrogates special rights to the PSF.

Does this make the PSF awful? No, of course not. But I can't pretend it is acceptable to grant special terms to one party in the community.

We don't do it for fun - we do it because we don't have the right to relicense some of the previously donated source code, and don't want to spend the lawyer time needed to determine if we can get by without those relicensing rights for new contributions while complying with those existing obligations. People that care about this can either offer to fund the lawyer time to figure out if ALv2 contributions could be accepted without relicensing rights, or accept that Python's complex licensing history means that contributions on a "licence in = licence out" basis are not currently considered feasible, and that a desire to contribute solely to projects with pristine licensing histories is currently incompatible with a desire to contribute directly to CPython. It's a pretty simple choice, and I consider it very poor form to use freely provided PSF communication channels to lobby against a licensing model the PSF believes it is legally obliged to use (choosing not to contribute directly yourself is a different story, as that's an individual ethical decision). Regards, Nick.

Antoine Pitrou writes:

...

On Sun, 11 Aug 2013 11:25:41 +1000 Ben Finney wrote:

...

Normal people are also those who want to avoid the requirement for reading and signing a legal document assigning special rights to the PSF, just to propose a fix.

I don't think we ask for a CLA when someone submits a 10-line patch.

Not true, at least in my experience. I have been asked to submit a contributor agreement for small patches to the documentation. Since I cannot in good conscience accept the PSF's requirements, they reject such contributions even under an acceptable all-parties-equal license.

-- \ “As soon as we abandon our own reason, and are content to rely | `\ upon authority, there is no end to our troubles.” —Bertrand | _o__) Russell, _Unpopular Essays_, 1950 | Ben Finney

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

Nick Coghlan writes:

On 11 Aug 2013 19:20, "Ben Finney" wrote:

...

Does this make the PSF awful? No, of course not. But I can't pretend it is acceptable to grant special terms to one party in the community.

We don't do it for fun - we do it because we don't have the right to relicense some of the previously donated source code, and don't want to spend the lawyer time needed to determine if we can get by without those relicensing rights for new contributions while complying with those existing obligations.

You're right. For the benefit of this forum: I've discussed this with Nick in person, and we agree that the PSF is in a bind on this matter because of awkward ancient license terms on some code in Python. We'd both prefer that the PSF could accept “license in = license out”, that is, no contributor agreement needed. It seems to me that the Apache License grants PSF everything they need, with no need for a contributor agreement; but neither of us has the legal expertise to know, and without that expertise, it's PSF that bears the risk. So, for what it's worth, I don't have ill will to the PSF on this matter.

[…] I consider it very poor form to use freely provided PSF communication channels to lobby against a licensing model the PSF believes it is legally obliged to use (choosing not to contribute directly yourself is a different story, as that's an individual ethical decision).

My apologies, I agree this is inappropriate. -- \ “If you continue running Windows, your system may become | `\ unstable.” —Microsoft, Windows 95 bluescreen error message | _o__) | Ben Finney

Antoine Pitrou writes:

Ben, I respect your distrust of the CLA's terms (or of CLAs in general), but does that mean you wouldn't contribute the python-daemon implementation under a CLA?

I would not sign such a document, correct.

AFAICT it has no chance of landing in the official source tree if you aren't willing to sign a CLA for it.

The work will be licensed to all recipients under the Apache License, and maintained as expected. Could one of the recipients be the person who makes the submission to the PSF for inclusion in Python core? -- \ “Anyone who believes exponential growth can go on forever in a | `\ finite world is either a madman or an economist.” —Kenneth | _o__) Boulding | Ben Finney

On 14.08.2013 05:12, Ben Finney wrote:

Antoine Pitrou writes:

...

Ben, I respect your distrust of the CLA's terms (or of CLAs in general), but does that mean you wouldn't contribute the python-daemon implementation under a CLA?

I would not sign such a document, correct.

...

AFAICT it has no chance of landing in the official source tree if you aren't willing to sign a CLA for it.

The work will be licensed to all recipients under the Apache License, and maintained as expected. Could one of the recipients be the person who makes the submission to the PSF for inclusion in Python core?

Only the copyright holder can enter into the CLA with the PSF, since it grants additional rights that go beyond the initial license, namely that of being able to relicense the code under an open source license. The purpose of the CLA is to prevent further complicating the license details of the Python distribution and to create a complete "paper" trail for each contribution, which tracks the copyright, so that the PSF can defend the IP rights in the distribution. Note that this does not necessarily mean that all code going into the core has to be subject to a CLA. It is still possible to integrate code which has a license compatible with the PSF license, but in general, we'd like to avoid the extra work of having to check and verify such licenses. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 14 2013)

...

...

Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: 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/

On 14.08.2013 11:17, Antoine Pitrou wrote:

Le Wed, 14 Aug 2013 11:03:36 +0200, "M.-A. Lemburg" a écrit :

...

Note that this does not necessarily mean that all code going into the core has to be subject to a CLA. It is still possible to integrate code which has a license compatible with the PSF license, but in general, we'd like to avoid the extra work of having to check and verify such licenses.

Is it possible to "check and verify", say, the common form of the (ultra-simple) MIT license (*)? That would make it a safe starting point for contributors.

(*) http://opensource.org/licenses/MIT

The "check and verify" step would have to be done on a case-by-case basis. We would need to make sure that the the copyright holders mentioned in the license are in fact the copyright holders, check that the license doesn't prevent the PSF from modifying the PSF license to address future concerns and also pay close attention to things like patents. The CLA makes this a lot easier for the PSF and everyone invovled, which is why we have it :-) But we're getting off-topic here. Such things should be discussed on the python-legal list: http://mail.python.org/mailman/listinfo/python-legal-sig -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 14 2013)

...

...

Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: 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/

On Sat, Aug 10, 2013 at 1:36 PM, Tshepang Lekhonkhobe wrote:

On Sat, Aug 10, 2013 at 10:41 AM, Stefan Behnel wrote:

...

BTW, the FAQ should go into wiki.python.org, I'd say.

Official docs look a lot better than the (super-ugly) wiki. rST is also a lot nicer to work with (or I'm just used to it).

Anyways, what's the advantage of moving stuff to the wiki?

The official docs are for documentation of Python itself, and are versioned along with the source code. I don't think that the list of frequently rejected proposals belongs there. In my opinion, the wiki is the right place for such a list. One reason is that this list will need to be updated quite often, which is much easier on a wiki, and has nothing to do with release dates of Python versions. - Tal Einat