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

[Kyle Mitchell]

On 2017-10-23 21:10, Bruce Perens wrote:
> On Mon, Oct 23, 2017 at 7:48 PM, Kyle Mitchell <kyle at kemitchell.com> wrote:
>
> >
> > Can you give an example of a net-freedom-reducing use
> > condition targeting license terms or source publication that
> > backfired?  Do you believe that _all_ use-based conditions
> > are doomed to backfire, that we can't write effective ones?
> >
>
> I mentioned the Berkeley SPICE one. But mainly the problem is keeping the
> legal load on passive users low.  Use restrictions, of course, effect
> users. And I really did consider that when writing the OSD.

As I understood it, the SPICE limitation didn't say anything
about licensing or source availability.  I imagine it had
more to do with human rights, or perhaps Apartheid specifically.

Just to check my understanding:  By "passive users", do you
mean users of the software as distributed, without
modification?

> > That language reads:
> >
> >   The license must not restrict anyone from making use of
> >   the program in a specific field of endeavor.  For example,
> >   it may not restrict the program from being used in a
> >   business, or from being used for genetic research.
> >
>
> While use restrictions are the main way that proposed licenses fail the
> field-of-endeavor language, they are not the only one. Coupling other
> license terms to fields of endeavor would also fail. No arguments about why
> the OSD should then ban the GPL, please. We've disposed of that one.

My concern here is that OSD 6 as written apparently means
both what it says, in very general terms, and also something
else entirely, and far more specific.  You may have disposed
of the GPL argument with condition 6 as you expanded on it.
But proprietary software either is a "field of endeavor", or
it isn't.  If it is, then you have to read "not restrict
anyone from making use" oddly, narrowly, and very
specifically to avoid current copyleft implementations.

Those are the words on the page.  Words flex, sure, but
sometimes farther than credulity can follow.  I have immense
respect for how difficult a document like OSD is to write.
Harder, I'm sure, than any specific license.  But if OSD 6
needs other words, after so many years, to say what it
means, then OSI should add and explain those words.  They
should be as public and accessible as the rest of OSD is
today.

> > So in your opinion distribution with modifications is the furthest copyleft
> > can go?
>
>
> No. Actually I don't know how you got there, since we haven't been
> discussing distribution.
>
> Consider a license with these terms:
>
> *If you modify the program, you must publish the modification in the source
> code form preferred for modification. As an exception to this rule, you are
> not required to distribute source code during private development of your
> modification. This is defined as until you distribute the program, use it
> for another legal entity, or allow another legal entity to use it.*
>
>
> See what I did here? I inverted a use restriction into a permission which
> lets you out of a license requirement.
>
> The requirement for this to work is that the first statement be legal under
> the OSD. So:
>
> *If you modify the program, you must publish the modification in the source
> code form preferred for modification.*
>
> That's OSD-compliant and it's the only requirement or restriction. Then:
>
>
> *As an exception to this rule, you are not required to distribute source
> code during private development of your modification. This is defined as
> until you distribute the program, use it for another legal entity, or allow
> another legal entity to use it.*
>
> This is only a permission. There's language like this in GPL 3 with regard
> to the Novell-Microsoft patent license.
>
> *unless you entered into that arrangement, or that patent license was
> granted, prior to 28 March 2007.*
>
> OSI approved the license.

I must be missing something.  This seems to elevate form
over substance in a pretty dramatic way.

Under copyright law, would-be licensees start with no
permission, other than fair use and other narrow carve-outs
from copyright as a whole.  By effect of a public license,
they end up with some set of permissions, subject to
conditions that whittle those permissions down, and perhaps
some exceptions to some of those conditions.  The end result
is a set of actions licensees may now take without liability
that they could not take without liability before.

Most Open Source licenses, including BSD-2-Clause, start out
by granting permission to do pretty much everything.  Then
they pare the broad grant back with conditions.  So
BSD-2-Clause's preamble, alone, would permit redistribution
in source form without notices.  But the preamble plus
condition 1 takes source redistribution without notices
back.

That's just a drafting choice, an implementation choice.  We
could "invert" BSD-2-Clause as "You may: ..." followed by an
exhaustive, numbered list of permission grants, rather than
a broad grant followed by restrictive conditions.  If we did
the job right, the resulting set of licensee permissions
would be the same.  In other words, we could "refactor" it.

I'm puzzled as to why "inverting a use restriction into a
permission" makes otherwise non-conformant terms conformant.
Isn't the legal effect the same?  Don't most approved
licenses pare permissions back with restrictive conditions
on a broad grant, rather than long enumerations of
affirmatively stated permissions?

I note that the language you propose _does_ differ from
going L0-R condition 3, in that it permits indefinite
private use of private modifications.  Is that relevant in
making it OSD-conformant, in your view?  It comes up fairly
often in FSF's comments on licenses.

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