The Python licensing situation.

Tue Jun 7 19:20:31 UTC 2011

  [[[ This is a resend.  I originally sent it on May 29th, but it
      never went through due to a moderation snafu on @opensource.org
      lists, and I just found that out recently.  Please follow up to
      this version, even if you have a previous version by private
      mail, so that we can keep the thread together. ]]]

This mail summarizes the Python licensing situation, and contains some
questions to help OSI figure out what to do with the new (well,
upgraded) Python-related licenses recently proposed.

This mail will look complex, but it gets simpler as it goes.  I urge you
to read it straight through and not try to skip around.

There are two separate issues:

  a) The license of Python, the C implementation of a programming
     language, itself.  This license is complex and multi-partite.

  b) The "Python Software Foundation License", a license that can be
     applied to any software, and that tends to be used to license
     software written *in* the Python language.  This license is simple.

Talking about (b) requires background knowledge of (a), so let's start
with (a).  The current OSI-approved Python license is here:

  http://opensource.org/licenses/Python-2.0

It's a multi-part license, consisting of these four parts:

  1) Python Software Foundation License Version 2  (i.e., 2.0)
  2) BeOpen.com License Agreement for Python 2.0
     ("BEOPEN PYTHON OPEN SOURCE LICENSE AGREEMENT VERSION 1" as it is
     confusingly called.  Don't get thrown: remember, the "2.0" refers
     to the version of Python it applies to, and the "1" refers to the
     version of the BeOpen license that this is.)
  3) CNRI License Agreement for Python 1.6.1
  4) CWI License Agreement for Python 0.9.0 through 1.2

Van Lindberg and the PSF have proposed an updated version of this
overall license (see [1] below).  Presumably, SPDX will call the new
version "Python-2.1", so I will use that name hereinafter.

All the differences between Python-2.0 and Python-2.1 are in the first
part, the "Python Software Foundation License" part.  The differences
are minor -- mechanical, really.  They are the result of the PSF
generalizing the PSF license (which is subject (b) of this mail) and
then substituting "Python Software Foundation" and "Python" into the new
text, in place of "<ORGANIZATION>" and "<SOFTWARE>".  I will detail the
changes a bit later in this mail, but they're fairly trivial.

Thus if OSI approves the the new standalone "Python Software Foundation
License" (see [2] below), then OSI approval of Python-2.1 overall should
really be automatic.

(Note there is an odd complication w.r.t. the CNRI portion -- see [3]
below -- but I'll address that later in this mail.)

So now we can move on to (b), the proposed standalone Python Software
Foundation license:

[2] below is Van Lindberg's and the PSF's proposal for the "Python
Software Foundation License Version 2.1".  There is no SPDX name for
this license yet, but "PSF-2.1" seems the obvious call, so I'll refer to
it as "PSF-2.1" hereinafter.  It would also replace the current PSF
section of the (OSI-approved) Python-2.0 multi-part license, at
http://opensource.org/licenses/Python-2.0.

As I said, it's basically just the first part of Python-2.0 with some
mechanical improvements:

  1) PSF-2.1 is generalized.  The default form of the license refers to
     "<ORGANIZATION>" and "<SOFTWARE>", instead of to Python
     specifically.  There's a helpful addendum (not part of the license)
     that gives an example of how to substitute in your software and
     organization.  The addendum uses Python and the Python Software
     Foundation for its examples.

  2) In section 1, the generalization resulted in a text adjustment:
     'using the Software ("Python") in source or binary form', instead
     of 'using this software ("Python") in source or binary form'.

  3) In section 2, a similar textual adjustment was made, plus a
     correction from "i.e." to "e.g.".

All of these changes are improvements; all are minor; none impinge on
any of the factors that led to OSI approval of Python-2.0.

So should OSI approve the proposed PSF-2.1 license?

Possibly.  I have a concern about clause 3:

  3. In the event Licensee prepares a derivative work that is based on
     or incorporates <SOFTWARE> or any part thereof, and wants to make
     the derivative work available to others as provided herein, then
     Licensee hereby agrees to include in any such work a brief summary
     of the changes made to <SOFTWARE>.

I realize this clause is also in Python-2.0, which is already approved.
Nevertheless, it is unclear what burden it places on those who make and
redistribute derivative works.  Unlike a requirement to distribute
source code, which is trivially easy since one always has the source
code in hand, a requirement to summarize changes is a requirement to
engage in a prose exercise of unknown scope.

Furthermore, it's not clear what "include in any such work" means,
technically.  Are version control logs sufficient?  Does it require a
NEWS or CHANGES file in the distributed source tarball?  What about in a
binary distribution of the derived work?  Would a ChangeLog generated
from version control logs be sufficient, or does it really have to be a
human-written summary?  Would a web page summarizing the changes be
sufficient?  Etc, etc.

Anyway, in the days of 'diff' and other automated textual analysis, it
seems unnecessary -- particularly given that the license already
contains trademark protections, and given the tendency of third parties
to supply such summaries readily whenever the redistributor themselves
fails to.

So, clause (3) could get messy, and is unnecessary in practical terms I
think.

Is PSF wedded to having clause (3) in there?  I'm not sure how much
software out there (besides Python) is already using a version of this
license, but if clause (3) were omitted I don't think it would be too
controversial for them to adjust their copies of the license over time.
(I'm guessing few people are invested in clause (3), and that they're
just using it because it came with the rest of the text.)

Independently of the clause 3 question:

The PSF license seems like a perfectly fine, GPL-compatible open source
license... But is it necessary to have another one?  Van Lindberg said:

> The genesis of this request was the SPDX project wanting a way to
> distinguish between the licenses that apply to different Python
> distributions. As long as we were doing that, I wanted the PSF license
> to become usable standalone so that it is not horribly ambiguous when
> people say they are licensing under the PSF license.

That is a laudable goal.  If there is already a lot of software out
there using this license, then we can't really undo that easily, and I
guess we ought to approve it, though it seems a pity from a license
proliferation standpoint (as Van acknowledged elsewhere, I believe).
Even then, IMHO we should still deal with the clause 3 issue.

Van indicated it is already in use:

> Third, from a Python perspective, we were having people putting stuff
> out "under the Python license" or "under the PSF license."  I want
> that to be well-defined, without having weird things in the license
> like having a specified (and for a non-Python project, wrong)
> copyright holder.

So I guess this license, or one close to it, is in use to some degree?
How much?  If it's not in widespread use, then... might it not be better
to simply have the PSF adopt the nearest already-existing GPL-compatible
license that matches what PSF-2.1 is trying to say, and just substitute
that into Python-2.1 as the first part?

Finally, regarding the CNRI part:

In [3] below, Van proposes a upgrade to the CNRI portion of the
Python-2.0 license (so this would be in Python-2.1).  The changes are
mainly about making it GPL-compatible.  They're actually a bit
interesting, but I don't want to go into them here, because there's a
larger question first:

In http://opensource.org/licenses/Python-2.0, OSI *already has* the
proposed CNRI 1.6.1 (GPL-compatible) text.  So it appears OSI has
already approved this, or else there is a clerical error.  Does anyone
know more about this?

By the way, some might wonder whether modern Python needs any of this
legacy license baggage, since all the CNRI code might be gone.  I did an
analysis (see [4]) and it looks like there *is* still ancient code in
there.  The earliest lines date from 1990, and there are still lines of
code from, say, 1996.  So you don't have to regenerate the annotations,
http://www.red-bean.com/kfogel/tmp/python-source-lines-annotated.out.gz
has them for anyone who wants a closer look.

So I guess the legacy license parts (CNRI, BeOpen, CWI) have to stay,
even for modern versions of Python.  http://docs.python.org/license.html
has some good background on Python licensing dates, as does
http://en.wikipedia.org/wiki/History_of_Python#BeOpen.

Oh, one last thing:

I've sent a separate mail to SPDX, CC'ing license-discuss@, about the
fact that http://www.spdx.org/licenses/Python-2.0 is listed on
http://www.spdx.org/licenses/ as "Python Software Foundation License v2"
when probably it should be called the "Python License v2.0", to avoid
further confusion between the license of Python itself (Python-2.0,
Python-2.1) and the generalized license put out by the Python Software
Foundation (PSF-2.1).

-Karl

[1] "FOR APPROVAL: The Python License"
http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:16983:201103:hoebdlpgfkcojpiljlkh

[2] "FOR APPROVAL: The Python Software Foundation License (PSF License)"
http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:16982:201103:epkohmakcbkdidkgbnoa

[3] "FOR APPROVAL: The CNRI License Agreement for Python 1.6.1"
http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:16981:201103:inockgicopfdiemlioea

[4] Try it yourself with this series of commands:

    $ hg clone http://hg.python.org/cpython
    $ cd cpython/
    $ find . -type f | grep -v ".hg/" | xargs hg annotate -d \
        >> python-source-lines-annotated.out
    $ cat python-source-lines-annotated.out | cut -d " " -f 5 | sort | uniq
    1990
    1991
    1992
    1993
    1994
    1995
    1996
    1997
    1998
    1999
    2000
    2001
    2002
    2003
    2004
    2005
    2006
    2007
    2008
    2009
    2010
    2011
    $ 