The Python licensing situation.

Chuck Swiger chuck at
Tue Jun 7 19:54:48 UTC 2011

Hi, Karl--

On Jun 7, 2011, at 12:20 PM, Karl Fogel wrote:
[ ... ]
> 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.

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.

> Furthermore, it's not clear what "include in any such work" means,
> technically.  Are version control logs sufficient?

Maybe-- it depends on whether such logs provide a summary of the changes.

>From considerable experience with commit messages, not everyone manages to describe the changes they've just committed in a fashion which would be understandable.

> Does it require a NEWS or CHANGES file in the distributed source tarball?

No, but such files would be a very good way of describing the changes.

> What about in a binary distribution of the derived work?

The license doesn't distinguish between binary and source distributions, so yes, the summary changes would need be included in a binary-only distribution.

> Would a ChangeLog generated from version control logs be sufficient, or does it really have to be a
> human-written summary?

The license doesn't say that a human has to write a summary rather than using a ChangeLog or similar.

> Would a web page summarizing the changes be sufficient?  Etc, etc.

No, a web page would not be sufficient, because it is not included with the distribution.

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

Such tools only work if you get the modified version in source rather than as a binary.  It's not especially pleasant to try to support a modified binary of something which you'd written which someone changed in unknown ways.

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

That's a moot question: the PSF license already exists and is relatively widely used, although perhaps not as much as the most comparable case of Perl.

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

Just like the folks on CPAN writing Perl modules, it is very common for someone writing Python code which they are willing to share with others to license such code under the same terms as Python.  For an example:

__author__    = 'Chuck Swiger <chuck at>'
__copyright__ = 'Copyright (c) 2005-2006 Charles Swiger'
__version__   = '$Id:,v 1.6 2006/05/06 15:47:51 chuck Exp $'
__license__   = 'This software is licenced under the same terms as Python.  (See the PSF license at'


More information about the License-review mailing list