FOR APPROVAL - Python License Changes

[Joel Rees]

I have no claim to competence, no oar in the water, no horse in this race, but ...

On Sun, 28 Aug 2011 01:39:29 -0400
Karl Fogel <kfogel at red-bean.com> wrote:

> [...]
> All of this license looks OSD-compliant to me, except for that clause 3.
> Here it is in the PSF-2.1 wording:
> 
>  > 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

Who defines/decides this "wants to make the derivative work available" condition? 

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

Who defines/decides the nature of the brief summary?

More to the point, ...

> We've already had some on-list discussion about this.  I pointed out
> that it is a "requirement to engage in a prose exercise of unknown
> scope", since it's not clear what a brief summary really should be.
> Chuck Swiger replied:
> 
>   > 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

(Unambiguous? Really? Just because we have a tradition of using diff in a certain way, .... But this isn't my primary point.)

> achieved automatically.  It's a bit of a hassle, but it's an automatable
> and essentially trivial hassle.
> 
> On the other hand, a "brief summary" is nothing like patch files. 

Is there some reason why a patch file would in any specific or general case fail to fulfill the "brief summary" para-requirement, ergo, in the case that the disclosure is somehow shown to be voluntary and, again, shown to be to the purpose of making available?

What if the disclosure is NOT because the person with the authority to disclose 

    ... wants to make the derivative work available to others 
    as provided herein, ...

?
> [...]
> A
> brief summary means the distributor of the derived work has to write a
> human-comprehensible summary of a diff of arbitrary complexity. 

If we were to assume that sort of interpretation of the GPL 2, no one would dare release anything under the GPL 2 unless the combination of source code, comments, and documentation were <emphasis>already</emphasis> reasonably human readable. (By whom?) Specifically, the clause which says

    The source code for a work means the preferred form 
    of the work for making modifications to it.

bends over backwards to try to (1) lay responsibility on the disclosing party to refrain from obfuscation and at the same time (2) recognize that the license can't magically give the receiving party the ability to understand and meaningfully modify the code, and only succeeds in walking that line because we are willing to read it that way.

The clause exists in a license which is in use. What is the practice there (speaking of precedence)?

> While
> this might be good software practice, I don't think it's wise to have
> the license require it.  After all, anyone else could examine the diffs
> and do it too; why should the license specify that the derived-work
> distributor do it?  The license should not assume that that distributor
> is more competent to do it than someone else.  They *might* be, but why
> not let them and their licensees decide that, instead of hardcoding it
> into the license?

I think, before asking why the license should require good engineering practices, one might ask representative members of the Python community whether that is the meaning they read into the clause, whether, in general practice, an unadorned diff has not been used to fulfill that clause in the previous version.

> Unlike with the CNRI license, there is no legacy pressure here.  So does
> PSF really need to include this clause?  I'm not fully persuaded of its
> OSD-compliance, because it makes distribution of derivative works
> conditional on a task whose difficulty in turn depends on the size and
> complexity of a code change.

I can see lots of stylistic problems with the clause, but style is not law. In fact, I would prefer to give more deference to legacy than to style.

> (I realize that OSI has its own legacy issue here, since we did approve
> earlier versions of this language.  But let's please try to consider
> this from a place of Platonic idealism, not messy reality :-). )

I'm not intending to be obnoxious, here, but the mess of reality is the context which gives law meaning, is it not? (Aren't we all good enough mathematicians here to remember that symbols have no semantic existence out of context?)

[...]

>From my (out of context) pov, it would be worth asking the Python community whether they might not want to make that clause more readable in the new version, but to also ask what the practice is relative to the clause, rather than try to determine the meaning without their help.

(Back to lurking mode.)

-- 
Joel Rees <joel_rees at sannet.ne.jp>