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