<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<span id="IDstID">Comments inline below.<br>
<br>
<hr>
<div style="font-family: Tahoma,Helvetica,sans-serif; font-size:
10pt;"><b>From:</b> Karl Fogel<br>
<b>Sent:</b> Tuesday, June 07, 2011 3:20:31 PM<br>
<b>To:</b> license-review, license-discuss<br>
<b>Cc:</b> Van Lindberg<br>
<b>Subject:</b> The Python licensing situation.</div>
</span><br>
<blockquote cite="mid:878vtdsb28.fsf@kslab.red-bean.com" type="cite">
<pre wrap="">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>.
</pre>
</blockquote>
<br>
[snip good discussion of concerns]<br>
<br>
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. <br>
<br>
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.<br>
<br>
<blockquote cite="mid:878vtdsb28.fsf@kslab.red-bean.com" type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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?
</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote cite="mid:878vtdsb28.fsf@kslab.red-bean.com" type="cite">
<pre wrap="">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 <a class="moz-txt-link-freetext" href="http://opensource.org/licenses/Python-2.0">http://opensource.org/licenses/Python-2.0</a>, 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?
</pre>
</blockquote>
<br>
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.<br>
<br>
Thanks,<br>
<br>
Van<br>
</body>
</html>
<pre>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.