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

Thu Oct 26 00:12:48 UTC 2017

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 :-)

    Thanks

    Bruce

On Wed, Oct 25, 2017 at 5:10 PM, Kyle Mitchell <kyle at kemitchell.com> wrote:

> 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
> _______________________________________________
> License-review mailing list
> License-review at opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20171025/505ca5f4/attachment.html>