[License-review] Consensus on L0-R

[Bruce Perens]

On Tue, Jun 19, 2018 at 9:31 PM, Kyle Mitchell <kyle at kemitchell.com> wrote:

>
> I've responded to this conclusion with history:
>
> http://lists.opensource.org/pipermail/license-review_
> lists.opensource.org/2017-November/003292.html


So, here you create a rather convoluted argument for the OSD not being
externally consistent, by ingoring the word "use" in #6 and arguing that
somehow #2 overrides #6. No overriding of one rule with another is
necessary for a valid analysis. You also ignore #3, which it turns out is
important for this analysis.

Use and the creation of derivative works are two separate and independent
rights in copyright law. Use means running the program.

So here is a valid analysis without any rule overriding another, without
self-reference, quite simple:

#2 requires that the program be available in source code form. It does not
make any reference to derivative works.

#3 requires that derivative works be allowed, and that it must be permitted
for them to be distributed under the same license as the original work. It
is not required for derivative works to be allowed under any other license.
It makes no reference to use.

#3 has an important application that you might be missing: In requiring
that the derivative works can be distributed under the same license as the
original work, it requires that licenses with terms that require source
code distribution, if used on the original work, must be capable of being
*applied* to a derivative work. Thus, it permits the GPL.

#6 requires that the program can be used for any purpose. It does not make
any reference to derivative works.

You are also assuming that I was unaware of the fact that programs could
process programs when I proposed the OSD. I was indeed aware, not simply
from the entire collection of textual tools in Unix which I had been using
since I started using Unix at the NYIT Computer Graphics Lab in 1981. There
was also Lisp, which was a well-known self-processing language at the time.


> I am not sure how your are discerning consensus.  I do recall you and
> Carlo came out definitely against conformance.
>

Yes, and you objected, and none of the reviewers spoke on your behalf at
that point (you're not a reviewer of your own license).
And I think I've proven that your analysis was erroneous, anyway.


>
> I remain open to the idea that you may be right.  But not
> for no reason.  I'll keep testing the reasons I'm given.
>
> > The discussion devolved to topics not connected with the license after
> > that, eventually requiring intervention by OSI's president.
>
> You refer to this message?:
>
> http://lists.opensource.org/pipermail/license-review_
> lists.opensource.org/2017-November/003277.html


No, another one which it would not help the civility of the discussion to
go over again.


> The topic of how, exactly the license-review process works
> is alive on the list again today.
>

Yes, and we can beat this dead horse once again, with the result that the
OSI may start using a new piece of software. This is not a fundamental
discussion of OSI's right to deny their imprimatur to your license.


> I'm asking OSI to approve an evolved reciprocal license that says, in
> essence, what Richard and others said GPL was meant to say in its day


No, actually FSF's "Four Freedoms" also prohibit LR-0. "Freedom 0": *The
freedom to run the program as you wish, for any purpose.*


> Approved licenses _do_ mention or address exceptions and parallel terms.
> Artistic (directly).  Apache (warranties). GPL (if you count writing in for
> an exception).
>

Sorry, what's the point here?


> We've addressed this.  If popularity is required for OSI
> approval, OSI should say so.


We just heard this evening from Allison about the license having some
meaningful value. Users would be one way to attest to such a value.

And of course being open to revision means you don't get rejected for a
stupid omission that you could fix without resubmitting the entire license.
Which makes it a best practice.

    Thanks

    Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20180620/2279f1c9/attachment-0001.html>