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

[Kyle Mitchell]

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.

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.

To give a concrete example, AGPL section 13 speaks in terms
of "an opportunity to receive the Corresponding Source".
"Corresponding Source", in turn, means "all the source code
needed to generate, install, and (for an executable work)
run the object code and to modify the work".  If you have
source for your own modifications, but not someone else's
modifications, in the aggregate you're providing over the
network, I don't think you can comply.

This risk is somewhat mitigated by the fact that it takes a
particular software architecture to enable modifications to
one part of a program without the modified source to
another.  It's certainly possible.  But if the program is
written in an interpreted language, or a single compiled
binary, you're likely to have the whole source for what you
build with modifications.

> >   4.  Use as a component of, or in development of, other
> >       software must be accompanied by release of that
> >       software as Open Source Software per the Open Source
> >       Definition published by the Open Source Initiative.
>
> So here you're thinking this is a license for things like software
> development tools and libraries, correct?

"[A]s a component of" is meant to catch the GPL use case of
incorporation as a dependency or library.  It's
intentionally broad, so there's no clear copyright or
technical "out", as with shared libraries, arguably
non-derivative works, and so on.

"[O]r in development of" is meant to catch developer tools.
The only situation in which use of dev tools are currently
covered by any copyleft implementation, that I'm aware of,
is making a modified dev tool available for remote
interaction over a network under AGPL.  An edge case, for
sure.

I have thought about trying to specialize "in development
of" with some examples.  I've come up with a few lists of
verbs, but they've all struck me as more problematic than
the language they want to replace.

Reading "in development of" to cover use of a transpiler to
output source code feels correct.   Reading "in development
of" to cover using a text editor to write other programs
feels a bit more like a reach.  But a "reach" in the
practical sense of a licensor thinking carefully about their
choice of license.  Not in any legal sense.

> >   5.  A failure to meet condition 3 or condition 4 is
> >       automatically excused on required release of software,
> >       or permanent cessation of use involving the software,
> >       within ____ calendar days of first failure to meet the
> >       condition involving the same software or a preexisting
> >       work upon which it was based.
> >
> > Number 3 and 4 now state release requirements affirmatively.
> > The "grace period" mechanism for both now lives in a
> > separate 5.  Number 5 is structured like a path to
> > forgiveness, akin to section 8 of (A)GPL-3.0.
>
> OK, that tightens it up a lot.
>
> However, the inclusion of any kind of grace period at all *materially*
> means that the grace period starts from the day a licensor *discovers*
> the infringement, not when the infringing use starts, since the licensor
> has no way to accurately know that time period.
>
> That's not, as far as I'm concerned, a reason to reject the license, but
> might be worth noting in the recommendations around it.

I'm not sure that's true.

X releases code under L0-R (14 days).  Y violates the
license by using with an unreleased private patch past its
grace period.  X can sue, six months later, then compel
production of documents and records that show use in excess
of permission under the license.  If the dates six months
ago don't add up to compliance, X has grounds for a
copyright claim against Y.

That assumes that X feels pretty confident that Y has made
unauthorized use.  Confident enough to incur the time and
other costs of sending a strongly worded letter and
escalating as necessary, if it is ignored.

There may also be cases where X learns more directly, before
litigation, of facts showing Y exceeded its permission.  We
can expect that to be pretty rare for, say, private patches
to standalone software that doesn't do any networking.  But
the same information asymmetry, alas, hides much GPL and
even LGPL violation today.  Public licensors with any
interest in their license conditions just can't police all
licensees.  They have to live with licensee's other motives
for compliance, and perhaps make an occasional public
example of someone.

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