<div dir="ltr">I'm off of this discussion until Tuesday at the earliest. I have an FCC filing to finish, and a life away from the Internet to pursue :-)<div><br></div><div>    Thanks</div><div><br></div><div>    Bruce</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 25, 2017 at 5:10 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">McCoy,<br>
<br>
Many thanks.  Comments inline.  Sorry again for rewrapping.<br>
<span class=""><br>
On 2017-10-25 22:10, Smith, McCoy wrote:<br>
> Not sure you need to hear back from me (I'm not on the OSI<br>
> board, so my affiliation is only as a commentator on this<br>
> and other OSI mailing lists).  But since you asked.....<br>
<br>
</span>I asked because your prior feedback was much appreciated.<br>
Thanks for taking time again!<br>
<span class=""><br>
> 1.  I continue to believe that your license, as drafted<br>
>     (based on the last draft I saw) violates OSD 6 & 9,<br>
>     for the reasons outlined in my prior e-mail.  I think<br>
>     it could be rewritten to not violate those provisions<br>
>     and meet what I understand to be your goals for the<br>
>     license.  But the process here is to examine your<br>
>     license, not your goals.<br>
<br>
</span>I'm not exactly sure I understand the OSD 6 concern,<br>
especially to the extent rephrasing alone can avoid it.<br>
This has come up with Bruce, as well, prompting words like<br>
"inversion" from Bruce and "refactoring" from me.  Does it<br>
boil down to a matter of form, rather than function?  That<br>
can't be it.  I must still be missing something.<br>
<br>
All the same, much inspired by Bruce, I'll be floating a<br>
more direct rewrite shortly.  Here's hoping the result<br>
addresses your OSD 6 concern.  If I'm so lucky, perhaps I<br>
can work backwards to a more complete understanding, with a<br>
passing and a failing text.<br>
<span class=""><br>
> 2.  I think there is quite an interesting philosophical<br>
>     question raised by what I think are your goals here. I<br>
>     will opine upon them as an external observer and not<br>
>     as someone who speaks for OSI (there are others who<br>
>     have responded to you who do).  Namely, would an "IP<br>
>     Maximaleft" license be approvable by OSI under the<br>
>     OSD?  So, hypothetically:<br>
<br>
</span>Let the record reflect that McCoy has coined "maximaleft".<br>
<span class=""><br>
>   "You are granted a license to all the rights that the<br>
>   author(s) have the right to grant, under the following<br>
>   conditions:<br>
><br>
>    1. You preserve all notices by the author(s).<br>
><br>
>    2. You preserve all disclaimers of liability by the<br>
>       author(s), and you understand that you get no<br>
>       liability from the author(s).<br>
><br>
>    3. Every exercise of the rights granted to you by the<br>
>       author(s) requires you to publicly publish the<br>
>       source code resulting from the exercise of those<br>
>       rights."<br>
<br>
</span>This is eerily close to my current rewrite draft.<br>
<span class=""><br>
> In my opinion, that sort of license would pass the OSD<br>
> (assuming it could be written in a way that is deemed to<br>
> be legally clear so that it doesn't sweep in use cases<br>
> violating OSD 9).  I don't think FSF's Freedom 0 is<br>
> required by the current OSD.<br>
<br>
</span>That leaves OSD 9.  GPL "work based on the Program" is<br>
clearly within bounds.  Could you give an example of a use<br>
out of OSD 9 bounds?<br>
<br>
For example, I believe it was Bruce who mentioned that<br>
requiring release of software incorporating L0-R software as<br>
a component would probably conform to OSD 9.  As does<br>
GPL-3.0 and its impositions on "the whole of the work, and<br>
all its parts, regardless of how they are packaged".   But<br>
per Bruce, requiring release of software generated,<br>
compiled, translated, or optimized by an L0-R program would<br>
not.  So L0-R could reach software created by modification<br>
of the L0-R software itself, but not software created by<br>
executing the L0-R software.<br>
<br>
I don't mean to welcome myself to still more of your time.<br>
But I'd be very grateful to read your thoughts along these<br>
lines, perhaps in the frame of the forthcoming revision.<br>
<div><div class="h5"><br>
> 3.  I don't think a license of that type is a particularly<br>
>     good idea, nor is it a license that I think many users<br>
>     would want to accept.  And I think it would be<br>
>     detrimental to the smaller developers.  The freedom to<br>
>     privately tinker, as articulated in FSF Freedom 0, is<br>
>     a worthwhile freedom.  Requiring someone to publish<br>
>     their tinkering, particularly when that obligation is<br>
>     continuing, would impose a burden that I think most<br>
>     developers wouldn't want to shoulder, and might also<br>
>     subject them to having to publish work that is not<br>
>     something they'd want public.<br>
><br>
> 4.  I seriously doubt this license is going to achieve the<br>
>     goals you seek.  The companies you think are<br>
>     extracting value from the work of unpaid developers<br>
>     would likely not accept software licensed under those<br>
>     terms.  Taking the right to privately tinker away from<br>
>     an organization that might have hundreds or thousands<br>
>     of developers who might be tinkering with the code<br>
>     creates an administrative compliance nightmare that is<br>
>     not likely worth the benefit of receiving the code.<br>
><br>
> 5.  In the end, the LZPL schema looks something like a<br>
>     fairly common model in the industry -- an eval<br>
>     license, followed by a commercial license in the eval<br>
>     process is successful.  Except the eval license in<br>
>     this case, LZPL, has terms that I think most<br>
>     organizations and developers wouldn't find palatable.<br>
>     Better for the developers you think want to use this<br>
>     model to use a more standard eval license and keep<br>
>     "open source" out of it.<br>
<br>
</div></div>I'm focusing more heavily on points germane to the review<br>
process, above, but I've read these points, too, and<br>
carefully.  Much obliged, and happy to return to these<br>
topics any time.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Kyle Mitchell, attorney // Oakland // <a href="tel:%28510%29%20712%20-%200933" value="+15107120933">(510) 712 - 0933</a><br>
______________________________<wbr>_________________<br>
License-review mailing list<br>
<a href="mailto:License-review@opensource.org">License-review@opensource.org</a><br>
<a href="https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review" rel="noreferrer" target="_blank">https://lists.opensource.org/<wbr>cgi-bin/mailman/listinfo/<wbr>license-review</a><br>
</div></div></blockquote></div><br></div>