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.

On Tue, Jul 6, 2010 at 7:05 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:

Normally we don't require contributor agreements for minor patches and other submissions, but given the attitude you have displayed here, I expect we'll make an exception for you (i.e. until you provide evidence of a change of heart by signing a contributor agreement, I'd consider any patches you provide to be on sufficiently legally dubious ground that we aren't in a position to accept them).

Sorry, that crack was uncalled for. You have made positive contributions to the language in the past, and hopefully will be willing and able to do so in the future. Just try to lose the attitude that everyone else is dumber than dirt. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Tue, 6 Jul 2010 07:05:58 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:

As Brett noted, yes, the LICENSE file is complicated, but most people don't bother reading it themselves - they ask what FSF and OSI think of it, and get the answers "BSD style" and "GPL compatible" and are happy with that.

Which is the very wrong thing to do, though. License text should be understandable by non-lawyer people; IIUC OpenBSD has a very sane policy in this respect.

The corporate history is such that the PSF probably doesn't have the legal rights to simplify it

Yes, that's probably the real problem and why it's not of much use to argue about it. You have to trust the PSF (and/or python-dev), because the license text may not be able to change very soon (if any day at all). Regards Antoine.

Neil Hodgson wrote:

anatoly techtonik:

...

The file consists of several licenses for multiple versions of Python. It is an unusual mix that negatively affects understanding.

A simpler license would be better.

There have been moves in the past to simplify the license of Python but this would require agreement from the current rights owners including CWI and CNRI. IIRC not all of the rights owners are willing to agree to a change.

That is the current position. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/

Le mardi 06 juillet 2010 à 12:58 +0900, Stephen J. Turnbull a écrit :

Antoine Pitrou writes:

...

Which is the very wrong thing to do, though. License text should be understandable by non-lawyer people;

This is a common mistake, at least with respect to common-law systems. Licenses are written in a formal language intended to have precise semantics, especially in the event of a dispute going to court. What you wrote is precisely analogous to "a computer program should be understandable to non-programmer people".

The point of free software licenses, though (as opposed to proprietary licenses), is not mainly to go to court (to “protect IP”, as the PSF says - quite naively in my opinion); it is to enable trust among people. Hence the requirement for being readable and understandable by the very people whom they help work together. (and besides, of course, a lawyer's opinion can never make you sure of anything wrt. court testing; lawyers very frequently disagree between themselves, and they are very careful to never provide any formal guarantee; for example, several French “IP” lawyers have argued that free licenses have no value in French authorship right; that hasn't prevented companies from making business with the GPL and other free licenses here)

Guido van Rossum <guido@python.org> writes:

A secondary reasoning for some open source licenses might be to prevent others from running off with the good stuff and selling it for profit. The GPL is big on that […]

Really, it's not. Please stop spreading this canard. The GPL explicitly and deliberately grants the freedom to sell the work for profit. Every copyright holder who grants license under the terms of the GPL is explicitly saying “you can seel this software for any price you like” <URL:http://www.gnu.org/philosophy/selling.html>. Whatever other complaints people may have against the GPL, it's simply *false* to claim what Guido did above. Please stop it. -- \ “We cannot solve our problems with the same thinking we used | `\ when we created them.” —Albert Einstein | _o__) | Ben Finney

Nir Aides <nir@winpdb.org> writes:

I take "...running off with the good stuff and selling it for profit" to mean "creating derivative work and commercializing it as proprietary code" which you can not do with GPL licensed code.

It's the “proprietary“ which is the distinguishing criterion there. The “selling” and “commercial” is totally orthogonal to that. That's the point: selling, and commercial activity in general, is explicitly encouraged and permission granted by the GPL. Too many people speak as though it were otherwise. To those who do: Please stop. -- \ “Following fashion and the status quo is easy. Thinking about | `\ your users' lives and creating something practical is much | _o__) harder.” —Ryan Singer, 2008-07-09 | Ben Finney

On Tue, Jul 6, 2010 at 9:22 AM, Ben Finney <ben+python@benfinney.id.au> wrote:

That's the point: selling, and commercial activity in general, is explicitly encouraged and permission granted by the GPL. Too many people speak as though it were otherwise. To those who do: Please stop.

Please, GPL advocates also spread their own type of FUD, claiming "free as in speech ain't the same thing as free as in beer, people!". While true, the bottom line is that Python being BSD-type enables me to make money with it that I wouldn't make if Python was GPL-type. Moreover, I don't think that GPL license allows money-making that BSD type wouldn't allow. Hence the common point of view saying "BSD-type is more commercial-friendly than GPL". I've written an article last year that, while it doesn't address this issue specifically, it touches it. http://www.hardcoded.net/articles/going_open_source.htm Virgil Dupras

On Tue, 6 Jul 2010 01:58:26 pm Stephen J. Turnbull wrote:

Antoine Pitrou writes:

...

Which is the very wrong thing to do, though. License text should be understandable by non-lawyer people;

This is a common mistake, at least with respect to common-law systems. Licenses are written in a formal language intended to have precise semantics, especially in the event of a dispute going to court. What you wrote is precisely analogous to "a computer program should be understandable to non-programmer people".

You've never used Apple's much-missed Hypertalk, have you? :) Given that Python has often been described as executable pseudo-code, I think it is ironic that you're implying that comprehensibility of language is a bad thing! Python is no less precise in its semantics than (say) APL. There are movements to discourage unreadable legalise in favour of simpler language that is more readable while still being precise. For example, the Canadian Bar Association supports the Plain English Movement: http://en.wikipedia.org/wiki/Plain_Language_Movement and of course excessive formality and legalise is often criticised even by lawyers for *harming* precision. (When even the judge can't work out what you mean, that's a problem.) None of this is to imply that the Python licence is guilty of such excessive legalise. But I think that, to the extent that other priorities and legal obligations permit it, we should always be be open to the idea of improving the readability and comprehensibility of "legal source code".

The fact is, in the U.S. if an ordinary person thinks they understand a license, then it's probably quite unpredictable what a court will say about attempts to enforce it.

I'm not sure that this is a fact or just an opinion, but *my* opinion is that this is a safe bet. Most people in the industry consider that it's generally unpredictable what a court will say about licences in general (particularly the shrink-wrap variety). It's certainly true that the general public generally has no clue about licences, contracts, or legal agreements in general, but then agreements written by lawyers aren't always much better. I've been asked to sign agreements that are nonsensical, e.g. circular definitions where Clause N says to refer to Clause X, and Clause X says to refer to Clause N, or NDAs that prohibited me from doing *anything* with the "confidential information" the other party gave me, including the work they wanted me to do. Or blatantly illegal, e.g. non-compete clauses that don't have a hope in hell of surviving a legal challenge, including one that would have meant that I was agreeing to never work for any person or company in Australia who ever had with a telephone. -- Steven D'Aprano

Steven D'Aprano writes:

On Tue, 6 Jul 2010 01:58:26 pm Stephen J. Turnbull wrote:

...

Licenses are written in a formal language intended to have precise semantics, especially in the event of a dispute going to court. What you wrote is precisely analogous to "a computer program should be understandable to non-programmer people".

You've never used Apple's much-missed Hypertalk, have you? :)

No. I was solving quadratic programs back then, and FORTRAN was much better for that. But I think it's more relevant that my mother tried writing HyperCard stacks, and gave up. On the rare occasions she wanted her computer to do something she couldn't do with MacPaint or MacWrite, she called me. She never complained about me writing programs in BASIC, even though they were totally incomprehensible to her.... And mentioning the "Python as executable pseudo-code" thing, I think you're way overestimating what average non-programmer people can cope with. (I'd be pleased to be proved wrong, especially by the undergrads I teach!!!) As for missing it, why would I when I've got Python?<wink>

On 7/5/2010 11:47 PM, Antoine Pitrou wrote:

The point of free software licenses, though (as opposed to proprietary licenses), is not mainly to go to court (to “protect IP”, as the PSF says - quite naively in my opinion); it is to enable trust among people.

Yes, that is true. Open source licenses are social documents as much as they are legal documents. However, they need to be legally enforceable so as to have their intended social effect.

LD 'Gus' Landis writes:

Yes. The BSD license on FreeBSD has allowed Apple to make MacOS X a completely proprietary product.

That's simply not true. http://www.opensource.apple.com/release/mac-os-x-1064/.

On Jul 6, 2010, at 8:09 AM, Steven D'Aprano wrote:

You've never used Apple's much-missed Hypertalk, have you? :)

on mailingListMessage get the message put it into aMessage if the thread of aMessage contains license wankery put aMessage into the trash end if end mailingListMessage

On Wed, Jul 7, 2010 at 7:05 AM, Terry Reedy <tjreedy@udel.edu> wrote:

Asking contributors to give written licenses in addition to the license implicit in the act of contribution is an act of distrust. It says something like "We worry that you might change you mind and sue, and a court might not immediately toss the suit." So it should not surprise if the occasional person reacts with overt hurt and distrust.

The other (IMO, more important) element to it is that it acts as an assertion that the developer actually *has* the rights to contribute the code they're contributing. So, rather than being worried about someone changing their mind about their contributions (although that's admittedly part of it), we're more concerned that contributors actually think about who owns the copyright on the code they're offering and make sure the appropriate permissions are in place. For example, if you look at some of the code that even Guido has submitted (e.g. pgen2), that's actually come in under Google's contributor agreement, rather than Guido's personal one. Presumably that was work he did on company time, so the copyright actually rests with Google rather than Guido. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Terry Reedy wrote:

Comment on trust. Trust works both ways. So does distrust.

Asking contributors to give written licenses in addition to the license implicit in the act of contribution is an act of distrust. It says something like "We worry that you might change you mind and sue, and a court might not immediately toss the suit." So it should not surprise if the occasional person reacts with overt hurt and distrust.

The written contributor agreements are needed to enable the PSF to defend the IP in the Python software. They are just a legal tool, nothing more. Note that the PSF doesn't relicense the contributed code under the whole license stack. The contributed code is (currently) being relicensed under the PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2 (the top part of the stack), which is a very straight forward BSD-style license. The other licenses in the stack only apply to the code owned by the resp. parties CWI, CNRI, BeOpen and the cast of thousands (which fortunately didn't get to send in their lawyers and still had a very good time). Apart from that, the Python distribution also comes with 3rd party code under various other BSD-style licenses. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 06 2010)

...

...

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

2010-07-19: EuroPython 2010, Birmingham, UK 12 days to go ::: Try our new 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 Wed, Jul 7, 2010 at 2:59 PM, Guido van Rossum <guido@python.org> wrote:

On Tue, Jul 6, 2010 at 11:27 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:

...

For example, if you look at some of the code that even Guido has submitted (e.g. pgen2), that's actually come in under Google's contributor agreement, rather than Guido's personal one. Presumably that was work he did on company time, so the copyright actually rests with Google rather than Guido.

I hope you are misremembering some details. I did that work while at Elemental Security (i.e. before I joined Google). It should have Elemental Security's contributor agreement. I developed that code initially for inclusion in Elemental's product line (as part of a parser for a domain-specific language named "Fuel" which did not get open-sourced -- probably for the better.

Whoops, I got my timeline wrong (it did seem a little off when I wrote it - I think part of my brain was trying to tell me the dates didn't match up). I must have been thinking of something else I was working on recently that had Google's name in the header, most likely the abc module. So apologies for the confusion - just s/pgen2/abc/ in my example to make it line up with my intent :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia