Licensing contributions (Was: Vanished link for AFL v2.1)
On Thu, May 20, 2010 at 10:22 PM, A.M. Kuchling <amk@amk.ca> wrote:
On Thu, May 20, 2010 at 09:47:33PM +0300, anatoly techtonik wrote:
What is the trend about AFL? Isn't PSF the official license of all Python stuff?
Yes, the PSF uses its own license for material where the PSF holds the copyright.
But when a person signs a contributor form, which is saying "I grant the PSF the right to use my code/patch/whatever under some license", what license is the *person* -- not the PSF! -- using?
Isn't it a common sense assumption that if you want contribution to be the part of this particular software you agree that it will be redistributed alike? If you want other terms - you need to say it explicitly. I can only see a point when you want to take GPL code from me and then make it Public Domain in the future. As in this case I may refuse to contribute, you need to bind me as developer with obscure license terms.
They need to use a license that lets the PSF take the code and change the license on it to be the PSF license. The PSF license doesn't actually say re-licensing is allowed. The Apache 2.0 and Academic Free licenses both explicitly allow re-licensing, so that's why contributors need to pick one of them.
Does the sentence that Apache 2.0 explicitly allow re-licensing really mean that I can drop it or replace with GPL, MIT or put in Public Domain at all? Why AFL? Why MIT or BSD is inappropriate? What about CC? Was there some discussion about it? Did you ask PSF contributors what license do they prefer (feel more comfortable) to see core Python stuff in? Why PSF can't change license PSF License 2 to PSF License 3 that is simpler and allow contributions? What PSF is afraid of in 2010 to maintain such complex license? Can you specify in simple words what is required from developers and record it as extension to some simple license like http://en.wikipedia.org/wiki/ISC_license? Please do not give me links. I am not a lawyer and not an English native, so I'd like to know the official point of PSF in developer's language. I bet many have question about licensing and AFL in particular, because I, for example, found AFL to be the most contradicting license at all: quoting Wikipedia (the license text is too complex for me): http://en.wikipedia.org/wiki/Academic_Free_License """ AFL versions 1.2 and 2.1 are not compatible with the GNU GPL.[1] The Free Software Foundation does not consider version 3.0 to be compatible with the GPL[1], though Eric S. Raymond (a co-founder of the OSI) contends it is GPL compatible.[3] In late 2002, an OSI working draft considered it a "best practice" license.[4] In mid 2006, however, the OSI's License Proliferation Committee found it "redundant with more popular licenses"[2], specifically version 2 of the Apache Software License. """ If "The mission of the foundation is to foster development of the Python community" - it should listen to developers, or better allow them freedom to use, exchange and contribute. Demanding or confusing them only increases FUD factor with D standing for dissatisfaction. Licensing preferences in general are often personal and demotivating, unfortunately. -- anatoly t.
anatoly techtonik wrote:
They need to use a license that lets the PSF take the code and change the license on it to be the PSF license. The PSF license doesn't actually say re-licensing is allowed. The Apache 2.0 and Academic Free licenses both explicitly allow re-licensing, so that's why contributors need to pick one of them.
Does the sentence that Apache 2.0 explicitly allow re-licensing really mean that I can drop it or replace with GPL, MIT or put in Public Domain at all?
No, the contributor agreement is what adds the right to relicense. Obviously you can't just drop a license willy nilly. That would make the whole thing rather pointless, no? ;-)
Why AFL? Why MIT or BSD is inappropriate? What about CC? Was there some discussion about it?
Yes, extensive review by lawyers. The initial license was chosen based on analysis of how good a legal foundation they made for the transaction. The rights that come to the PSF are those in that license + what the contributor agreement grants. - Stephan
On 20/05/2010 21:53, anatoly techtonik wrote:
On Thu, May 20, 2010 at 10:22 PM, A.M. Kuchling<amk@amk.ca> wrote:
On Thu, May 20, 2010 at 09:47:33PM +0300, anatoly techtonik wrote:
What is the trend about AFL? Isn't PSF the official license of all Python stuff?
Yes, the PSF uses its own license for material where the PSF holds the copyright.
But when a person signs a contributor form, which is saying "I grant the PSF the right to use my code/patch/whatever under some license", what license is the *person* -- not the PSF! -- using?
Isn't it a common sense assumption that if you want contribution to be the part of this particular software you agree that it will be redistributed alike? If you want other terms - you need to say it explicitly. I can only see a point when you want to take GPL code from me and then make it Public Domain in the future. As in this case I may refuse to contribute, you need to bind me as developer with obscure license terms.
The PSF needs the source code (the intellectual property) of Python to be secure. This means we need to *know* we have the legal right to distribute it. To ensure this the core developers (all committers) sign a contributor agreement explicitly licensing their contributions to the PSF under a choice of two licenses that the PSF lawyers determined gave the PSF the rights it needs to both redistribute and relicense the whole of the Python source code. If any developer isn't willing to license their contributions to the PSF under these well known and OSF recognised open source licenses then they are free to not contribute to Python, but that would be very odd - to want to contribute to an open source project but not be willing to license your contributions under a compatible open source license. If you read the contributor agreement (which is not long or *overly* legally worded) then you will see that contributors still own their contributions and are free to relicense them under the GPL, declare them public domain, or sell them commercially if they so desire. This is why companies like google, canonical and Microsoft have been able to agree to and sign the PSF contributor agreements.
They need to use a license that lets the PSF take the code and change the license on it to be the PSF license. The PSF license doesn't actually say re-licensing is allowed. The Apache 2.0 and Academic Free licenses both explicitly allow re-licensing, so that's why contributors need to pick one of them.
Does the sentence that Apache 2.0 explicitly allow re-licensing really mean that I can drop it or replace with GPL, MIT or put in Public Domain at all? Why AFL? Why MIT or BSD is inappropriate? What about CC? Was there some discussion about it?
It was decided by the PSF under the advice of their lawyers quite some time ago. Why do you care about this?
Did you ask PSF contributors what license do they prefer (feel more comfortable) to see core Python stuff in?
Python core stuff is under the PSF license. This has some rather odd terms as at various times parts of the source code have been owned by several commercial entities. That imposes certain restrictions about the license wording that the PSF is *able* (legally) to use. The only important thing is that the PSF license is a GPL compatible OSF recognised open source license allowing commercial and non-commercial redistribution.
Why PSF can't change license PSF License 2 to PSF License 3 that is simpler and allow contributions?
What are you talking about - the PSF license is the license that the Python source code is *distributed* under. It is very liberal, but has nothing to do with contributions to Python.
What PSF is afraid of in 2010 to maintain such complex license? Can you specify in simple words what is required from developers and record it as extension to some simple license like http://en.wikipedia.org/wiki/ISC_license?
Please do not give me links. I am not a lawyer and not an English native, so I'd like to know the official point of PSF in developer's language.
It is a restriction caused by the history of how Python was developed. The obscure wording of the PSF license does not affect what users are free to do with Python (beyond its specific licensing conditions) and isn't related to the question of how contributions are made because we don't use the PSF license for that.
I bet many have question about licensing and AFL in particular, because I, for example, found AFL to be the most contradicting license at all:
Anyone with questions is free to ask. I've rarely heard any questions though, it doesn't seem to be a problem in practise beyond the beauracracy of getting potential contributors to sign an agreement in the first place.
quoting Wikipedia (the license text is too complex for me): http://en.wikipedia.org/wiki/Academic_Free_License """ AFL versions 1.2 and 2.1 are not compatible with the GNU GPL.[1] The Free Software Foundation does not consider version 3.0 to be compatible with the GPL[1], though Eric S. Raymond (a co-founder of the OSI) contends it is GPL compatible.[3] In late 2002, an OSI working draft considered it a "best practice" license.[4] In mid 2006, however, the OSI's License Proliferation Committee found it "redundant with more popular licenses"[2], specifically version 2 of the Apache Software License. """
If "The mission of the foundation is to foster development of the Python community" - it should listen to developers, or better allow them freedom to use, exchange and contribute. Demanding or confusing them only increases FUD factor with D standing for dissatisfaction. Licensing preferences in general are often personal and demotivating, unfortunately.
All those things are possible under the current licensing situation. If you really want to claim it is *actually* a problem you will have to explain how... Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Fri, May 21, 2010 at 12:14 AM, Michael Foord <mfoord@python.org> wrote:
Does the sentence that Apache 2.0 explicitly allow re-licensing really mean that I can drop it or replace with GPL, MIT or put in Public Domain at all? Why AFL? Why MIT or BSD is inappropriate? What about CC? Was there some discussion about it?
It was decided by the PSF under the advice of their lawyers quite some time ago. Why do you care about this?
I was going to dedicate my time to enhance some of pydotorg services. I would like to contribute them under the terms of WTFPL license. From the other side it would be nice (but I do not demand it) to borrow bugfixes from other contributors back, because I will save time for rewriting this stuff for other installations. But I was totally confused by the terms of APL and difference between versions, and differences between Apache 2.0, and PSF license, and the necessity to sign contributors' agreement, send it by mail (yes, real world "postal" mail), perhaps pay a lawyer to validate it? Because everybody can mail you my form. Perhaps I also do not want to disclose my personal details to any of PSF corporation members (of course, because I am a troll). I would like to sign electronic form with my email account. In the end I am the owner, I make all contributions from this account, so the only freedom I gain from signing a contributors' agreement is that if my account is hacked you can immediately send an order to jail me. So, why my email is not enough to sign an agreement?
Why PSF can't change license PSF License 2 to PSF License 3 that is simpler and allow contributions?
What are you talking about - the PSF license is the license that the Python source code is *distributed* under. It is very liberal, but has nothing to do with contributions to Python.
I need to sign contributor's agreement to dedicate my code to PSF, but if I want bugfixes back into my code/library, PSF license seems to directly affect it.
Anyone with questions is free to ask. I've rarely heard any questions though, it doesn't seem to be a problem in practise beyond the beauracracy of getting potential contributors to sign an agreement in the first place.
And how many potential contributors were, ahem, pissed off by this requirement?
All those things are possible under the current licensing situation. If you really want to claim it is *actually* a problem you will have to explain how...
Suggestion to drop AFL and Apache 2.0 licenses and leave only agreement sent with other reply.
Michael Foord
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
I release you. Amen. -- anatoly.
On 21/05/2010 11:36, anatoly techtonik wrote:
On Fri, May 21, 2010 at 12:14 AM, Michael Foord<mfoord@python.org> wrote:
Does the sentence that Apache 2.0 explicitly allow re-licensing really mean that I can drop it or replace with GPL, MIT or put in Public Domain at all? Why AFL? Why MIT or BSD is inappropriate? What about CC? Was there some discussion about it?
It was decided by the PSF under the advice of their lawyers quite some time ago. Why do you care about this?
I was going to dedicate my time to enhance some of pydotorg services.
We have been discussing contributions to Python itself - as far as I know we don't have a system in place for licensing contributions to pydotorg services, although we probably should.
I would like to contribute them under the terms of WTFPL license.
Why do you want to control what license you contribute under? No large open source project that I am aware of allows that, for sensible reasons related to intellectual property protection that have been explained to you.
From the other side it would be nice (but I do not demand it) to borrow bugfixes from other contributors back, because I will save time for rewriting this stuff for other installations. But I was totally confused by the terms of APL and difference between versions, and differences between Apache 2.0, and PSF license, and the necessity to sign contributors' agreement, send it by mail (yes, real world "postal" mail), perhaps pay a lawyer to validate it? Because everybody can mail you my form.
You are *still* fundamentally misunderstanding. There is a big difference between the license that contributions *to the PSF* are made under (which does not affect you) and the license that Python itself (not necessarily or specifically "pydotorg services" whatever they may be) are available under. Please understand this difference before continuing the discussion.
Perhaps I also do not want to disclose my personal details to any of PSF corporation members
If you don't trust the PSF then you probably *shouldn't* contribute. That is pretty fundamental I'm afraid.
(of course, because I am a troll). I would like to sign electronic form with my email account. In the end I am the owner, I make all contributions from this account, so the only freedom I gain from signing a contributors' agreement is that if my account is hacked you can immediately send an order to jail me. So, why my email is not enough to sign an agreement?
Why PSF can't change license PSF License 2 to PSF License 3 that is simpler and allow contributions?
What are you talking about - the PSF license is the license that the Python source code is *distributed* under. It is very liberal, but has nothing to do with contributions to Python.
I need to sign contributor's agreement to dedicate my code to PSF, but if I want bugfixes back into my code/library, PSF license seems to directly affect it.
Nope - incorrect. (You really need to *read* the agreement otherwise you will continue to waste people's time.) Licensing your contributions to the PSF does *not* affect whatever else you may choose to do with your code.
Anyone with questions is free to ask. I've rarely heard any questions though, it doesn't seem to be a problem in practise beyond the beauracracy of getting potential contributors to sign an agreement in the first place.
And how many potential contributors were, ahem, pissed off by this requirement?
None as far as I know - possibly one including you.
All those things are possible under the current licensing situation. If you really want to claim it is *actually* a problem you will have to explain how...
Suggestion to drop AFL and Apache 2.0 licenses and leave only agreement sent with other reply.
You still haven't shown how the current situation is actually a problem. Michael Foord
Michael Foord
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
I release you. Amen.
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 20.05.2010 22:53, schrieb anatoly techtonik:
On Thu, May 20, 2010 at 10:22 PM, A.M. Kuchling <amk@amk.ca> wrote:
On Thu, May 20, 2010 at 09:47:33PM +0300, anatoly techtonik wrote:
What is the trend about AFL? Isn't PSF the official license of all Python stuff?
Yes, the PSF uses its own license for material where the PSF holds the copyright.
But when a person signs a contributor form, which is saying "I grant the PSF the right to use my code/patch/whatever under some license", what license is the *person* -- not the PSF! -- using?
Isn't it a common sense assumption that if you want contribution to be the part of this particular software you agree that it will be redistributed alike? If you want other terms - you need to say it explicitly. I can only see a point when you want to take GPL code from me and then make it Public Domain in the future. As in this case I may refuse to contribute, you need to bind me as developer with obscure license terms.
There's absolutely no "binding" involved. Your code is always yours, and you are free to license it in any other way. *However*, since the code you contribute to Python will be distributed under the Python license, the PSF must be assured that it can do that, now and in the future. This is why you have to release it to *us* under a license that allows this act.
They need to use a license that lets the PSF take the code and change the license on it to be the PSF license. The PSF license doesn't actually say re-licensing is allowed. The Apache 2.0 and Academic Free licenses both explicitly allow re-licensing, so that's why contributors need to pick one of them.
Does the sentence that Apache 2.0 explicitly allow re-licensing really mean that I can drop it or replace with GPL, MIT or put in Public Domain at all? Why AFL? Why MIT or BSD is inappropriate? What about CC?
[etc, etc.] What *I* would really like to know is why you are asking all these questions, esp. in a way that implies that we don't have satisfying answers. Be assured that we have, that they are mostly nontrivial (since legalese is involved), and that until now I haven't heard of any potential contributor taking back his contributions because he was uncomfortable with either initial license offered. Maybe we can discuss the issue again when your contribution form is due? Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEARECAAYFAkv14hgACgkQN9GcIYhpnLA4EgCffbVdQBl3BWPZYW+jRG7oDMxB pL8AoISI88TnpegBaORo84BQGS73CiBN =zXaV -----END PGP SIGNATURE-----
In addition to what others have written, some pointed replies: On Thu, May 20, 2010 at 16:53, anatoly techtonik <techtonik@gmail.com> wrote:
On Thu, May 20, 2010 at 10:22 PM, A.M. Kuchling <amk@amk.ca> wrote:
On Thu, May 20, 2010 at 09:47:33PM +0300, anatoly techtonik wrote:
What is the trend about AFL? Isn't PSF the official license of all Python stuff?
Yes, the PSF uses its own license for material where the PSF holds the copyright.
But when a person signs a contributor form, which is saying "I grant the PSF the right to use my code/patch/whatever under some license", what license is the *person* -- not the PSF! -- using?
Isn't it a common sense assumption that if you want contribution to be the part of this particular software you agree that it will be redistributed alike? If you want other terms - you need to say it explicitly.
It is explicit, in the contributor form. Go read it. Now, please, before replying further.
Does the sentence that Apache 2.0 explicitly allow re-licensing really mean that I can drop it or replace with GPL, MIT or put in Public Domain at all?
No, I believe that is mistaken, as I wrote elsewhere. It's the contributor agreement that allows re-licensing.
Why AFL? Why MIT or BSD is inappropriate?
I believe that was because of the patent grant clause that the AFL has, as does the Apache license.
What about CC? Was there some discussion about it?
There was a lot of discussion years ago, before the Creative Commons existed. And most CC licenses are not appropriate for software anyhow.
Did you ask PSF contributors what license do they prefer (feel more comfortable) to see core Python stuff in? Why PSF can't change license PSF License 2 to PSF License 3 that is simpler and allow contributions? What PSF is afraid of in 2010 to maintain such complex license?
There's an explanation of the history of the license, written in plain English, in the license itself. Go read it.
Can you specify in simple words what is required from developers and record it as extension to some simple license like http://en.wikipedia.org/wiki/ISC_license?
No, not without the agreement of all the rights-holders, some of whom are unwilling to remove their layer from the license stack.
Please do not give me links.
Please don't be a troll. Yes, you are being a troll. Do your own research, or hire a lawyer to explain all this if it's that important to you. Stop wasting our time. -- David Goodger <http://python.net/~goodger>
Even after being accused in trolling I'll continue, because I really want a FAQ on this.
From my side I must apologize for accusing PSF that it doesn't do what it should. The last paragraph sounds strange, it is not really well thought to be sent, and as a result some people may have pissed off instead of answering reasonably.
On Fri, May 21, 2010 at 6:22 AM, David Goodger <goodger@python.org> wrote:
In addition to what others have written, some pointed replies:
On Thu, May 20, 2010 at 09:47:33PM +0300, anatoly techtonik wrote:
What is the trend about AFL? Isn't PSF the official license of all Python stuff?
Yes, the PSF uses its own license for material where the PSF holds the copyright.
But when a person signs a contributor form, which is saying "I grant the PSF the right to use my code/patch/whatever under some license", what license is the *person* -- not the PSF! -- using?
Isn't it a common sense assumption that if you want contribution to be the part of this particular software you agree that it will be redistributed alike? If you want other terms - you need to say it explicitly.
It is explicit, in the contributor form. Go read it. Now, please, before replying further.
http://www.python.org/psf/contrib/contrib-form/ There won't be any question if contribution form didn't contain confusing clauses that only AFL and Apache 2.0 licenses are accepted. Correct me if I wrong, but even if my software is Apache 2.0 licensed, I can not give PSF the right to "create and distribute collective works and derivative works" "under any other open source license approved by a unanimous vote of the PSF board" without consent of all authors. And even Apache 2.0 allows that by default, you still need to comply with its terms, like "4.1. You must give any other recipients of the Work or Derivative Works a copy of this License;". So, to make PSF actions legal towards contributions, you need either: 1. Comply to the terms of Apache 2.0 and AFL licenses (distribute licenses with Python, retain copyright notices, carry prominent notices about changes, etc.) - in this case you don't need any license agreement at all. 2. Consent of all the authors that they agree to submit their work, so that it will become PSF licensed - in this case license doesn't matter. So far I haven't found any Apache 2.0 text in my Python source checkout. Is it because my checkout is partial and covers only Lib and Doc or maybe Python code is not owned by PSF then? I assume that it is because PSF follows path no.2, but also want to protect Python code from patent claims. Why not just include it in agreement in clear text and drop license stuff altogether?
Does the sentence that Apache 2.0 explicitly allow re-licensing really mean that I can drop it or replace with GPL, MIT or put in Public Domain at all?
No, I believe that is mistaken, as I wrote elsewhere. It's the contributor agreement that allows re-licensing.
Why AFL? Why MIT or BSD is inappropriate?
I believe that was because of the patent grant clause that the AFL has, as does the Apache license.
So, as I said - this can be mentioned explicitly in agreement itself. Any other goals PSF is trying to achieve with these contributors' agreements? Perhaps collecting some private data from open source contributors?
What about CC? Was there some discussion about it?
There was a lot of discussion years ago, before the Creative Commons existed. And most CC licenses are not appropriate for software anyhow.
It would be nice to know why. The side effect of this approach is that designers are perhaps not interested in joining Python community at all - their work won't receive due attribution.
Did you ask PSF contributors what license do they prefer (feel more comfortable) to see core Python stuff in? Why PSF can't change license PSF License 2 to PSF License 3 that is simpler and allow contributions? What PSF is afraid of in 2010 to maintain such complex license?
There's an explanation of the history of the license, written in plain English, in the license itself. Go read it.
Layman terms at http://www.python.org/psf/license/ sounds like it is a 2 clause BSD license, but BSD is 10 times smaller. According to license, if I use any Python code from standard library (or documentation), I need to: 1. include copyright "Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Python Software Foundation; All Rights Reserved" 2. include in any such work a brief summary of the changes made This applies even to the example from documentation. But because nobody does it, PSF License Agreement automatically terminates. Therefore nobody is allowed to "to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use Python alone or in any derivative version". It looks like the License contradicts with common sense. Or at least I should stop monitoring changes in Python standard library, because one day I may want to copy paste some snippet to extend it in my app. I used abc.py module from Python 2.6, because it was not present in 2.5. Should I add PSF copyright to my Python app?
Can you specify in simple words what is required from developers and record it as extension to some simple license like http://en.wikipedia.org/wiki/ISC_license?
No, not without the agreement of all the rights-holders, some of whom are unwilling to remove their layer from the license stack.
I am sure Python 3000 could use a different license at least for standard library. Can I ask PSF who are those right-holders, what proposals were made to them and how did they argument their decision? Did they clearly express their interests? Something makes me think that they just need is a proper attribution and PSF could provide this in many ways to reach an agreement on relicensing.
Please do not give me links.
Please don't be a troll. Yes, you are being a troll. Do your own research, or hire a lawyer to explain all this if it's that important to you. Stop wasting our time.
You don't want to waste your time to explain PSF license terms to community members? Or anybody asking for clarification automatically becomes a troll and is not accounted as a part of community? Would PSF accept a donation from me to make this research? If it should not be that important for me - why do you demand me to sign a contributor's agreement? Do not get me wrong. I like Python and want it to become better, like everybody else here. But there are plenty of new and more attractive languages for newcomers out there. Language features, clean docs, site design, pictures, polished community services are as equally important as understanding legal implications in this respect. -- anatoly t.
participants (6)
-
"Martin v. Löwis" -
anatoly techtonik -
David Goodger -
Georg Brandl -
Michael Foord -
Stephan Deibel