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

[Kyle Mitchell]

On 2017-10-23 18:10, Bruce Perens wrote:
> On Mon, Oct 23, 2017 at 3:08 PM, Kyle Mitchell <kyle at kemitchell.com> wrote:
>
> >
> > 1. Why are net-freedom-enhancing conditions on distribution
> >    permitted, but net-freedom-enhancing conditions on use
> >    prohibited?
> >
>
> Because net-freedom-enhancing conditions on use were not necessary, given
> that we had distribution and modification to hang them off of, and there
> were examples of net-freedom-enhancing conditions on use that had backfired
> and become net-freedom-reducing. So, I wrote the rule that way.

Interesting.

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?

That being said, all things being equal, I'd like to be
convicted specifically, not by association!

> > 2. What's the basis in OSD for that distinction?
>
> The OSD language on field of endeavor restrictions. Now, you are attempting
> to avoid that by coupling modification and use together in your
> restrictions, awkwardly and unnecessarily.

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.

It's very, very hard for me to read that as:

  The license must not put conditions on any kind of
  permission but permission to distribute with
  modifications.

Moreover, it's perfectly possible to write conditions on
distribution with modifications that violate the criterion.
For example, a license condition that says licensees may not
distribute with modifications that enable interoperability
with military systems or standards.

> > 4. Industry developments---ASP, PaaS---are making that
> >    distinction less and less relevant.  Doesn't
> >    confining copyleft to distribution-triggered
> >    conditions fundamentally hobble it as a technique for
> >    driving a good reciprocity bargain?
>
>
> Not really, because you can do all that you desire with modification alone.

I cannot.

If I include an L0-R-licensed Python library package as a
dependency of a project, to be run as distributed by the
original author, I don't think I've "modified" the package
in any plain sense.  If I utilize an L0-R-licensed binary
optimizer to improve a proprietary software program, I don't
think I've "modified" the L0-R program, either.

> > In other words, is AGPL the furthest copyleft can go?
>
>
> Not at all. If you want to hang your terms on modification, you can still
> do that. You can activate your terms on private development (which OSD does
> not prohibit but some may take exception to), or you can make _exceptions_
> to your terms that protect private development and are permissive rather
> than restrictive.

So in your opinion distribution with modifications is the
furthest copyleft can go?  Perhaps with some allowance for
"saying use, but meaning distribution" aberrations, like
AGPL-3.0 section 13?

That would be a tight collar around copyleft's neck.  A
statement, in effect that only a subset of the power of
copyright is available to be turned back around on
copyright.

As I've mentioned elsewhere, a great many of the most
common, and powerful, proprietary software licensing models
reach right for use language, or don't bother distinguishing
which exclusive rights under copyright will be trampled in
violation.  Concurrent-user, seat-count, and
running-instance limits, to give a few examples.

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