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

[Kyle Mitchell]

On 2017-10-24 13:10, Josh berkus wrote:
> On 10/23/2017 05:15 PM, Kyle Mitchell wrote:
> > On 2017-10-23 16:10, Josh berkus wrote:
> >> On 10/23/2017 03:55 PM, Kyle Mitchell wrote:
> >>> Josh,
> >>>
> >>> I've been busy working out variations, trying to cover all
> >>> the concerns we raised, plus a few from Richard and McCoy,
> >>> without doubling the length of the license or veering into
> >>> heavy-duty contract structure.
> >>>
> >>> The frontrunner:
> >>>
> >>>   3.  Use with any software patch must be accompanied by
> >>>       release of that patch as Open Source Software per the
> >>>       Open Source Definition published by the Open Source
> >>>       Initiative.
> >>
> >> [...]
> >>
> >> My first question, in the above, is "what if the user doesn't have the
> >> ability to relicense the patch?"  The clause above imposes an obligation
> >> that the *user* may be unable to fulfill -- or for that matter even
> >> unaware of -- while the *distributor*, who is the jerk who bundled ZRPL
> >> code with a proprietary patch in the first place, gets off scot-free.
> >> Is that how you intended this paragraph to be interpreted?
> >
> > Yes.  The originator of the non-Open Source patch will be in
> > breach, as would any follow-on user to whom they provide a
> > copy.  The originator of the patch can't give more
> > permission than they themselves received from owners of
> > rights in the original L0-R code.  If the one who made the
> > patch made any kind of warranty---express or implied---to
> > the end user, the end user might be able to bring a claim
> > against the infringing modifier-distributor, to answer for
> > any liability of their own.
>
> Not according to the wording in that clause; according to it, only "use"
> triggers the restriction, not redistribution.  Granted that it's
> difficult to modify software without using it (at least for testing
> purposes), but the license seems worded to put the onus on the user, not
> on the modifier.

I suppose L0-R could drive an even harder bargain than it
tries to now, by prohibiting distribution with non-Open
Source modifications, or for use as a component of non-Open
source.  That wouldn't help our naive users executing
prebuilt binaries.  But it might dissuade the one making
those binaries from handing them out in the first place.

A few more notes on this below.

> > The situation you describe is unfortunate, but not
> > peculiar to L0-R.  Any copyleft license that triggers a
> > requirement to provide all source, not just source for
> > your own modifications, has the same potential.
> > Otherwise, the freedom to hack software you obtain
> > wouldn't get much protection.  Any first infringer could
> > open the door for subsequent recipients to dodge the
> > copyleft requirement, on the grounds that it's
> > conveniently impossible to do so.
>
> You're missing the distinction between the user and the modifier of code
> here.  The GPL puts its emphasis on *distribution*, not use; in fact, I
> can use GPLv2 code all I want in combination with any other licenses and
> not violate anything.  The violation only happens when I give a copy of
> that code to someone else.

Correct, roughly speaking.

> The distinction here is important.  Theoretically, someone who is going
> to modify code should understand the licensing of the code they are
> modifying.  But I don't feel like we can expect the same of someone who
> is just executing a binary;  they don't *know* that it was modified with
> incompatibly licensed code unless they dig into the code history.

Nor can we realistically expect the same of someone who is
just executing a purportedly MIT-licensed binary.  They may
not know it was modified with, say, proprietary performance
patches, for which they lack proper use licenses.

> What I don't get is why you even bother with this emphasis on use
> instead of distribution.  Explain?

Sure.  Two reasons.

First, L0-R wants to drive a harder reciprocity bargain than
GPL.  For example, it wants to trigger on exactly the GPL
use case you outline above.  GPL allows licensees to take
open code, modify it, build on top of it, build out other
software with it, and refuse to share that work back to the
open, all by avoiding "distribution".

AGPL wanted to drive a harder bargain than GPL, too, by
closing the ASP loophole.  So AGPL also triggers source
requirements on a kind of use, albeit one that _feels_
vaguely like a kind of distribution, to cover cases GPL's
distribution-based trigger couldn't reach.

Second, L0-R wants to maximize distribution and
compatibility with distribution systems.  Preserving
BSD-2-Clause's "redistribution" conditions verbatim does
just that.

As a practical matter, many distribution systems take
warranties and even default licenses for user-provided
content, under their terms of service.  Those can serve as
backstops, should redistribution of user content technically
exceed permission under the applied public license.  But not
all such services do this with terms, want to, or know they
might want to.

In the end, software is always caveat user.  Open Source is
no exception.  It's as important to make sure you have terms
for software you're using to begin with as it is to make
sure those terms are Open Source terms, and that you can
live with their conditions.

I've done a lot of work on those problems.  But that work
doesn't take the form of public license terms.

Thanks again for great questions, Josh.  Really, really
appreciate the time you've put in.

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