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

[Kyle Mitchell]

On 2017-10-23 16:10, Bruce Perens wrote:
> On Mon, Oct 23, 2017 at 1:27 PM, Kyle Mitchell <kyle at kemitchell.com> wrote:
>
> >
> > 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
> >
>
> Which is unsettling because it allows them to get rid of the nasty freedom
> part. There has been an effort to recast Open Source as the "open source
> development paradigm". Which doesn't really exist. There is an open
> development paradigm and there is Open Source, and one is not the other nor
> is one necessary for the other. If OSI is being seduced into that idea,
> it's a mistake.

What these folks do or don't think about "freedom" as it
relates to Open Source they themselves should say.

I appear here only in my capacity as messenger.  I'm aware I
might still get shot, but hey, that's the gig.

> > 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.
> >
>
> Au contraire. OSI exists to draw a line in the sand, clearly define it,
> promote that you should do things that way and make it clear what is, and
> what is not that way, and nurture the development community that works in
> the specific way we stand for. Lots of people do great work and we can
> appreciate it, but it's not OSI's job to be inclusive of it.

Let there be a line. And if a line there is, may it be a
sharp one.

I mention these folks and their views, and plead to have
them considered, because the matter of what comes to mind
when people see and say "open source" isn't a contest of
rigor, or first claim, or internal consistency.  Numbers are
relevant.  So is audience.  So is a certain prestige amongst
developer-kind.

If OSI succeeds in holding up to all its most rigorous,
self-imposed standards, but fewer and fewer developers care,
either because they dismiss OSI's claim to define to "open
source", or because they hitch their identities to some new
turn of phrase, I think the community as a will have
suffered a very great loss.

> > 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.
> >
>
> Many years ago a "summit" of Open Source using companies was held in which
> they issued their consensus statement that the developer community should
> only use permissive licenses. A fellow named Christopher Blizzard responded
> to this with an essay entitled "Every little girl wants a pony". I no
> longer have a copy - can anyone find it and the statement that elicited it?

I would be very, very grateful for links to, or copies of,
these documents!

> The mission of Open Source developers is not to be a vast pool of creators
> providing corporate welfare for the world's richest companies, functioning
> as their unpaid employees. We have not set out to facilitate the
> development of proprietary software with our work, but to create more Open
> Source. To the extent that the proprietary world participates, they do so
> under our rules, not the other way around. Or they call it something other
> than "Open Source".
>
> Thus, it is within the purview of OSI to recognize that every little girl
> wants a pony, and to say "no" when appropriate in the interest of the
> developers.

This rings very near to the sentiment that set off License
Zero.  The immediate moral response to industry abuse of
community was a license addressing the _source_ of the pain,
a noncommercial license.

It was only talking to friends and fellow devs still holding
on in the copyleft camp that lead me to write L0-R.  The
core realization there was that commerce was just the most
visible symptom of the underlying disorder.  The fundamental
difference is in values, in a lack of reciprocity that makes
a one-way valve between producer-community to
consumer-users, to the benefit of the latter.

So I asked devs what kind of deal they'd want with users, if
they could write their own.  It boiled down to "share what
you do with my code as open source, or support me if you're
stuck in a place that can't or won't do that" plus "I want
to keep working on GitHub, distributing on npm, and using
the other current-generation code services".

That's a harder copyleft bargain than AGPL, mashed up with
permissive distribution permissions.  L0-R was born.

> > The number one requested feature is setting _negative_ rules instead. Rules
> > like "no GPL", or "anything but copyleft".
> >
>
> I suspect this request is coming from parties that can afford Palamida or
> Black Duck but are unwilling to go to the expense. The corporations need to
> have a compliance effort. OSI did not set out to absolve them of that
> responsibility.

LF has, to the extent of SPDX, OpenChain, and I'm sure other
work I'm now forgetting.  I expect their view is that if
it's going to get done with software, the software should
ideally be Open Source.

> > http://lillicense.org/
>
> The less-informed approach legal language with the firm belief that they
> could improve upon it if only they were allowed to state it simply. But
> this "cry in the dark" ends up duplicating the Apache license in its
> effect, and the Apache license is brief, well-understood and not baffling
> in its legal language. OSI's major responsibility in regard to this sort of
> effort is to explain why it ultimately harms the developer community.

Jeremy Ashkenas, the hand behind Lil License, explained to
me that he was motivated mostly to make this clarification:

  The authors have no obligation to provide support or
  updates for the software, and may not be held liable for
  any damages, claims or other liability arising from its
  use.

IIRC, the rest is a rehash of MIT.

The picture is of a prolific permissive-license software
developer getting fed up enough to write a license, even
though he knew he shouldn't do so himself, just to speak and
perhaps dull the pain pain of having hordes or end-user
developers fail to understand a simple implication of The
MIT License.  Brokenness on many levels.

> > I wouldn't underestimate how alienating and frustrating is legal English to
> > minds not yet ruined for it.
>
> As you can see from the wording, when I wrote the OSD I was a systems
> programmer at Pixar who worked on Linux for a hobby. I had little
> understanding of how to properly phrase it, or it might have been written
> as a list of permissions rather than a list of prohibitions. Any
> development of legal knowledge that followed that was out of necessity.
>
> OSI (and FSF before it) did not create the framework of intellectual
> property law, indeed we are more prisoners of it than anything else. The
> alienation and frustration arises from the fact that the system was not
> built to accommodate us, but to thwart us. It literally exists to make
> copying a tort.
>
> It is the unfortunate truth that the words of the license are only a
> portion of what needs to be parsed. There is the context of law and case
> law. Thus, we arrive at things like an exhaustion doctrine that applies to
> the BSD license in regard to patents, but is completely unstated within the
> license.
>
> Unfortunately if a developer believes they understand a plain-language
> license, they are probably understanding less than half of it due to the
> lack of context. We can warn them, or we can train them. We might harm them
> by doing neither.

For what it's worth, a key part of what I do when I write a
plain-language contract, best case, is test it on non-lawyer
readers.  Then:

1. write in key background rules not apparent from the text

2. put terms with specific legal meanings in quotes, and
   either call them out as legal terms, or defined them if I
   think I can

I'm a full-time transactional attorney.  My experience has
_not_ been that educated speakers of English can never
understand legal documents at a practical level.  It has
been that writing transactional documents that educated
speakers of English can understand requires a great deal of
the attorneys drafting.  More than they're accustomed to.
Also that the effort pays off, magnificently, in myriad,
unexpected ways.

My two cents.

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