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

[Kyle Mitchell]

On 2017-09-26 11:09, Carlo Piana wrote:
> On 26/09/2017 04:07, Kyle Mitchell wrote:
> > "Use in the execution and development of any computer
> > program" is written in technical terms, not legal terms.
> > Court I'm familiar with will see those word choices,
> > gather that they are technical terms, rather than legal
> > ones, and ask, "What would software people mean by
> > 'execution and development'?".  The court would ask for
> > evidence from software people, not lawyers.
> >
> > You gave a specific example.  As a software person, I
> > _would_ read the language to apply to programs compiled
> > with an L0-R compiler.  Yes, that's new.  And
> > intentional.
>
> Besides it being against the OSD, I find this concept fairly
> overreaching on general policy grounds.

Might I ask what those policy grounds are?

A number of folks, on the list and off, have mentioned
policy considerations separate from OSD conformance.  Not
everyone seems to agree OSI should do more than apply OSD,
but in conversation with most of those who do, I'm at a
loss.  There doesn't seem to be any document setting out
what OSI's additional policy constraints are, or what, if
any, relationship they have to OSD itself.

I'm very grateful to those, like John Cowan and Bruce
Perens, who've taken the time to go back and forth with me.
I get a better picture of the policies that matter to those
individuals that way.  But it takes a lot of time, and I'm
sure my understanding won't ever be perfect.  Reproducing
that experience is a lot to ask, both of those proposing on
license-review, and of those responding there.  Having
achieved it, it still isn't clear which of whose policy
concerns will affect OSI's public decision on the license.

Returning to L0-R, if the policy position is that license
conditions that require reciprocity can go no further than
AGPL, then I'm wasting time indeed.  Someone should stop me
before I take any more.  But that would be, I think, a
momentous shift for OSI and the meaning of OSI approval.

If permissive-side terms can get more or more permissive,
even at the cost of legal uncertainty and risk to
developers---for example, in FPL/0BSD---but copyleft terms
can't evolve in their own direction, then OSD plus OSI
policies make a ratchet that turns only away from copyleft,
and toward pushover licenses.

> > As for the Definition, I'm afraid I can't read it as you
> > do.  OSD criterion number 6 prohibits limits on use of
> > software in "fields of endeavor", not all limits on use,
> > flat-out.  It gives two examples, business and genetic
> > engineering, that are broad reasons for using software,
> > not choices about how to license software.  And we all
> > know a famous counterexample, the JSON License's
> > prohibition on use for evil, very broad indeed.  OSI's
> > annotations describe the major intent of the criterion
> > to exclude noncommercial use limitations.  Commercial
> > use of L0-R code is very possible.
>
> Again, this is plainly wrong. It means that you cannot *use* (mind: not
> distribute, just use) this software in a legal way if the software you
> are interacting with is not under a license that allows you sharing the
> code either on legal or material grounds (e.g., it's BSD, but you didn't
> receive the source). That limits the field of endeavor very much indeed.
> The examples are just examples. "Genetic research" is no different from
> "Proprietary software development and/or consumption". You may find a
> confirmation in #9 as well: the same rationale applies here.
>
> JSON limitation, besides being rather vague and undefined and ultimately
> probably inapplicable, is not AFAICT an OSI approved license, and you
> can read many comments online criticizing (I seem to remember discussing
> it here or maybe in other licensing discussion fora, sorry, can't recall
> it precisely).

If "proprietary software development and/or consumption" is
a field of endeavor against which an OSD-conformant license
can't discriminate, how do _any_ copyleft licenses conform
to the definition?  Criterion 6 isn't specific to conditions
on use, or indeed to license conditions at all.

To quote Stallman, from "Copyleft: pragmatic idealism":

  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.

That's discrimination.  But is it discrimination against a
"field of endeavor"?  Apparently not.

On the other side, some business firms choose to
discriminate against Open Source and Free Software, such as
by adopting a proprietary-software business model.  But as
the open community has grown, we've seen more and more firms
based on Open Source competing with proprietary-software
incumbents.

Moodle competes with Blackboard, for example.  The field of
endeavor is education.  The choice of proprietary or open
software is evidently independent of the field.

> > We know from the choice of words, from the examples,
> > from the annotation, and from the approval of licenses
> > like AGPL, that the criterion does not prohibit all
> > possible limits on use.  Modifying an AGPL program and
> > using it in such a way that users interact with it
> > remotely, without any opportunity to receive source, is
> > not permitted.  But AGPL meets the Definition, including
> > criterion 6, even if users over the network never
> > receive any copy of any part of the software.  Often
> > they don't.
>
> AGPL limits the use of the software as well, but only insofar as you
> provide public access to the software you are running. If you use it
> privately, then you can modify it at leisure. The example is way way
> different.
>
> The fact that people would not use of their right is immaterial, the
> license sets copyright conditions, and these conditions by no means
> WHATSOEVER limit your use if this use does not involve network access.
>
> I agree that AGPL stretches a bit the Definition, but not on the right
> to use, rather on the right to MODIFY the software, and only if you aim
> this in a situation which is functionally equivalent to distribution.

You've echoed some very important points from my
back-and-forth with John here.  John can speak for his own
point of view---and does, very capably!---but I will try to
recap the key points of my part in it.

On AGPL and use versus distribution:

I bring up AGPL to show that the Definition has room for
conditions that go beyond legal "distribution" of a
"derivative work".  Especially to address technical
loopholes that permit taking from the open/free community
without giving back, on technicalities.  Loopholes that pose
a fundamental threat to copyleft as a strategy.

Applying that pattern forward, AGPL has a tools loophole.  I
can arguably run modified AGPL software on my own hardware,
use it to generate any number of useful outputs, and grant
access to those outputs behind a software service.  And I
can keep my patches to myself, as long as users never
"interact" with the AGPL software itself.

In other words, anything one step removed from interaction
over a network gets a free pass.  Depending on the software,
I can potentially "distribute" all of its utility, in the
sense I think you mean, so long as I don't also distribute
the experience of "interaction" with it.  Does OSI policy
prohibit closing that loophole?  How do we close it without
a more exacting, and use-based, trigger?

AGPL's muddying of the use-distribution distinction is
symptomatic of what's going on in the industry.  Hosted
software and rental infrastructure make the boundary less
and less clear, less and less relevant.  Folks' interests
tend to get distributed across a whole swarm of computers
these days, even when the folks aren't programmers.
Relatively few of those computers are directly owned or
controlled; we have no idea where execution takes place, or
how many network segments are involved.  If copyleft can't
respond to that trend, staying within the Definition, again,
the Definition's a noose around copyleft's neck.

On unmodified use:

A recent revision to the L0-R license text, posted elsewhere
on this thread, helps to clarify that unmodified use does
not trigger copyleft requirements.  The intent of L0-R is
nothing more or less than requiring publication of source
and Open Source licensing of modifications, incorporating
software, and software developed with tools.  I'll be
posting another revision shortly that I think makes that
even more clear.

On use conditions generally:

I absolutely concede that conditions on use are different
from conditions on distribution.  In my mind, the question
L0-R asks is:  Given that, why can't use conditions conform
to the Open Source Definition?

DFSG, OSD after it, and "What is free software?" were all
written, to some extent, as generalizations of existing
licenses, GPL among them.  They all speak in terms of
absolute freedoms, or prohibitions on restricting freedoms.
Then they make room for copyleft.  Sometimes they seem to
carve out a very specifically GPL-shaped hole, so tight a
fit that one wonders how AGPL fits.  Sometimes they speak to
copyleft at a more general level, closer to that of the rest
of the definition.

For an example of the former, FSF's "What is free software?"
states freedom 3 absolutely:

  The freedom to distribute copies of your modified versions
  to others (freedom 3).

and only later, in a subsection of the part about freedom 3:

  Certain kinds of rules about the manner of distributing
  free software are acceptable, when they don't conflict
  with the central freedoms.  For example, copyleft (very
  simply stated) is the rule that when redistributing the
  program, you cannot add restrictions to deny other people
  the central freedoms.  This rule does not conflict with
  the central freedoms; rather it protects them.

There's no such "Copyleft" carve-out from the discussion of
freedom 0 (use), and no discussion of whether conditions on
freedom 0 could be freedom-protecting.  As a result, "What
is free software?" might be _more_ specific about
permissible conditions than OSD.  Under FSF's definition,
I'd ask:  Why can't we leverage conditions on use to protect
the four freedoms, too?  Up until AGPL, that wasn't the GPL
approach.  Perhaps it isn't the approach FSF thinks best.
But isn't it consistent with the values?

The effect we'd expect from L0-R-style conditions is more
Open Source releases, on the one hand, and more support for
Open Source, in the form of fees for "selling exceptions",
on the other.  The result of either is Open Source
enhancing.  That's the structure that L0-R attempts to
implement.  When the definitions and maintaining
organizations speak of copyleft in anything like general,
architectural terms, they accept conditions on protected
freedoms generally, not just on distribution.  At that
level, I think they describe L0-R.

An aside on AGPL:

I do not believe AGPL Section 13 says anything about
"public" access, directly or through a defined term.  It
requires offering source to "all users interacting with it
remotely through a computer network".

There is some limitation to the distributed-copy based
copyleft trigger in (A)GPL to accommodate private
modifications, say, within companies, or distributed to
others to run at the distributor's behest.  You could
describe those structures in general terms as distinguishing
distribution for "public" and "private" purposes.  But
Section 13 doesn't invoke any of that structure.

Best,

K

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