FOR APPROVAL - Python License Changes

Karl Fogel kfogel at
Sun Aug 28 20:21:40 UTC 2011

Rod Dixon <roddixon at> writes:
>I agree with what has been said in this discussion. The issue
>regarding the requirement of a "brief summary" explaining changes made
>resulting in a derivative work is a close call in terms of whether it
>is desirable, but I agree that it does not seem to violate the

Heh, well, what has been said so far in this discussion is contradictory
-- you can't agree with all of it :-).

Some people have said that clause is compatible with the OSD, others are
saying it is incompatible.  I fall into the latter camp, for the reasons
given in my previous mail & further explained below.

>The requirement may be burdensome for certain distributors, but
>the terms of the license impose the summary requirement on the creator
>of the derivative work who may not necessarily be the distributor but
>should be the person (or entity) who can produce an accurate summary
>of the changes they made. This shouldn't be that burdensome. Or, if it
>is, it is not because of the summary requirement, it is because of the

This is not always true.  A programmer might make very complex changes,
but then leave the company.  Now the company wants to release the code,
but there's no one left in-house who can easily summarize the changes.
The programmer who made the changes is a genius, but wrote very poor log
messages and comments, so no one can understand what she did.

Ironically, there might be other people out in the world who *could*
understand the changes and write the summary!  But since the company
cannot release the code publicly, those strangers never get the chance
to help.

This is not a contrived example.  People get hit by buses, or by medical
issues, or by better job offers, all the time.  It has happened in
projects I have worked on.  If the expertise needed to summarize changes
disappears unexpectedly, the last thing the license should do is prevent
further distribution of those changes -- this is exactly the time when
we need the changes to be accessible to *more* people, given that the
old expert(s) disappeared!

So my objection is twofold:

  1) The clause is OSD-incompatible because it places an arbitrary
     burden on those releasing a derived work, and in some cases may
     make redistribution effectively too difficult to undertake.

  2) The clause works against its own purpose anyway.  If the goal is to
     get good summaries of changes, then the best way is to give the
     greatest number of people the chance to write those summaries.

Only (1) is a factor for OSD approval, but I think (2) is a pretty
substantial objection too.


More information about the License-review mailing list