The Python licensing situation.
Lindberg, Van
Van.Lindberg at haynesboone.com
Tue Jun 7 19:37:40 UTC 2011
Comments inline below.
________________________________
From: Karl Fogel
Sent: Tuesday, June 07, 2011 3:20:31 PM
To: license-review, license-discuss
Cc: Van Lindberg
Subject: The Python licensing situation.
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>.
[snip good discussion of concerns]
These are all good points that I am still considering. I also need to go back to the PSF board on this. My main motivating factor here was to make the changes as minimal as possible... but perhaps in for a penny, in for fivepence might be a better position. I need to make sure there aren't additional reasons (e.g. contractual or other agreements with CNRI) that might foreclose changing this section.
In any event, even if this stays, the PSF can take a position that the summary of changes can be in any form reasonably calculated to allow people to understand the differences - e.g. README, changelog, patchfile, commit histories would all be acceptable.
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?
This is in use, mostly for Python projects that are aiming to eventually get into the Python stdlib. Given Python's "batteries included" philosophy and general "prove yourself standalone, then we will incorporate you" procedure, this is a decent number. How many I couldn't guess - I would say in the low hundreds.
My main concern here is that, IIRC, there were agreements between CNRI and the PSF that allowed the PSF to go forward -- only under the license that was approved by CNRI. As I said, I will check on that recollection to see if it is correct. The reason why I thought that the existing proposed changes can go forward is because the generalized PSF 2.1, when applied to Python, would be essentially identical to the existing license.
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?
There *is* a clerical error - the version that was picked up and mirrored was the beta version of the license. This proposal is to 1) fix the clerical error, and 2) update the naming so that it is unambiguous.
Thanks,
Van
CIRCULAR 230 NOTICE: To ensure compliance with requirements imposed by
U.S. Treasury Regulations, Haynes and Boone, LLP informs you that any
U.S. tax advice contained in this communication (including any
attachments) was not intended or written to be used, and cannot be
used, for the purpose of (i) avoiding penalties under the Internal
Revenue Code or (ii) promoting, marketing or recommending to another
party any transaction or matter addressed herein.
CONFIDENTIALITY NOTICE: This electronic mail transmission is confidential,
may be privileged and should be read or retained only by the intended
recipient. If you have received this transmission in error, please
immediately notify the sender and delete it from your system.
More information about the License-review
mailing list