[License-review] Consensus on L0-R

[Kyle Mitchell]

On 2018-06-20 00:06, Bruce Perens wrote:
> On Tue, Jun 19, 2018 at 9:31 PM, Kyle Mitchell <kyle at kemitchell.com> wrote:
>
> >
> > I've responded to this conclusion with history:
> >
> > http://lists.opensource.org/pipermail/license-review_
> > lists.opensource.org/2017-November/003292.html
>
> So, here you create a rather convoluted argument for the OSD not being
> externally consistent

Actually, there I point out that RPL, a license OSI approved
in two versions, decades ago, requires release of private
changes, closes the ASP loophole by a condition on a kind of
use, and extends reciprocity beyond modified versions and
combinations.  Their gap to close was web frameworks.
L0-R's is development tools.

In the message here, I argue that _your reading_ of OSD to
damn L0-R was not externally consistent, and seemed
concocted ad hoc to achieve one particular result:

http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2017-November/003289.html

Fortunately, there are other internally consistent readings
that accord with OSI's approval decisions.

> by ingoring the word "use" in #6 and arguing that
> somehow #2 overrides #6.

I didn't argue for any override at all.  You did, in your
second attempt at an OSD reading to include AGPL and exclude
L0-R, to which I responded.  I stated explicitly that
there's no language in OSD to support any criterion
overriding any other, and in fact the preamble suggests all
be read consistently.

I don't ignore "use", and in fact I've addressed #6 more
than any other criterion on this list.  There's no blanket
prohibition on use restrictions in #6 as written.  Rather,
there's a prohibition on restrictions on use in specific
fields of endeavor.  If "field of endeavor" means running
over a network for others without sharing source or
licensing on like terms, or running to produce output that's
a derivative of the program, OSI has approved licenses that
fail #6.  In theory, AGPL 13 has to fall back on the 106
exclusive rights, despite its language, just as L0-R
condition 5 must.

Fortunately, the more natural reading of "field of
endeavor", and the examples in OSD#6, don't cover means of
endeavoring, like closed, proprietary software development.

> You also ignore #3, which it turns out is important for
> this analysis.
>
> Use and the creation of derivative works are two separate and independent
> rights in copyright law. Use means running the program.

Use is not an exclusive right of copyright holders under the
Copyright Act.  It appears in one narrow provision, 117,
which applies only to owners and distinctly owner-like
licensees of copies.

To use your term, use was "synthesized" as a copyright
holder privilege, based on the fact that execution without
reproduction, preparation of a derivative work, or
distribution is practically impossible.

> So here is a valid analysis without any rule overriding another, without
> self-reference, quite simple:
>
> #2 requires that the program be available in source code form. It does not
> make any reference to derivative works.
>
> #3 requires that derivative works be allowed, and that it must be permitted
> for them to be distributed under the same license as the original work. It
> is not required for derivative works to be allowed under any other license.
> It makes no reference to use.
>
> #3 has an important application that you might be missing: In requiring
> that the derivative works can be distributed under the same license as the
> original work, it requires that licenses with terms that require source
> code distribution, if used on the original work, must be capable of being
> *applied* to a derivative work. Thus, it permits the GPL.
>
> #6 requires that the program can be used for any purpose.
> It does not make any reference to derivative works.

See above.  "Field of endeavor" is important in how others
understand OSD #6, to save existing network-copyleft
licenses.

As for OSD reading number three, I'm sorry, I don't follow.
How is L0-R troubled by this reading?  Re #3, derivatives of
L0-R code can be licensed under L0-R:

  Releasing source code means publicly licensing it under
  either this license or a license approved by the Open
  Source Initiative, and promptly publishing it...

What do #2, #3, and #6 require that L0-R fails to provide,
or prohibit that L0-R requires, that doesn't boil down to
"any use restriction"?

> You are also assuming that I was unaware of the fact that programs could
> process programs when I proposed the OSD.

You mentioned that you hadn't considered a license with a
term like L0-R condition 5, but that if you had, you would
have prohibited it in your draft.  That motivated my
response:  If you'd addressed it in your draft, someone else
may have taken issue between proposal and adoption, for OSI
or Debian before it.  It's come up now instead, and I am
here to argue for it now.

> > I am not sure how your are discerning consensus.  I do recall you and
> > Carlo came out definitely against conformance.
> >
>
> Yes, and you objected, and none of the reviewers spoke on your behalf at
> that point (you're not a reviewer of your own license).

Silence is not consensus.  Especially in light of the
demands on participants' time repeatedly voiced here.

This is consensus deployed as a procedural weapon, not
sought as a goal.  In healthy consensus-based organizations,
a block starts a conversation, never stops it.

Richard has written that it's arguably conformant with OSD
as written.  (I take it he might amend OSD to change that
result.)  He can obviously speak for himself.

> > I'm asking OSI to approve an evolved reciprocal license that says, in
> > essence, what Richard and others said GPL was meant to say in its day
>
> No, actually FSF's "Four Freedoms" also prohibit LR-0. "Freedom 0": *The
> freedom to run the program as you wish, for any purpose.*

  I make my code available for use in free software, and not
  for use in proprietary software, in order to encourage
  other people who write software to make it free as well. I
  figure that since proprietary software developers use
  copyright to stop us from sharing, we cooperators can use
  copyright to give other cooperators an advantage of their
  own: they can use our code.

  https://www.gnu.org/philosophy/pragmatic.html

FSF's own drafting implies the same kind of more nuanced
understanding of Freedom 0 as OSI's approval of AGPL implies
of OSD #6.  I'm not free to run AGPL software for the
purpose of providing proprietary network services to others.

RPL predates AGPL.  FSF's advertises no mechanism for
after-the-fact clarification.  I wish they did.

> > Approved licenses _do_ mention or address exceptions and parallel terms.
> > Artistic (directly).  Apache (warranties). GPL (if you count writing in for
> > an exception).
> >
>
> Sorry, what's the point here?

Even mentioning dual-licensing in a license text doesn't
stop OSI approving it.

The point is moot.  The current draft of L0-R no longer
mentions dual-licensing.

> > We've addressed this.  If popularity is required for OSI
> > approval, OSI should say so.
>
> We just heard this evening from Allison about the license having some
> meaningful value. Users would be one way to attest to such a value.

No one has opposed L0-R as duplicative of a currently
approved license.  It's novel.  There is value in that.

But "value" will always be little more than a conduit for
summations of personal views.  It's even looser than
"policy" or "good for the community".

That's no fault of Allison's.  She hasn't been stuck into
the back-and-forth on L0-R, as we have.  If we want to know
what she meant, or what the board means, we should ask.  And
whether, say, BSD+Patents demonstrated a user base prior to
approval.

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