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

[Kyle Mitchell]

On 2017-10-23 12:10, Bruce Perens wrote:
> While there may be greenhorns or new kids who are unclear on the function
> of OSI, and I understand that many are unclear of what Open Source actually
> means

I see some of that, but alas, I also see better informed
members of the community who know plenty well what OSI does,
see its position on license-driven meaning of "Open Source",
and scoff.  These are contributors who identify strongly, on
a personal level, with "open source".  People for whom "open
source" rings mostly in the kind of collaborative practices,
governance concerns, and social values I understand the
Beyond Licensing Work Group was set up to explore:

https://wiki.opensource.org/bin/Main/Open+Source+Initiative+Working+Groups/Beyond+Licensing+Working+Group+Proposal/

Their view makes me uneasy.  I'm not so quick to dismiss
what OSI is and has done.  And I like to think I know a bit
more history, politically and legally, than the average
bear.  But please be aware that positions on OSD don't just
run a gamut from indifferent ignorance to appreciative
enlightenment.  Whatever happens, OSI shouldn't talk past
those whose views don't fit on that line.  There are more
than a few of them.  Many are doing vitally important work
right now.

> I do not receive reports of the community being upset that more
> licenses are not being approved. If there is any exasperation communicated,
> it is that so many licenses have already been approved and that there
> appears to be no end to the process. Indeed, the best thing the OSI might
> be able to do for the community at this point might be to stop operating
> continuously and only consider licenses at several-year intervals.

If OSI measures need and community sentiment by volume, like
a vote by applause at a battle of the bands, it will always
hear consumers' preference louder than maintainers'.
Software itself, especially with permissive Open Source
terms, fairly well guarantees the former will outnumber the
latter.  And of course users would, as a rule, rather have
the most permissive, legally tenable license they can get.

For example, I built a license metadata audit tool for
JavaScript and npm.  It works with a config file that can
set a whitelist of allowed licenses, by SPDX ID.  The number
one requested feature is setting _negative_ rules instead.
Rules like "no GPL", or "anything but copyleft".  If we put
it to a one-dev, one-vote poll of users, I think they'd boot
GPL off the OSI list!

On the other hand, I speak to a lot of maintainers and
companies producing open code.  I routinely hear calls for a
"new deal" with users, new in any number of dimensions,
implemented in new license terms.  If I don't help them
write those terms, they often end up picking up the crayon
themselves, even if they know they shouldn't.  Here's just
the latest such lay cry for help, from a few weeks ago:

http://lillicense.org/

> I would consider it an active disservice to the community to approve a
> license that had the effect of a present one and was simply shorter and
> purportedly easier for some party to understand but perhaps only in the
> mind of the author.

That's one definition of "proliferation", I think.  But I
wouldn't underestimate how alienating and frustrating is
legal English to minds not yet ruined for it.  Probably the
best-received piece of writing of my career is a
line-by-line rundown of the MIT License:

https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html

I cannot tell you how many folks have sent me e-mail saying,
essentially:

  Thank you so much.  I think I'm finally starting to really
  understand the MIT License, and what licenses do.

But inevitably also:

  But couldn't we rewrite it in a plainer way, so it's clear
  to everyone from the get-go, and they don't have to read
  your huge blog post?

I'm very fond of plain-language drafting in my law practice.
When I offer it as an option to clients, they're often
ecstatic.  So I hear the proliferation concern, but at the
same time, I'd hate to see OSI lock out plain-language
variations by policy.

> The fact that there is some program out there to parse license terms and
> perform combinatorial analysis as if it were "Lawyer in a Box" is not a
> compelling argument for allowing an increase in the combinatorial problem.
> I would much rather have the developers understand the combinations, even
> if this means restricting the number of them, than have them rely on the
> appearance of a legal authority where none is actually utilized.

Ah, forgive me.  I wasn't clear.

SPDX gives us a standardized way to name our license terms
with short identifiers.  So "MIT" means "the SPDX
standardized form of The MIT License".  Package metadata
standards give us files that say "this SPDX identifier
corresponds to the license terms for the code in this
package".

The combination makes it possible to recurse the filesystem,
find all conformant software packages, inventory their
terms---10 MIT packages, 3 BSD-2-Clause, 1 AGPL-3.0,
etc.---and run those inventories against rules.

We can also use software to make those rules.  So I can say
"approve it if OSI has", and download a list of SPDX
identifiers for OSI-approved licenses.  If OSI approves a
new license next week, and it shows up in my codebase two
weeks later, it gets approved.

There is still at least one lawyer, somewhere, doing the
analysis.  But once they perform the analysis for a given
license, we can detect that the same license applies to
different software, and apply conclusions about its
suitability in a given user context.  How well this works
depends on the packaging system, the language environment,
and other details.  Sometimes it works really, really well.

Some companies apply natural language processing and other
techniques to try to recognize which standard license terms
a LICENSE file contains, or to make conclusions about
arbitrary license terms.  I have nothing to say about them
yet.  Or nothing good, rather.

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