FOR APPROVAL - Python License Changes

[Rod Dixon]

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

As for the word "brief" being nebulous, I agree -  in the sense that it is redundant when summary follows the word brief. Even so, you still have the problem of whether "summary" is a burdensome requirement. The summary is a good idea, IMHO. Yet, I don't like hard-coding these *rules* in licenses  -- as Karl said, doing so is an undesirable practice. Still, I think inclusion of the summary requirement is compliant with the OSD.

Rod

Sent from my iPhone 

On Aug 28, 2011, at 11:44 AM, Russ Nelson <nelson at crynwr.com> wrote:

> Karl Fogel writes:
>> (Btw, I realize that OSI approved it already, in the CNRI Python
>> 1.6-beta-1 license at http://opensource.org/licenses/pythonpl and in the
>> related portion of http://opensource.org/licenses/Python-2.0.  This is
>> just the same language as there, so we'd be hard pressed to reject the
>> license because of it now.  But read on.)
> 
> Times change, and understanding of effects changes. Something which we
> approved in the past may not be approvable today. We're not a court;
> precedents are instructive but not limiting.
> 
>>> 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.
>> 
>> But I don't think that's quite the same thing.  Requiring changes to be
>> distributed as patch files is well-defined, unambiguous, and can be
>> achieved automatically.  It's a bit of a hassle, but it's an automatable
>> and essentially trivial hassle.
> 
> And that wasn't the reasoning. The reasoning was (as you write) and
> put forth because of TrollTech's Qt Public License. DJB's qmail wasn't
> open source. It wasn't even freely copyable software! With no
> copyright license, you couldn't copy it, but instead had to fetch each
> copy afresh from DJB's website.
> 
>> On the other hand, a "brief summary" is nothing like patch files.  A
>> brief summary means the distributor of the derived work has to write a
>> human-comprehensible summary of a diff of arbitrary complexity.
> 
> "Brief" is also a nebulous term to be putting in a license. I
> speculate that the idea was to limit the difficulty of producing a
> summary, addressing our concerns.
> 
>> Have you talked to CNRI about getting clause 3 removed?
> 
> I think that is a good course of action. It can take some persistence
> and patience, but I think it can be done.
> 
> -- 
> --my blog is at    http://blog.russnelson.com
> Crynwr supports open source software
> 521 Pleasant Valley Rd. | +1 315-600-8815
> Potsdam, NY 13676-3213  |     Sheepdog       
>