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

[Brett Cannon]

On Mon, Jul 5, 2010 at 11:04, anatoly techtonik <techtonik at gmail.com> wrote:
> 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.

But no one also cares that it's 2.6.2. Someone who has editing writes
on the website decided to point the link to then newest version of the
license at that time. But the only difference in the license between
releases is that there is another line recording a release date.
THAT'S IT! So who care if it is 2.6.2 that's listed? That page could
get updated by the release manager for every release, but that's just
another step in an already involved process.

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

But the license stack is required. There is code in Python that dates
back to the early 1990s and is covered by the oldest license in there.
Unless an explicit purge is done to rid Python of all code that falls
under one of the licenses in the stack you cannot just remove it
because it's old. The license is complicated and long because Python's
history is complicated and long.

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

The license is certified by the OSI and is GPL-compatible. If you want
to go through the entire codebase of Python and rewrite it so that it
can be licensed under a BSD-derived one, go for it. I for one, have
better things to do.

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

Out of my over 8 years of participating on python-dev, this is the
first time ANYONE has brought this up. I do not think we are losing
any developers who want to contribute because of the PSF 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"
>

That's going to require a lawyer to sign off on, and I think our
lawyer has better things to do than to worry about trying to make a
little bit of legalese a little clearer for the layperson. It has been
certified by third parties that the PSF license is a BSD-derived
license and is GPL-compatible. That's plenty.

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

It's purely to be nice to the developer if they happen to have some
preference for some reason. The licenses listed allow for us to
immediately relicense any contributed code under the PSF. Which one
makes absolutely no technical difference.

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

Where the hell did you get that POV from? Anyone can sign the
agreement. Practically every person who has shown up to a sprint for
the core has signed that agreement. Just because you have signed it
does not mean you have garnered any special ranking within the Python
community and your opinion is held in higher regard. You get listened
to by earning people's respect, not by signing some piece of paper. If
you feel like people are not taking you seriously enough it's because
you have not earned their respect enough.

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

Because people have better things to do than to try to clarify legal
details when they are not lawyers themselves. Deferring to experts is
what people do to distribute work, and these people giving you these
replies were deferring.

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

What?!? If this was meant as a joke it is not funny in the slightest.

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

It's not needed because we relicense the code under out license
immediately, which is allowed by the AFL.

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

Says you, which is not enough to cause me to want to change how our
expertly designed agreement works.

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

Non-confidence notes? You are the only person who has no faith in our
lawyer, Van Lindberg, who is a recognized and respected intellectual
property lawyer.

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

Of course we don't. We relicense the code for our use. You keep the
copyright, we take the license. If the license changes, it changes. If
you don't like it then don't contribute.

> 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

Seriously? You are worried we are going to spam you or something? If
you can't trust us then don't sign it.

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

And you should not have written it. Basically at this point, knowing
how you feel, I will never touch any of your code knowing you dislike
the idea of it becoming licensed under the PSF license.

I have tried to give you the benefit of the doubt, Anatoly, and have
tried to overlook your general attitude of being somewhat pushy, but
this has pushed me over the edge. If you had some questions about the
license, you should have asked the PSF or here on python-dev instead
of saying that the PSF is not doing a good job. From where I come from
you first try to calmly talk to the people who are doing something
that you have questions about before calling for their overthrowing.

Considering essentially all of the core developers are PSF members you
have just insulted the entire development team by saying they are
doing a poor job in shepherding the project they work on in their
spare time . Good job. And by the way, some of the core developers
also used to be (that's me) or currently are on the board of
directors. Well done indeed.

You have just landed on my python-dev shit list, doubling its size to
two. I hope that some day you can learn how to communicate online more
effectively with a group of people, but for now I am simply deleting
all of your emails.