On Mon, Jul 5, 2010 at 11:04, anatoly techtonik <techtonik@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/LI...
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.