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

[Kyle Mitchell]

Bruce, you have some lawyer in you! You've found a reading
of OSD that prohibits L0-R condition 5. It's complex, too.
And internally consistent.

Unfortunately, not externally consistent. It breaks three
rules even lawyers, inveterate twisters of words, abide by.
It ignore natural readings of OSD in favor of selective
ones. It reads rules into OSD that aren't grounded in any of
its words. And it reads criteria in ways that disqualify
approved licenses when reapplied to them, consistently.

As I understand your reading:

1. Analysis, modification, and generation of software is a
   "field of endeavor" under OSD 6.

2. As a result, both GPL and L0-R fail OSD 6.

3. In OSD 2, "the program" means not just the software
   licensed, but software built on it. You mentioned
   combinations. I take it you include less controversial
   modified versions, too.

4. OSD 2 says open source licenses have to make sure "the
   program" comes with source code.

5. OSD 2 trumps OSD 6.

6. As a result, GPL conforms, but L0-R does not, because
   GPL's conditions ensure "the program" comes with source,
   but L0-R overshoots, ensuring other programs come with
   source, too.

That's a lot of surface area. Back-references to numbered
items above appear in square brackets below.


# Unnatural Readings

[4] The idea that a license can fail one of the criteria and
still conform to the Definition runs right against the
preamble: "The distribution terms of open-source software
must comply with the following criteria." To conform to the
definition, don't license terms have to meet all ten?

[3] It's strange to read "the program" to mean not just the
program as provided, but also modified versions and
combinations. Reading OSD 6-8 the same way seems to make OSD
_require_ copyleft. Otherwise a few of those guarantees are
just for the program as provided.

[4] OSD 2 talks about allowing distribution in source and
binary. That's clearly something licenses do. But the part
you quote, "the program must include source code", isn't
anything a license can achieve, only encourage. It can't be
a "must" for the license, just the circumstances of the code
to which the license applies.

[4] The first sentence of OSD 2 comes verbatim from DFSG.
Isn't it natural to read it in the distro context, as you've
read OSD 1 and OSD 9? If Debian can't find the source, just
a GPL-licensed binary, it isn't free software and won't be a
part of Debian, even though its license conforms. On the
other hand, reading source availability and license terms
conformance apart follows OSD's preamble, which
distinguishes source code access and "distribution terms".
DFSG was about packages, and OSD is about one particular
part of a package, its license, so it makes sense that
language retained from DFSG overhangs a bit.


# Not in the Text

[5] There's no language in any part of OSD about one
criterion overriding or carving an exception out of another.
The criteria don't refer to each other. Other than the
preamble, there's no framing language about how they relate.
It's very possible to read each as standing independently,
adding up to the whole definition.


# Inconsistent Interpretations

[4] Interpreting OSD 2's "[t]he program must include source
code" as a license _requirement_, and "the program" to
include modified versions and combinations, causes problems
for permissive licenses that allow redistribution of
modified versions and combinations without source or offers
to provide it. Like BSD, an example in DFSG 10.

[2] For completeness: To the extent OSD 2 overriding OSD 6
doesn't hold, your interpretation of OSD 6 excludes many
copyleft licenses, including GPL, as you mentioned. It might
exclude _all_ currently approved copyleft licenses.


# Why These Problems Matter

I respect that you know what you meant by the criteria.
Others approve of, and rely on, what you wrote. Not
stretching or adding to the text keeps applied meaning and
approved writing together, as a social contract.

Consistent interpretation keeps us honest, stops us from
picking between readings for specific licenses to achieve
specific results. It also shows we're honoring the
Definition, and helps teach others how to do so. Bucking
consistency leaves open the possibility that you read
selectively to exclude L0-R by any available means, setting
aside shared understanding.

You've written that some on the board are tired of following
precedent, instead of policy and principle. I never met a
judge, especially a long serving judge, who wouldn't
sympathize. But I've never met a judge who wouldn't apply
the same standards I have here to overturn a peer's
decision. Because precedent rules protect legitimacy. They
come with every democratic stewardship position.

If OSD isn't part of a social contract, as DFSG are for
Debian, or OSI wants to stop treating the Definition as
such, that ought to be a very explicit, public decision.
Accountability solely for outcomes, without any social
contract, can be very expedient. But careful readings of OSD
either matter, and ought to both make and honor precedent,
or they don't matter, or only as rhetoric, because in the
end it's all about personal judgment. If the former, you
need to amend your reading, or amend OSD. If the latter,
please ask Simon or Richard to say so. That would settle it,
and I would go away.


# Missing from OSD 9

If anyone had mentioned L0-R-style reciprocity in 1997, they
might very well have argued for it, too. I am here to argue
for it now. I regret appearing some twenty years late. But
as far as I know, the idea turned up in 2017, too.

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