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