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

[Kyle Mitchell]

Josh,

Thank you!

On 2017-10-19 19:10, Josh Berkus wrote:
> On 10/19/2017 05:27 PM, Kyle Mitchell wrote:
> >     3.  Uses with any modification that is not "Open Source"
> >         as defined by the Open Source Initiative must be
> >         limited to <Grace Period> calendar days.
> >
> >     4.  Uses as part of, or in development of, other
> >         software that is not "Open Source" as defined by the
> >         Open Source Initiative must be limited to <Grace
> >         Period> calendar days.
>
> Some questions for you:
>
> - What event is the time limit measured from?

Excellent question.  Right now, it isn't up to usual
standards of private-contract clarity.  I would love help
bringing it closer.

The bad news?  That's not laziness talking.  I'm not sure
how clear it can be, or should be.  I suspect clarity would
come from pinning it down to technical details that will
change, inconveniently, over time.  Practical developments
could scramble the result, just as they've scrambled
triggers in copyleft licenses past.  Meanwhile, going that
route would probably take quite a bit of language, too.
Take L0-R into BSD+Patent territory.

Why press on?  Because my gut sense---US lawyer talking
here---is that fuzziness favors the licensee, and that these
provisions are fuzzy, but not unenforceable, as currently
written.  If you can come up with a reasonable reading of
the language under which you fit within n consecutive
calendar days, you have the upper hand.  Conversely, if
there's no straight read that brings the facts within n
days, the licensor could enforce with confidence.

So, a failure case to start.  Company uses an L0-R project,
grace period of 7 calendar days, with patch B, on January
first.  On January seventh, they edit patch B, giving birth
to patch B2, and use with B2.  On January thirteenth, they
edit again.  On to B3.

Are they in compliance?  My gut tells me no.  My mind tells
me they could make it painful to find out before an American
court.  Not ideal.

We could try to patch in at least a couple of ways, using
whatever clarity we think comes from the BSD
use-distribution distinction:

    3.  Uses with any modification that is not "Open Source"
        as defined by the Open Source Initiative must be
        limited to <Grace Period> calendar days,

        1. starting on first use with any such modification.

        2. starting on first use with any such modification,
           and ending on last use with any derivative work
           based on that modification.

    4.  Uses as part of, or in development of, other
        software that is not "Open Source" as defined by the
        Open Source Initiative must be limited to <Grace
        Period> calendar days,

        1. starting on first use with any such software.

        2. starting on first use with a such software, and
           ending on last use with any derivative work based
           on that software.

The first variants imply that a single licensor needs a
license to use _immediately_ upon triggering use, if they've
made a prior use that would have triggered, had it crossed
the n-day grace period.  That makes the grace period a
one-time-use kind of mitigation, and a potential gotcha.
The second variants are easier to read as per-use with
modification or per-use with other software grace periods,
resetting on use with each distinct modification or other
software.  The first avoid the problem of defining distinct
triggering uses that ought to reset the clock.  The latter
accept the problem, and solve it incompletely.

The alternative to all of this is to drop the grace period
entirely.  It would be possible to comply with that license,
assuming you work "in the open" and apply the same public
license to your code.  But we all know not everyone, in
every context, can do that.  We could build in retroactive
forgiveness for those that eventually publish Open Source,
but that vitiates the incentive to comply in the first
place.

In practice, I expect some L0-R licensors will choose a
grace period reflective of the short time frame needed to
publish code, on the order of days, and some licensors will
choose a grace period like a free trial, on the order of
weeks.  Since the actual number of days will be arbitrary,
my gut tells me to keep it generic, and work toward
something OSI can approve with a placeholder.  That I
shouldn't rely on whether n days, for some n, feels
reasonable or workable to satisfy OSD's values.

> - How do you picture the time limit being enforced?  If a licensor
> encounters potential infringement, how will he or she know how long the
> infringing code has been in use/distributed/built?

1.  Note potential compliance.  Set a reminder to...

2.  Check for compliance some time later, perhaps the length
    of the grace period.  Can we find their code online?

3.  Cease and Desist to the potential offender.

If the licensee can provide evidence of compliance that
makes a suit untenable, the licensor moves on.  If they're
unhappy, say, with the breadth of distribution of the code,
OSD-conformant terms and information about the whereabout of
the code should enable them to redistribute more broadly.

Conceptually, it's akin to knowing when you can C&D an
(A)GPL infringer.  There's always a chance they've made
source available in some way you didn't happen to find.
There is a difference, playing off the fact that OSD is less
specific in how source must be provided than, say, GPL-3.0.
But referencing the Open Source Definition by name is so
valuable, readability wise, that I don't think I'd trade it
back for my old language, which spoke in terms of
"publication" and OSD-conformant license terms.

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