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).
">

(original) (raw)

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)