[License-review] For Approval: License Zero Reciprocal Public License

[Kyle Mitchell]

McCoy,

Many thanks.  Comments inline.  Sorry again for rewrapping.

On 2017-10-25 22:10, Smith, McCoy wrote:
> Not sure you need to hear back from me (I'm not on the OSI
> board, so my affiliation is only as a commentator on this
> and other OSI mailing lists).  But since you asked.....

I asked because your prior feedback was much appreciated.
Thanks for taking time again!

> 1.  I continue to believe that your license, as drafted
>     (based on the last draft I saw) violates OSD 6 & 9,
>     for the reasons outlined in my prior e-mail.  I think
>     it could be rewritten to not violate those provisions
>     and meet what I understand to be your goals for the
>     license.  But the process here is to examine your
>     license, not your goals.

I'm not exactly sure I understand the OSD 6 concern,
especially to the extent rephrasing alone can avoid it.
This has come up with Bruce, as well, prompting words like
"inversion" from Bruce and "refactoring" from me.  Does it
boil down to a matter of form, rather than function?  That
can't be it.  I must still be missing something.

All the same, much inspired by Bruce, I'll be floating a
more direct rewrite shortly.  Here's hoping the result
addresses your OSD 6 concern.  If I'm so lucky, perhaps I
can work backwards to a more complete understanding, with a
passing and a failing text.

> 2.  I think there is quite an interesting philosophical
>     question raised by what I think are your goals here. I
>     will opine upon them as an external observer and not
>     as someone who speaks for OSI (there are others who
>     have responded to you who do).  Namely, would an "IP
>     Maximaleft" license be approvable by OSI under the
>     OSD?  So, hypothetically:

Let the record reflect that McCoy has coined "maximaleft".

>   "You are granted a license to all the rights that the
>   author(s) have the right to grant, under the following
>   conditions:
>
>    1. You preserve all notices by the author(s).
>
>    2. You preserve all disclaimers of liability by the
>       author(s), and you understand that you get no
>       liability from the author(s).
>
>    3. Every exercise of the rights granted to you by the
>       author(s) requires you to publicly publish the
>       source code resulting from the exercise of those
>       rights."

This is eerily close to my current rewrite draft.

> In my opinion, that sort of license would pass the OSD
> (assuming it could be written in a way that is deemed to
> be legally clear so that it doesn't sweep in use cases
> violating OSD 9).  I don't think FSF's Freedom 0 is
> required by the current OSD.

That leaves OSD 9.  GPL "work based on the Program" is
clearly within bounds.  Could you give an example of a use
out of OSD 9 bounds?

For example, I believe it was Bruce who mentioned that
requiring release of software incorporating L0-R software as
a component would probably conform to OSD 9.  As does
GPL-3.0 and its impositions on "the whole of the work, and
all its parts, regardless of how they are packaged".   But
per Bruce, requiring release of software generated,
compiled, translated, or optimized by an L0-R program would
not.  So L0-R could reach software created by modification
of the L0-R software itself, but not software created by
executing the L0-R software.

I don't mean to welcome myself to still more of your time.
But I'd be very grateful to read your thoughts along these
lines, perhaps in the frame of the forthcoming revision.

> 3.  I don't think a license of that type is a particularly
>     good idea, nor is it a license that I think many users
>     would want to accept.  And I think it would be
>     detrimental to the smaller developers.  The freedom to
>     privately tinker, as articulated in FSF Freedom 0, is
>     a worthwhile freedom.  Requiring someone to publish
>     their tinkering, particularly when that obligation is
>     continuing, would impose a burden that I think most
>     developers wouldn't want to shoulder, and might also
>     subject them to having to publish work that is not
>     something they'd want public.
>
> 4.  I seriously doubt this license is going to achieve the
>     goals you seek.  The companies you think are
>     extracting value from the work of unpaid developers
>     would likely not accept software licensed under those
>     terms.  Taking the right to privately tinker away from
>     an organization that might have hundreds or thousands
>     of developers who might be tinkering with the code
>     creates an administrative compliance nightmare that is
>     not likely worth the benefit of receiving the code.
>
> 5.  In the end, the LZPL schema looks something like a
>     fairly common model in the industry -- an eval
>     license, followed by a commercial license in the eval
>     process is successful.  Except the eval license in
>     this case, LZPL, has terms that I think most
>     organizations and developers wouldn't find palatable.
>     Better for the developers you think want to use this
>     model to use a more standard eval license and keep
>     "open source" out of it.

I'm focusing more heavily on points germane to the review
process, above, but I've read these points, too, and
carefully.  Much obliged, and happy to return to these
topics any time.

-- 
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933