The Python licensing situation.

[Karl Fogel]

Chuck Swiger <chuck at codefab.com> writes:
>> 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.

Thanks, Chuck.  I understand (and agree) that it is permitted -- my
point was more about whether it's desirable :-).

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

Good point; I hadn't thought of the binary case.

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

I think it might be reasonable to assume that a court would interpret
all the change-listing formats you and I agree to above as being forms
of summarization that comply with the license.  I'd like to read Van's
response, though.

>> 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 pkix.net>'
>__copyright__ = 'Copyright (c) 2005-2006 Charles Swiger'
>__version__   = '$Id: histogram.py,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 www.python.org/license.html).'

Thanks; useful information.

-Karl