FOR APPROVAL - Python License Changes

[Karl Fogel]

Hi, Van.  Your post that started this thread proposed three related
Python-ish licenses for approval:

  1) A legacy "CNRI license for Python 1.6.1"
  2) A new, clean "Python Software Foundation" license 2.1
  3) A "Python License" for Python itself [includes CNRI bits, see (1)]

I'll try to tackle them all together in this mail, but for sanity in
three sections, in the order given above.  All of this is being tracked
in http://projects.opensource.org/redmine/issues/3.  I will also address
license naming issues, as it seems easiest to do that along with
discussion of the licenses themselves.

Okay, first off:

Re (1): legacy "CNRI license for Python 1.6.1"

I've read it over carefully, and it all looks fine, though clause 3 is a
bit worrying.  While I'm not sure it's a showstopper, it's unfortunate:

  > 3. In the event Licensee prepares a derivative work that is based on
  > or incorporates Python 1.6.1 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 Python 1.6.1.

But since the proposed "Python Software Foundation" license (2) has this
exact same clause, and since PSF may have more control over the wording
of that license (as it's not as legacy-ish as the CNRI one), I will
raise the detailed concerns about this clause in the section on (2)
below.  Let's have the substantive discussion about it there, not here.

(Btw, I realize that OSI approved it already, in the CNRI Python
1.6-beta-1 license at http://opensource.org/licenses/pythonpl and in the
related portion of http://opensource.org/licenses/Python-2.0.  This is
just the same language as there, so we'd be hard pressed to reject the
license because of it now.  But read on.)

Regarding naming:

Jill and Tom of SPDX (CC'd) and I had a call.  We'd like to propose that
"CNRI Python Open Source License Agreement" and "CNRI-Python-" be the
long and short identifiers respectively, with the suffix being the
version number.  (There are historically two slightly different
versions, differing in at least their choice-of-law clause; the details
of that aren't relevant here, so I won't go into them.  We can focus on
those issues in a separate thread.)

Okay, next up:

Re (2): a new, clean "Python Software Foundation" license 2.1:

All of this license looks OSD-compliant to me, except for that clause 3.
Here it is in the PSF-2.1 wording:

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

We've already had some on-list discussion about this.  I pointed out
that it is a "requirement to engage in a prose exercise of unknown
scope", since it's not clear what a brief summary really should be.
Chuck Swiger replied:

  > OSI definition 4 permits PSF clause 3.
  > 
  > In fact, OSI has approved licenses which forbid distributing
  > modified works except as patch files.  This was done to largely to
  > recognize that software like DJB's qmail is still OSI open source.

But I don't think that's quite the same thing.  Requiring changes to be
distributed as patch files is well-defined, unambiguous, and can be
achieved automatically.  It's a bit of a hassle, but it's an automatable
and essentially trivial hassle.

On the other hand, a "brief summary" is nothing like patch files.  A
brief summary means the distributor of the derived work has to write a
human-comprehensible summary of a diff of arbitrary complexity.  While
this might be good software practice, I don't think it's wise to have
the license require it.  After all, anyone else could examine the diffs
and do it too; why should the license specify that the derived-work
distributor do it?  The license should not assume that that distributor
is more competent to do it than someone else.  They *might* be, but why
not let them and their licensees decide that, instead of hardcoding it
into the license?

Unlike with the CNRI license, there is no legacy pressure here.  So does
PSF really need to include this clause?  I'm not fully persuaded of its
OSD-compliance, because it makes distribution of derivative works
conditional on a task whose difficulty in turn depends on the size and
complexity of a code change.

(I realize that OSI has its own legacy issue here, since we did approve
earlier versions of this language.  But let's please try to consider
this from a place of Platonic idealism, not messy reality :-). )

Regarding naming:

Easy call: "Python Software Foundation License 2.1" and "PSF-2.1".

Okay, last section:

Re (3): "Python License" for Python itself [includes CNRI bits, see (1)]

This one's easy, because its only issue is the one already addressed
above.  If we resolve that, then this license should be approved.  I
checked over all the other sections (the BeOpen and CWI) and they look
OSD-compliant, which is not surprising, since we approved them in the
past.

Have you talked to CNRI about getting clause 3 removed?

I realize that OSI sort of approved it already, in the CNRI Python
1.6-beta-1 license at http://opensource.org/licenses/pythonpl and in the
related portion of http://opensource.org/licenses/Python-2.0.  This is
just the same language as there, so we'd be hard pressed to reject the
license because of it now.

But since there is still CNRI code in Python, and future distributions
of Python itself must therefore include CNRI legacy license bits, it
would be great to get this clause removed at least for the future.  As
to what effect that has on Python 1.6.1 itself, which was long ago
distributed with this clause, I have no idea, but let's cross that
bridge when we come to it.  For now I'd just love to know if CNRI is
willing to jettison the clause, perhaps even retroactively.  That would
remove a really pesky issue, and they might have decided by now that the
clause has not brought them any real-world benefit.

Regarding naming:

As we discussed on the phone, it'd be nice for the license of Python
itself to be easily distinguishable from the PSF license.  So here are
some suggestions, with both long name and proposed SPDX short-name:

  Python Multi-license, 2 parts    | PythonMulti-2-part
  Python Original License, 2 parts | PythonOriginal-2-part
  Python Legacy License, 2 parts   | PythonLegacy-2-part
  Python Native License, 2 parts   | PythonNative-2-part

Take your pick, or propose something else, as you wish!  They're all
okay by us.  Needless to say, license names have no bearing on OSI
approval or on other substantive questions.

Best,
-Karl