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)