<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 19, 2018 at 9:31 PM, Kyle Mitchell <span dir="ltr"><<a href="mailto:kyle@kemitchell.com" target="_blank">kyle@kemitchell.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I've responded to this conclusion with history:<br>
<br>
<a href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2017-November/003292.html" rel="noreferrer" target="_blank">http://lists.opensource.org/<wbr>pipermail/license-review_<wbr>lists.opensource.org/2017-<wbr>November/003292.html</a></blockquote><div><br></div><div>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.</div><div><br></div><div>Use and the creation of derivative works are two separate and independent rights in copyright law. Use means running the program.</div><div><br></div><div>So here is a valid analysis without any rule overriding another, without self-reference, quite simple:</div><div><br></div><div>#2 requires that the program be available in source code form. It does not make any reference to derivative works.</div><div><br></div><div>#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.</div><div><br></div><div>#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 <i>applied</i> to a derivative work. Thus, it permits the GPL.</div><div><br></div><div>#6 requires that the program can be used for any purpose. It does not make any reference to derivative works.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I am not sure how your are discerning consensus.  I do recall you and Carlo came out definitely against conformance.<br></blockquote><div><br></div><div>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).</div><div>And I think I've proven that your analysis was erroneous, anyway.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I remain open to the idea that you may be right.  But not<br>
for no reason.  I'll keep testing the reasons I'm given.<br>
<span class=""><br>
> The discussion devolved to topics not connected with the license after<br>
> that, eventually requiring intervention by OSI's president.<br>
<br>
</span>You refer to this message?:<br>
<br>
<a href="http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2017-November/003277.html" rel="noreferrer" target="_blank">http://lists.opensource.org/<wbr>pipermail/license-review_<wbr>lists.opensource.org/2017-<wbr>November/003277.html</a></blockquote><div><br></div><div>No, another one which it would not help the civility of the discussion to go over again.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The topic of how, exactly the license-review process works<br>
is alive on the list again today.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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</blockquote><div><br></div><div>No, actually FSF's "Four Freedoms" also prohibit LR-0. "Freedom 0": <i>The freedom to run the program as you wish, for any purpose.</i></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Approved licenses _do_ mention or address exceptions and parallel terms.  Artistic (directly).  Apache (warranties). GPL (if you count writing in for an exception).<br></blockquote><div><br></div><div>Sorry, what's the point here?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We've addressed this.  If popularity is required for OSI<br>
approval, OSI should say so.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>    Thanks</div><div><br></div><div>    Bruce</div></div>
</div></div>