<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div>Kyle,</div>
<div><br>
</div>
<div>The non-compliance with freedom 0 is a show stopper in my opinion and I typically am not all that concerned about compatibility with the GPL.</div>
<div><br>
</div>
<div>Nigel</div>
<div class="x_gw_quote" style="border-top:#b5c4df 1pt solid; padding-top:6px; font-size:14px">
<div><b>From: </b><span>Kyle Mitchell <<a href="mailto:kyle@kemitchell.com">kyle@kemitchell.com</a>></span></div>
<div><b>Date: </b><span>Wednesday, Oct 25, 2017, 8:10 PM</span></div>
<div><b>To: </b><span>License submissions for OSI review <<a href="mailto:license-review@opensource.org">license-review@opensource.org</a>></span></div>
<div><b>Subject: </b><span>Re: [License-review] For Approval: License Zero Reciprocal Public License</span></div>
</div>
<br>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">McCoy,<br>
<br>
Many thanks. Comments inline. Sorry again for rewrapping.<br>
<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>
I asked because your prior feedback was much appreciated.<br>
Thanks for taking time again!<br>
<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>
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>
<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>
Let the record reflect that McCoy has coined "maximaleft".<br>
<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>
This is eerily close to my current rewrite draft.<br>
<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>
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>
<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>
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>
<br>
-- <br>
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933<br>
_______________________________________________<br>
License-review mailing list<br>
License-review@opensource.org<br>
<a href="https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review">https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review</a><br>
</div>
</span></font>
</body>
</html>