License() release list is imcomplete; intentional?
On 2.7, >>> license() return a text that includes a complete list of releases from 1.6 to 2.7 and stops there Release Derived Year Owner GPL- from compatible? (1) 0.9.0 thru 1.2 1991-1995 CWI yes 1.3 thru 1.5.2 1.2 1995-1999 CNRI yes 1.6 1.5.2 2000 CNRI no 2.0 1.6 2000 BeOpen.com no ... 2.6.5 2.6.4 2010 PSF yes 2.7 2.6 2010 PSF yes Was it intentional to stop with 2.7 and not continue with 2.7.1, etc? On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7. Intentional? It then jumps back to 3.0 and ends with the 'previous' release, 3.3.1. Should 3.3.2 be included in the 3.3.2 list? ... 2.6.4 2.6.3 2009 PSF yes 2.6.5 2.6.4 2010 PSF yes 3.0 2.6 2008 PSF yes 3.0.1 3.0 2009 PSF yes ... 3.2.4 3.2.3 2013 PSF yes 3.3.0 3.2 2012 PSF yes 3.3.1 3.3.0 2013 PSF yes -- Terry Jan Reedy
Le Tue, 17 Sep 2013 11:37:48 -0400, Terry Reedy <tjreedy@udel.edu> a écrit :
On 2.7, >>> license() return a text that includes a complete list of releases from 1.6 to 2.7 and stops there Release Derived Year Owner GPL- from compatible? (1)
0.9.0 thru 1.2 1991-1995 CWI yes 1.3 thru 1.5.2 1.2 1995-1999 CNRI yes 1.6 1.5.2 2000 CNRI no 2.0 1.6 2000 BeOpen.com no ... 2.6.5 2.6.4 2010 PSF yes 2.7 2.6 2010 PSF yes
Was it intentional to stop with 2.7 and not continue with 2.7.1, etc?
On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7. Intentional? It then jumps back to 3.0 and ends with the 'previous' release, 3.3.1. Should 3.3.2 be included in the 3.3.2 list?
... 2.6.4 2.6.3 2009 PSF yes 2.6.5 2.6.4 2010 PSF yes 3.0 2.6 2008 PSF yes 3.0.1 3.0 2009 PSF yes ... 3.2.4 3.2.3 2013 PSF yes 3.3.0 3.2 2012 PSF yes 3.3.1 3.3.0 2013 PSF yes
I don't really understand why the releases should be manually listed. Is it some kind of defensive coding? Regards Antoine.
I don't really understand why the releases should be manually listed. Is it some kind of defensive coding?
I think it's to give people who care about such things all the information they need to make informed decisions. As I recall, the 1.6 series was problematic, because it wasn't actually open source. That's why 2.0 is a derivative of 1.5.2. I doubt there are other licensing weirdities lurking, but better to give people everything they might need, especially if it's not difficult. At this point I think the hard work is done. Release managers or their minions just need to remember to tack on the next line. Skip
On Tue, Sep 17, 2013 at 8:47 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Le Tue, 17 Sep 2013 11:37:48 -0400, Terry Reedy <tjreedy@udel.edu> a écrit :
On 2.7, >>> license() return a text that includes a complete list of releases from 1.6 to 2.7 and stops there Release Derived Year Owner GPL- from compatible? (1)
0.9.0 thru 1.2 1991-1995 CWI yes 1.3 thru 1.5.2 1.2 1995-1999 CNRI yes 1.6 1.5.2 2000 CNRI no 2.0 1.6 2000 BeOpen.com no ... 2.6.5 2.6.4 2010 PSF yes 2.7 2.6 2010 PSF yes
Was it intentional to stop with 2.7 and not continue with 2.7.1, etc?
On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7. Intentional? It then jumps back to 3.0 and ends with the 'previous' release, 3.3.1. Should 3.3.2 be included in the 3.3.2 list?
... 2.6.4 2.6.3 2009 PSF yes 2.6.5 2.6.4 2010 PSF yes 3.0 2.6 2008 PSF yes 3.0.1 3.0 2009 PSF yes ... 3.2.4 3.2.3 2013 PSF yes 3.3.0 3.2 2012 PSF yes 3.3.1 3.3.0 2013 PSF yes
I don't really understand why the releases should be manually listed. Is it some kind of defensive coding?
Worse, it's superstition based on myth. IIRC this table was added when a few core Python developers including myself left CNRI in 2000. We had a bit of an argument about the license (not too much though -- in the end things came out alright). Some lawyer at CNRI thought it was a good idea to record a release history like this with the license, as a defense against whatever claims of ownership to the code someone else might suddenly come up with. Since all I wanted was to get out of there while causing them minimal upset, I told them I'd comply. But that's over 13 years ago now, and I'm not sure if it ever made sense (the internet is a different place than CNRI's lawyers envisioned). Only the top 10 of so lines of the table are in the least interesting (note that it describes a graph). I propose that we truncate the table and add a note saying that all following releases are owned by the PSF, GPL-compatible, and derived from previous PSF-owned and GPL-compatible releases. That should do until the PSF goes out of business (which I hope will never happen -- this is one reason why I wish the conferences were run by a separate entity, to avoid a conference bankruptcy from risking Python's continued open-source status). -- --Guido van Rossum (python.org/~guido)
On Tue, 17 Sep 2013 09:47:48 -0700 Guido van Rossum <guido@python.org> wrote:
IIRC this table was added when a few core Python developers including myself left CNRI in 2000. We had a bit of an argument about the license (not too much though -- in the end things came out alright). Some lawyer at CNRI thought it was a good idea to record a release history like this with the license, as a defense against whatever claims of ownership to the code someone else might suddenly come up with. Since all I wanted was to get out of there while causing them minimal upset, I told them I'd comply. But that's over 13 years ago now, and I'm not sure if it ever made sense (the internet is a different place than CNRI's lawyers envisioned). Only the top 10 of so lines of the table are in the least interesting (note that it describes a graph). I propose that we truncate the table and add a note saying that all following releases are owned by the PSF, GPL-compatible, and derived from previous PSF-owned and GPL-compatible releases. That should do until the PSF goes out of business (which I hope will never happen -- this is one reason why I wish the conferences were run by a separate entity, to avoid a conference bankruptcy from risking Python's continued open-source status).
The PSF isn't technically the copyright holder, so would that pose a significant threat? (at worse the PSF could relicense Python based on the copyright agreements, but Python would still be distributable under the original license) Regards Antoine.
On Tue, Sep 17, 2013 at 10:39 AM, Antoine Pitrou <solipsis@pitrou.net>wrote:
On Tue, 17 Sep 2013 09:47:48 -0700 Guido van Rossum <guido@python.org> wrote:
IIRC this table was added when a few core Python developers including myself left CNRI in 2000. We had a bit of an argument about the license (not too much though -- in the end things came out alright). Some lawyer
at
CNRI thought it was a good idea to record a release history like this with the license, as a defense against whatever claims of ownership to the code someone else might suddenly come up with. Since all I wanted was to get out of there while causing them minimal upset, I told them I'd comply. But that's over 13 years ago now, and I'm not sure if it ever made sense (the internet is a different place than CNRI's lawyers envisioned). Only the top 10 of so lines of the table are in the least interesting (note that it describes a graph). I propose that we truncate the table and add a note saying that all following releases are owned by the PSF, GPL-compatible, and derived from previous PSF-owned and GPL-compatible releases. That should do until the PSF goes out of business (which I hope will never happen -- this is one reason why I wish the conferences were run by a separate entity, to avoid a conference bankruptcy from risking Python's continued open-source status).
The PSF isn't technically the copyright holder, so would that pose a significant threat?
I have no idea. If you want a real answer talk to a lawyer.
(at worse the PSF could relicense Python based on the copyright agreements, but Python would still be distributable under the original license)
But only the PSF has the list of original contributors and their licenses. -- --Guido van Rossum (python.org/~guido)
On Tue, Sep 17, 2013 at 2:45 PM, Glenn Linderman <v+python@g.nevcal.com>wrote:
On 9/17/2013 10:51 AM, Guido van Rossum wrote:
But only the PSF has the list of original contributors and their licenses.
So can that list be made public, and available in multiple archives?
Technically it already is public based on the * next to your name on bugs.python.org. As for a concise list that's more human readable I'm sure it could if someone chose to put the effort in to write the code to make the list.
On Tue, 17 Sep 2013 15:39:25 -0400, Brett Cannon <brett@python.org> wrote:
On Tue, Sep 17, 2013 at 2:45 PM, Glenn Linderman <v+python@g.nevcal.com>wrote:
On 9/17/2013 10:51 AM, Guido van Rossum wrote:
But only the PSF has the list of original contributors and their licenses.
So can that list be made public, and available in multiple archives?
Technically it already is public based on the * next to your name on bugs.python.org. As for a concise list that's more human readable I'm sure it could if someone chose to put the effort in to write the code to make the list.
The list is public in that sense (but probably not complete). However, whatever is considered to be the legal info, including the license the contributor chose, is not in the tracker. That information is in the hands of the PSF secretary, and to my (outsider, and therefore possibly incorrect :) understanding most of it is currently in the form of physical paper in a filing cabinet. I don't know if there is a project to digitize the archives or not, but it would seem like a sensible thing to do, for backup reasons if nothing else (perhaps there are already physical backups, though). --David
On 17/09/2013 16:37, Terry Reedy wrote:
On 2.7, >>> license() return a text that includes a complete list of releases from 1.6 to 2.7 and stops there Release Derived Year Owner GPL- from compatible? (1)
0.9.0 thru 1.2 1991-1995 CWI yes 1.3 thru 1.5.2 1.2 1995-1999 CNRI yes 1.6 1.5.2 2000 CNRI no 2.0 1.6 2000 BeOpen.com no ... 2.6.5 2.6.4 2010 PSF yes 2.7 2.6 2010 PSF yes
Was it intentional to stop with 2.7 and not continue with 2.7.1, etc?
On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7. Intentional? It then jumps back to 3.0 and ends with the 'previous' release, 3.3.1. Should 3.3.2 be included in the 3.3.2 list?
... 2.6.4 2.6.3 2009 PSF yes 2.6.5 2.6.4 2010 PSF yes 3.0 2.6 2008 PSF yes 3.0.1 3.0 2009 PSF yes ... 3.2.4 3.2.3 2013 PSF yes 3.3.0 3.2 2012 PSF yes 3.3.1 3.3.0 2013 PSF yes
To me it looks like Python 2.7 isn't mentioned in the licence for Python 3 because Python 3 is derived from Python 2.6 and Python 2.7 is on a different branch, so it isn't relevant.
On 9/17/2013 11:48 AM, MRAB wrote:
On 17/09/2013 16:37, Terry Reedy wrote:
On 2.7, >>> license() return a text that includes a complete list of releases from 1.6 to 2.7 and stops there Release Derived Year Owner GPL- from compatible? (1)
0.9.0 thru 1.2 1991-1995 CWI yes 1.3 thru 1.5.2 1.2 1995-1999 CNRI yes 1.6 1.5.2 2000 CNRI no 2.0 1.6 2000 BeOpen.com no ... 2.6.5 2.6.4 2010 PSF yes 2.7 2.6 2010 PSF yes
Was it intentional to stop with 2.7 and not continue with 2.7.1, etc?
On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7. Intentional? It then jumps back to 3.0 and ends with the 'previous' release, 3.3.1. Should 3.3.2 be included in the 3.3.2 list?
... 2.6.4 2.6.3 2009 PSF yes 2.6.5 2.6.4 2010 PSF yes 3.0 2.6 2008 PSF yes 3.0.1 3.0 2009 PSF yes ... 3.2.4 3.2.3 2013 PSF yes 3.3.0 3.2 2012 PSF yes 3.3.1 3.3.0 2013 PSF yes
To me it looks like Python 2.7 isn't mentioned in the licence for Python 3 because Python 3 is derived from Python 2.6 and Python 2.7 is on a different branch, so it isn't relevant.
I thought of that, but if that were the reason, nothing after 2.6(.0) should be listed. I think we should follow Guido's idea of truncating after n lines, summarizing the rest, and freezing the file until there is a significant change. -- Terry Jan Reedy
On 09/17/2013 05:37 PM, Terry Reedy wrote:
On 2.7, >>> license() return a text that includes a complete list of releases from 1.6 to 2.7 and stops there Release Derived Year Owner GPL- from compatible? (1)
0.9.0 thru 1.2 1991-1995 CWI yes 1.3 thru 1.5.2 1.2 1995-1999 CNRI yes 1.6 1.5.2 2000 CNRI no 2.0 1.6 2000 BeOpen.com no ... 2.6.5 2.6.4 2010 PSF yes 2.7 2.6 2010 PSF yes
Was it intentional to stop with 2.7 and not continue with 2.7.1, etc?
On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7. Intentional? It then jumps back to 3.0 and ends with the 'previous' release, 3.3.1. Should 3.3.2 be included in the 3.3.2 list?
... 2.6.4 2.6.3 2009 PSF yes 2.6.5 2.6.4 2010 PSF yes 3.0 2.6 2008 PSF yes 3.0.1 3.0 2009 PSF yes ... 3.2.4 3.2.3 2013 PSF yes 3.3.0 3.2 2012 PSF yes 3.3.1 3.3.0 2013 PSF yes
Since there are 3 versions of this table, it's unavoidable that one of them gets out of sync :) * LICENSE * Doc/license.rst * the versions for each release on the website So I wholeheartedly support truncating before 2.2 (which is the first release where all micro versions are PSF owned and GPL compatible) and just saying "2.2 onwards" (or whatever is the best way to say it). cheers, Georg
OK. Let's do it. On Wed, Sep 18, 2013 at 1:54 AM, Georg Brandl <g.brandl@gmx.net> wrote:
On 09/17/2013 05:37 PM, Terry Reedy wrote:
On 2.7, >>> license() return a text that includes a complete list of releases from 1.6 to 2.7 and stops there Release Derived Year Owner GPL- from compatible? (1)
0.9.0 thru 1.2 1991-1995 CWI yes 1.3 thru 1.5.2 1.2 1995-1999 CNRI yes 1.6 1.5.2 2000 CNRI no 2.0 1.6 2000 BeOpen.com no ... 2.6.5 2.6.4 2010 PSF yes 2.7 2.6 2010 PSF yes
Was it intentional to stop with 2.7 and not continue with 2.7.1, etc?
On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7. Intentional? It then jumps back to 3.0 and ends with the 'previous' release, 3.3.1. Should 3.3.2 be included in the 3.3.2 list?
... 2.6.4 2.6.3 2009 PSF yes 2.6.5 2.6.4 2010 PSF yes 3.0 2.6 2008 PSF yes 3.0.1 3.0 2009 PSF yes ... 3.2.4 3.2.3 2013 PSF yes 3.3.0 3.2 2012 PSF yes 3.3.1 3.3.0 2013 PSF yes
Since there are 3 versions of this table, it's unavoidable that one of them gets out of sync :)
* LICENSE * Doc/license.rst * the versions for each release on the website
So I wholeheartedly support truncating before 2.2 (which is the first release where all micro versions are PSF owned and GPL compatible) and just saying "2.2 onwards" (or whatever is the best way to say it).
cheers, Georg
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
Now tracked at http://bugs.python.org/issue19043 Georg On 09/18/2013 04:57 PM, Guido van Rossum wrote:
OK. Let's do it.
On Wed, Sep 18, 2013 at 1:54 AM, Georg Brandl <g.brandl@gmx.net <mailto:g.brandl@gmx.net>> wrote:
On 09/17/2013 05:37 PM, Terry Reedy wrote: > On 2.7, >>> license() return a text that includes a complete list of > releases from 1.6 to 2.7 and stops there > Release Derived Year Owner GPL- > from compatible? (1) > > 0.9.0 thru 1.2 1991-1995 CWI yes > 1.3 thru 1.5.2 1.2 1995-1999 CNRI yes > 1.6 1.5.2 2000 CNRI no > 2.0 1.6 2000 BeOpen.com no > ... > 2.6.5 2.6.4 2010 PSF yes > 2.7 2.6 2010 PSF yes > > Was it intentional to stop with 2.7 and not continue with 2.7.1, etc? > > On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7. Intentional? > It then jumps back to 3.0 and ends with the 'previous' release, 3.3.1. > Should 3.3.2 be included in the 3.3.2 list? > > ... > 2.6.4 2.6.3 2009 PSF yes > 2.6.5 2.6.4 2010 PSF yes > 3.0 2.6 2008 PSF yes > 3.0.1 3.0 2009 PSF yes > ... > 3.2.4 3.2.3 2013 PSF yes > 3.3.0 3.2 2012 PSF yes > 3.3.1 3.3.0 2013 PSF yes
Since there are 3 versions of this table, it's unavoidable that one of them gets out of sync :)
* LICENSE * Doc/license.rst * the versions for each release on the website
So I wholeheartedly support truncating before 2.2 (which is the first release where all micro versions are PSF owned and GPL compatible) and just saying "2.2 onwards" (or whatever is the best way to say it).
cheers, Georg
_______________________________________________ Python-Dev mailing list Python-Dev@python.org <mailto:Python-Dev@python.org> https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
participants (9)
-
Antoine Pitrou -
Brett Cannon -
Georg Brandl -
Glenn Linderman -
Guido van Rossum -
MRAB -
R. David Murray -
Skip Montanaro -
Terry Reedy