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

[Josh berkus]

On 09/25/2017 12:45 PM, Kyle Mitchell wrote:
> Josh,

> If I want to reuse, say, a single function from the source of a BSD-2-Clause project, I read the license to permit me to do so, as long as I preserve notices in distributed source code or documentation with distributed binaries.  The same would be true of a function from an L0-R-licensed project, with the additional requirement that the larger work must be published in source form and licensed under OSI terms if the L0-R code is used in "execution or development" of that program.  If your larger work runs a function copied from my L0-R project, that would be a "use[] in the execution" of your larger work.

However, this right is 100% inheritable.  That is, as a downstream
developer, I have exactly the same rights as the developer from whom I
received the code.

> 
>> - organizations who decide to create OSS communities around modified
>> versions of the code.
>>
>> Clause 3 of the license privileges the "original releasor" of the code
>> over successive OSS redistributors as a part of the license.
> 
> I think I know what you mean, but I'm not entirely sure.  Let me take a stab.
> 
> Fundamentally, there is a difference in all dual-licensed projects between the individual or entity that grants the initial copyleft license, and retains the right to offer other terms for the original code, and others licensed only under the public terms, who can't give others more permission than they've received.  All condition-bearing licenses, the vast majority of OSI-approved licenses among them, create that kind of difference to some degree.  Moreover, that difference is the basis of dual licensing, clearly possible with OSI-approved public terms.

But dual-licensing isn't part of the OSS license.  Companies
dual-license by virtue of their ownership of the original copyright, not
because the OSS license enables dual-licensing.  Embedding
dual-licensing in the OSS license itself is a radical innovation, and
would need to be debated as to whether it violates the OSD.

You also need to make a case as to why a license which embeds
dual-licensing is needed.  Materially, it's clear that companies can
already dual-license, and several have built lucrative business models
around it.  If MySQL didn't need L0-R, why does anyone else?

> If that's the "privilege" that irks, L0-R's automatic waiver should please.  Perchance the original licensor stops dual licensing---that is, stops using its unique position to offer different terms---L0-R reverts to a permissive license, a slight variation on BSD-2-Clause.  At that point, setting aside the usual permissive-license notice preservation requirements, the original licensor stands more or less in the same position as subsequent contributors publishing on similarly permissive terms.  Everyone will have given nearly all the permission the law stands them in stead to give, to everyone.

Only the "original licensor" can set the agent, which is presumably an
organization with whom that licensor has a business relationship -- one
which a downstream licensor may not share.  Certainly, as a developer, I
am unlikely to grant a firm chosen by you the right to relicense my
freely donated code as they see fit.  Generally, I expect to get paid
for that.

The alternative is chaos, where each page of the code has a different
agent allowed to grant waivers, and any commercial licensing requires a
week on the telephone.  Worse, each page of the code could also have
different time limits.

>> It also leaves unresolved what redistributors are allowed to do in terms of
>> agents, time limits, and other changes.
> 
> All of the template variables, from the copyright notice down, are part of the license, for the licensor to decide.  Downstream distributors cannot change those terms---"relicense" the code---any more than they can relicense AGPL or GPL code.

No other approved license that I know of includes immutable contact
information for a specific agency.  In fact, we've delayed approval of
licenses brought to us by large government agencies over this specific
point.

Any time a license requires specific contact information, it runs up
against these questions:

* what if the licensee lives in a country where they're not allowed to
contact that person/address/website?
* what if the contact information changes?  how do you update licenses
in the field?

> An aside: I was already tempted to move alternative-licensing information out from under condition 3, up with the other notices, for copyright and source availability.  I think I will take a stab at that next, as it helps make clear that passing information around with license terms is typical of open source today.  If there's anything new in L0-R as currently proposed, it's the template variables for the lengths of the grace period and automatic waiver period.  Those affect the legal language in ways that, say, additional information crammed in an Apache-2.0 NOTICE file should not or could not.

Removing all references to the agent from the license would help.

> This raises a major procedural question, which I could boil down to: "Would OSI approve BSD-2-Clause as an Open Source license today?"  There is always a bit of history and practice that develops, applying a test like the Definition over and over again.  Best practices, or at least our perception of them, also evolve, or hopefully do.  But I'd be surprised and dismayed to learn that the goalposts have moved so far.  And I think it would come as quite a shock to the swathes of developers choosing BSD-n-Clause and its cousins, MIT, ISC, etc., for new work every day.

The issues I have with your license are its differences from BSD, not
its similarities.

> Worse comes to worst, I could rewrite L0-R in a more traditionally legal, EPL- or Apache-esque style, addressing each substantive question in its own enumerated section, with descriptive headings, and so on.  I'm a licensing lawyer, and that's my native mode.  But style and brevity matter in our communities.  I think it's vitally important that someone---if not License Zero, someone else---evolve the copyleft concept in a license form that feels tractable to those who can't trust the "enterprise"-looking, American contract-style licenses.

Brevity to the point of incoherency isn't an asset.  You've done a lot
of explaining of what you meant by Clause 3, but as a developer if I
read Clause 3 that's not what I see.  People expect brief licenses to be
easily understood.

--Josh Berkus