[Python-Dev] Licensing // PSF // Motion of non-confidence

Mon Jul 5 20:04:28 CEST 2010

Sorry for touching a sore point of if I sound like a boss to someone.
I tried to be as constructive as possible, but politeness was not the
point, so I can only hope you understand.

I do not think PSF does its job well and here is why.

1. Python licensing terms are explained poorly
In order to "advance the Python programming language", and "to support
and facilitate the growth of international community" PSF should be
clear about the legal stuff with no complications. So that even people
without English background can understand the terms.

1.1 Let's start with http://www.python.org/psf/license/
...
    Full text of the Python 2.6.2 license
...
Q: Why 2.6.2?
A: Nobody cares.

Inside referenced doc there are several licenses for Python +
historical note. I remember I've tried to read this file several
times, but only after comparing freeness and beerness of PSF license
to GPL in private talk with Eric I was able to go through this
seriously.
Moving on...

1.2. Mixed content of Python License file
Attached or see
http://code.python.org/hg/branches/release2.7-maint/annotate/41a3e598052f/LICENSE

The file consists of several licenses for multiple versions of Python.
It is an unusual mix that negatively affects understanding. For the
sake of clarity the LICENSE file scope should only be relevant to the
current code. It may include a historical reference to other files if
needed - LICENSE-HISTORY if you like.

It is important to keep LICENSE terms concise for occasional
contributors with skills needed for core development, because for
outsiders there are many open source projects out there.
_For example_, if I see an interesting project with GPL license (Ruby)
and BSD license (Go) and ask myself "What should I choose for the next
time I feel too depressive to spend my weekend watching movies?" - I
will choose Go. I am sure it won't be a waste of my life time, just
because both languages are equally trendy (Ruby sites are truly Gems
in design, and Go presentation at Google IO was awesome), so license
here is deciding factor. Every language has bugs and it is inevitable
that you would like them to be fixed. As it is open source.. yes -
you'll be politely asked to go fix them yourself. If you're an expert
- you will fix them anyway (whatever you share fixes or not is a
different story). Over the time you'll become acquainted with codebase
and of course you will want to use this experience in your daily job
writing code for customers who pay you money for keeping the code
closed. In this case GPL allows you the freedom to rewrite the code
from scratch, BSD - to copy/paste with attribution notice.

If I'd be an outsider - when I'd see PSF license - I'd think - "or no,
thats yet another stupid big license" (YASBL) and move on to the next
news item (this time from pure C universe).

1.3 Python License content

I believe that contents of attached LICENSE-PYTHON-2.x single
copy/paste from LICENSE is enough for understanding and complying for
Python 2.1+ series. Correct me if I wrong. But thanks to Berne
Convention the wording can and should be improved.

I hope the example in 1.2 made it clear that to attract professionals
with strong core development skills, who are able to make quality
contributions and are usually sought after in commercial projects, it
is important to have license terms similar to those people already
familiar and comfortable with, i.e. BSD, MIT/X (or more recent ISC
variant - http://en.wikipedia.org/wiki/ISC_license)

I propose the simplified PSF License v3 that in comparison to PSF v2:
 1.3.1 combines point 4 and 5 to standard "THE SOFTWARE IS PROVIDED
AS-IS ..." copied verbatim from ISC (MIT equivalent) license
 1.3.2 drops point 6 as it lacks the copyright of Captain Obvious
 1.3.3 combines points 8, 1 and 2 into standard ISC (simplified MIT)
header with "and the following conditions are met:" from BSD license
to outline the requirements of PSF in comparison to MIT, BSD and ISC
style licenses
 1.3.4 replaces point 7 with standard "Neither the name of the
<organization>... " from BSD license
 1.3.5 replaces point 3 with "Redistributions of derivative works
should include a brief summary of the changes made to Python"

Full text of license is attached as PSF-LICENSE-v3.
For those who complain that I am not sending patches and only direct
people what to do - LICENSE.patch contains the patch made with diff.py
tool that comes bundled with Python.

Please indicate if and where the license became different from legal
point of view.

2. PSF fails to comply with the terms of Contributors Agreement
http://python.org/psf/contrib/contrib-form/

Note that there are also:
http://python.org/psf/contrib/contrib-form-python/
http://python.org/psf/contrib/contrib-form-jython/
which are reachable by "python contributor's agreement" search query
and it is doesn't clear why there are multiple terms and why they
differ.

-- personal intermezzo --
The fact that Contributors Agreements chapter is here is that I didn't
care about the license much until people sorted me out from Python
community of "those who signed contributor's agreement" into "those
other outcasts that don't have the right to speak" category. I started
to ask questions about licensing stuff, and received a bunch of
negative replies like "why don't you sign the agreement first?",
"we've consulted with lawyer - believe us", "if you are not a lawyer -
why are you asking?". I do not know how many of these replies were
from members of PSF, but they surely were not happy to clarify
anything. I stopped sending patches (because I didn't sign this
agreement) and was accused in unethical behavior like doing myself
nothing and just directing people what to do. To prevent further
allegations I hereby claim that PSF is fully responsible in the
outcome of current situation and in the people pissed off from Python
Community as a result!
Just kidding - a little but tired already.
-- personal intermezzo --

I assume that pydotorg contributions, Python contributions and Jython
are the same contributions, so there is only one Contributors
Agreement, but there is no proof.

PSF doesn't comply with the terms of agreement, because it requires
contributors to submit code under either Apache 2.0 or AFL license.
Both these licenses require to include text of license in
distributions, but so far no Apache or AFL license text is present in
Python source code tree.

PSF also fails to explain they need to receive contributions using two
very verbose licenses, which are almost identical. AFL in fact was
found "redundant" in favor of Apache 2.0 in 2006 by OSI's License
Proliferation Committee. PSF can just say:

"""Contributor understands and agrees that PSF shall have the irrevocable and
perpetual right to make and distribute copies of any Contribution, as well
as to create and distribute collective works and derivative works of any
Contribution."""

That is enough.

Why playing strange Apache 2.0 and AFL games if it is clearly written :
""" Contributor understands and agrees that PSF shall have ... the
right ... to create ... derivative works ... under the Initial License
or under any other open source license approved by a unanimous vote of
the PSF board """

" Contributor understands and agrees ... " - I do not understand, so I
can't sign. Even if I sign CA there is a chance that I (or whoever has
more money) can prove that terms impossible to understand. In this
case all contributors agreements will be deemed invalid. So Python
code is in danger and hence my derived work is in danger too.

That's why I asked who supplied PSF lawyer to create such agreement.
The argumentation that this agreement is legitimate like "Believe us -
we've payed to lawyer" is surely not the thing I expected to hear. If
you want international recognition of legitimacy of such agreements. -
you need the reputation of some legal authority like Ernst&Young or
Deloitte or one of big PSF supporters. In this case PSF will be
eligible for trust instead of non-confidence notes.

There are other reasons that make me hesitate about signing PSF
agreements. For instance PSF doesn't provide any guarantees that:
1. The text of Contributors Agreement won't be changed after I sign it
2. My personal details are properly guarded and won't be shared with
any members of PSF committee or partner companies or any third parties
without my explicit permission

That's all. You may want to reread the first paragraph of the letter
before reply.

P.S. Sorry for not replying to recent threads (i.e. Mercurial) -
writing a letter like these takes from 4 to 12 hours and is very
exhausting.
-- 
anatoly t.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LICENSE
Type: application/octet-stream
Size: 14448 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100705/175394ac/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LICENSE-PYTHON-2.x
Type: application/octet-stream
Size: 2464 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100705/175394ac/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PSF-LICENSE-v3
Type: application/octet-stream
Size: 1182 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100705/175394ac/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LICENSE.patch
Type: application/octet-stream
Size: 3930 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100705/175394ac/attachment-0007.obj>