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

[Kyle Mitchell]

McCoy,

Thanks for your time, as well.  Very generous!

And congrats again on getting BSD+Patents through.  Poor
BSD-2-Clause has a whole flock of hungry lawyers circling
above it these days...

Please forgive me for reflowing your message. I prefer
unbroken, plain text myself, but keep getting chided for it,
and am back to wrapping at 60.

On 2017-10-20 20:10, Smith, McCoy wrote:
> I had similar drafting concerns as did Richard, as well as
> others.  The goal with this license is still a bit murky
> to me (the way I read it and understand the mailing list
> discussion, the goal here is to create a permissive
> license that may be relicensed under any copyleft license
> that meets the OSD, but for a short grace period where it
> might be relicensed under any other license model), and I
> think there are probably better ways to achieve this goal
> with greater clarity (and to avoid questions of OSD
> compliance that others have raised).

Thanks for a chance to revisit the goal at a high level.  I
tried to lay that out in my initial submission e-mail, per
the instructions on the webpage.  There's been a whole lot
of typing since then.

L0-R's goal is to implement a share-alike license that
triggers in even more situations than AGPL, but is easier to
comply with once triggered.  It starts with BSD-2-Clause and
adds conditions that require sharing alike of modifications,
incorporating software, and software built with.  However,
the licensing part of share-alike needn't take the form of
L0-R terms.  Any OSD-conformant terms suffice.

> 1.  I agree with Richard that the grace period concept, as
>     currently formulated, is arguably non-conformant with
>     OSD 6.  I also think that the way Richard has
>     reformulated it solves that potential problem.  It
>     also is more consistent with how other, more recent,
>     OSD approved licenses do things; see, for example, the
>     grace/cure periods in Sec 8 of GPLv3.  So, rather than
>     saying "you may only do X for the following number of
>     days," saying "you must do Y within the following
>     number of days" gets away from questions about whether
>     you are excluding a specific field of endeavor, which
>     is prohibited by OSD 6.  Another tack, which I think
>     is more consistent with your goals here, is to say
>     "you must relicense under a license that obligates, as
>     a condition of exercise of rights, that source code be
>     disclosed" (or something along those lines) to
>     eliminate the concern you seem to have about
>     permissive licensing allowing for the option of
>     non-open source (aka commercial) forking.  The grace
>     period to me seems like a fairly unimportant part of
>     the goal of your license, unless you are trying --
>     like the authors of GPLv3 -- to make clear that users
>     have a certain period, greater than instantaneous, to
>     conform without being in a state of breach or
>     infringement.

The concern about "instantaneous" compliance was my
motivation.

As a practical matter, I know many devs who work "in the
open" by default, for whom an unmitigated requirement to put
new code out wouldn't pose any problem.  But that just isn't
possible in different work environments.  L0-R doesn't want
to force devs who can't work like that to do so.  Rather,
it's about seeing the code in the open, eventually.
Share-alike as in "share your work like we have", not "work
like we do".

I will need to put a bit more thought on the difference
between "you must do A in X days" and "you may only enjoy
this license without doing A for X days".  How one falls
afoul of condition six, and the other doesn't.  On first
pass, that sounds awfully formalistic.  When GPL says "you
must", the legal effect is really "it's a condition of this
license that you", right?  There must be something I'm not
grasping here.

> 2.  The use of "Open Source" in quote marks is potentially
>     confusing given that's not a defined term by the OSI.
>     The OSI promulgates the Open Source Definition (OSD
>     for short) so I think you should be using that
>     terminology.

How about:

  ...that does not conform to the Open Source Definition
  published by the Open Source Initiative...

>     Also, it is not "software" that meets
>     that definition, it is the license associated with it.

I believed this, too, until some back-and-forth on this
thread.  And as first proposed, L0-R's reference to Open
Source read:

  ...that is not published in original source code form and
  publicly licensed under the terms of this license or terms
  approved by the Open Source Initiative as "Open Source"...

"Open Source" versus "Open Source Definition" aside, that
reflected the idea that OSD is only about license terms.  If
OSD doesn't say anything about source availability, L0-R had
to do so itself.

But then OSD 2 says:

  The program must include source code.... Where some form
  of a product is not distributed with source code, there
  must be a well-publicized means of obtaining the source
  code for no more than a reasonable reproduction cost,
  preferably downloading via the Internet without charge.
  The source code must be the preferred form in which a
  programmer would modify the program.  Deliberately
  obfuscated source code is not allowed.  Intermediate forms
  such as the output of a preprocessor or translator are not
  allowed.

Clearly, those aren't license criteria.  A license can't
achieve any of that directly, and could do so indirectly,
for the original licensor, only by means of a warranty.  The
closest I've seen is a provenance warranty, in Larry Rosen's
licenses.  Never a source-available warranty.

All manner of concerns about "publication" came up in
discussion, too.  Valid concerns.  Rather than try to
reimplement the source availability criteria laid out in
OSD, I reference them.  L0-R was already referencing OSD for
terms criteria.

>     Better terminology would be something along the lines
>     of "software licensed under a license that meets the
>     Open Source Definition from the Open Source
>     Initiative."  Note, however, I think it is smarter to
>     instead say "software that is licensed under a license
>     certified as meeting the Open Source Definition by the
>     Open Source Initiative" since tying your license terms
>     to the definition means that there are any number of
>     licenses that have never gone through the review
>     process (and which may in fact be non-OSD compliant)
>     that may be swept up into the options of your license.
>     By way of example, the Clear BSD License:  It is on
>     the FSF's list of "free software" licenses, but not on
>     the OSI list.  There are good reasons for that (as
>     described in the warnings on the FSF page).  Can LZPL
>     code be relicensed Clear BSD?  Is that a result you
>     want, given the concerns some have with that license?

Point taken on the scope of "OSD-conformant".  I hear there
are a few "crayon licenses" in there, too, which Bruce would
like to redo in white-out.  On the other hand, I'm told L0-R
may not end up in the club, either, precisely on the
difference between OSD-conformant and what OSI will approve.

As for relicensing:  A modification to L0-R code could be
licensed, say, MIT, and comply.  But I don't see L0-R
permitting relicensing from L0-R code itself to MIT.  MIT
grants more permission than L0-R licensees receive, due to
the new conditions triggering source and licensing
requirements.

> 3.  As Richard has noted "uses with modifications" is
>     quite confusing.  I think you are referring to
>     conditions imposed upon modifications of code licensed
>     under LZPL; if so, you should say that.  If not, it
>     sounds to me like you are trying to impose
>     restrictions upon
>     other software (that software that is used with
>     modifications of LZPL software), which would be a
>     violation of OSD 9.

Does reversion to "use with modification", a callback to the
BSD grant language, alleviate the confusion here?

> 4. "Uses as part of, or in development of, other software"
>    seems to be a clear limitation on other software, and a
>    violation of OSD 9.  I'm not sure what you're getting
>    at here that is different than in the prior paragraph.
>    "Part of" seems to be getting at the same concept as
>    "modifications" in the prior paragraph.  "In
>    development of" seems to be targeted at the same thing,
>    or else is an effort to impose conditions on software
>    in no way derived from LZPL licensed software, which
>    would fail OSD 9 (and is probably copyright misuse as
>    well).
>
> It might help if you were to more clearly articulate (on
> the board, or to yourself) what it is you want people to
> do, and not do, with LZPL licensed code, articulate those
> in a draft of the license (using language more consistent
> with the rights granted in BSD), and then compare those
> against, in particular, OSD 6 and OSD 9 to ensure that
> neither the goals, nor the explicit language, of your
> provisions are inconsistent with those parts of the
> definitions.

Sounds like examples are in order.

A distributes a Python parser generator, X, under L0-R.

B patches X to improve its performance.  X does not release
source code for its patch.  After a time, B falls afoul of
L0-R condition 3, for use with modifications that are not
Open Source.

C writes a file transfer program in Python that imports X as
a package.  C uses X as A distributed it.  C provides copies
of source for the whole transfer program to users, including
for X, but licenses its code "on top" as proprietary
software.  B falls afoul of L0-R condition 4, for use of X
as a part of proprietary software.

D uses X, as A distributed it, to generate a parser for a
compiler.  B sells the compiler on proprietary terms.  B
falls afoul of L0-R condition 4, for use of X in the
development of its compiler, which is not Open Source.

E includes X in a software distribution, to be provided on
physical media, online for download, and for installation on
provided infrastructure.  Other software in the distribution
is proprietary.  E retains X's notices with its source.  E
is in compliance with L0-R condition 1.

F includes a compilation of X to native code in a similar
software distribution.  F reproduces X's notices in
accompanying documentation.  F is in compliance with L0-R
condition 2.

G runs X, just as A distributed it, to compare its output to
that of another parser generator.  F is in compliance with
L0-R, under the general grant of permission.  No conditions
read on G's use without modification.

> I also find the argument that you're trying to do
> something that AGPL, or LGPL, or some other OSI approved
> license is trying to do, but in a different way, to be
> muddling the discussion.  In general, the discussion (per
> the submission guidelines) should focus on conformance
> with OSD, the rationale for your license ("Compare to and
> contrast with the most similar OSI-approved license(s)":
> i.e., what additional features beyond 2-clause BSD this
> license provides), and perhaps why particular language you
> chose is being used.

Discussion here on the list has ranged broadly, and often
far afield of my initial proposal, responsive to the
questions the OSI approval-process page lays out:

https://lists.opensource.org/pipermail/license-review/2017-September/003097.html

I'm happy to talk about any aspect of the license, and
understand it's my part in this process to do so, whether
questions go immediately to OSD or not.

That being said, I've taken pains to ask repeatedly whether
a concern is OSD- or policy-driven.  That prompted more
general discussion on the role of additional policy
considerations, how they bear on this process, and L0-R's
fate more specifically.

As for goal, L0-R does not try to reimplement AGPL-3.0's
trigger.  L0-R aims to implement a trigger that fires in
more situations than the combination of GPL and AGPL 13.  In
order to address the ASP loophole, AGPL triggered source
provision requirements on a kind of use, namely use
facilitating interaction over a network.  L0-R follows that
line, implementing copyleft entirely in conditions on use,
rather than on distribution.

Use conditions strike me as more powerful.  I think we see
that in proprietary software, where seat-count,
running-instance, and other limits get implemented as
use-based conditions, and work.  And I think use conditions
can plug copyleft loopholes that distribution conditions
can't.

With the added power comes a risk of gotchas and overreach.
Hence a felt need for a grace period, as a mitigation. Maybe
that's not the right mitigation.  But that's the motivation.

I don't think anything I've mentioned wanders into copyright
misuse territory, any more than, say, a noncommercial
limitation would.  Especially when acquiring a copy, or
executing it, implicates 106 exclusive rights.

> As an aside, a permissive license that allows for copyleft
> forks but not permissive or proprietary forks might be an
> interesting option, if that's what you're trying to get
> at.  I don't think that there is anything right now on the
> OSI list that does that.  But right now it's not clear to
> me that's what you're getting at.

L0-R aims to be a copyleft license that allows forks, the
additional code of which may be licensed under any
OSD-conformant terms, permissive or copyleft.

I agree a permissive-to-copyleft only license would be an
interesting exercise. If you ever try to write one, let me
know.  I'd be interested to help as I can.

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