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

[Kyle Mitchell]

> > 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.

I'm not quite sure I follow.  I think I'm stumbling on "inheritable".

The model is "direct licensing".  Everyone who comes upon a copy of L0-R code, or BSD-2-Clause code, receives the same permission, subject to the same conditions, under the public license.  The conditions apply to everyone receiving permission.  Rights don't pass through distributors or developers of modifications or incorporating works.  They aren't "sublicensors".  Rather, they reproduce notices that communicate the existence of the public license, its terms, and the notices required to satisfy its condition.  They can't concoct notices that communicate different information about permissions with legal effect.

There are edge cases where folks "downstream" in the sense of receiving from someone other than the copyright holders end up with code, but not notice, conditions, or disclaimer.  Redistribution without that information by anyone is outside the permission granted by the public license.  So everyone ends up with the same license, but not everyone always ends up with all the information they need to comply with that license's conditions.

> >> - 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?

In what sense does L0-R "embed" dual licensing, and which criterion of the Open Source Definition prohibits that?  To the extent L0-R merely acknowledges what was read into, or true in practice about, prior Open Source licenses, does that difference in content, but not meaning, take it out of the OSD?  Running through the Definition again, I don't see any criteria on point.

The obvious answer to my first question is the automatic waiver of condition 3.  The effect of the waiver is to transition the terms from one kind of Open Source license---a copyleft license---to another kind of Open Source license---a permissive license.  That isn't "dual licensing" in the sense of offering two distinct sets of terms concurrently, one Open Source, the other not.  And it isn't "delayed release", as under the Business Source License, from proprietary to Open Source terms.

Rather, it's another option that's already available to licensors under existing, OSI-approved copyleft licenses: relicensing.  It's perfectly possible---if not always practical---to license a bit of code, say, GPL-2.0, and then publicly relicense it later on more permissive terms, say MIT.  GPL-2.0 isn't any less an Open Source license for failing to prevent that.

Would L0-R come under the OSD, in your view, without the automatic waiver?  Without the notice of alternative license availability?  That license would still enable licensors to do, manually, exactly what L0-R as currently does for them, automatically.  They could publish directions to alternative licenses elsewhere, say in doc or header comments, sell alternative licenses for a while, and then, if business dries up, relicense BSD-2-Clause.

> > 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.

I'm now firmly convinced that I should revise the proposed terms to move the agent information out of condition 3, and make it utterly generic.  The revised text will make clear that there needn't be any agent at all.  Red herring.

Both as currently proposed and as imminently revised, only the original licensor can set information about alternative licensing of the original licensor's IP.  Only subsequent contributors can set that information for IP in their contributions.  The original licensor cannot cannot make those choices for any subsequent contributor's IP, or vice-versa, any more than they can unilaterally change copyright notices for others.  L0-R could have been written to allow first licensors to exert control on the mechanics of dual licensing downstream, but very consciously declined to do so.

Alas, the chaos you describe is very common today, with essentially unstructured mixing and matching of source code files, and even syntactic structures within source code files, from diverse sources.  We have all seen concatenation of dozens of copyright notices, followed by The MIT License, and concatenations of multiple, distinct licenses. Even in licenses that purport to constrain license terms of contributions, such as Apache-2.0 and the (A)GPLs.

I won't be seen running any kind of advertisement here, but suffice it to say, I think license management is a technical problem amenable to technical solution, and in any even not a license-terms or OSD problem.  SPDX and interpreted-language package managers have done great work with metadata, if that's of interest.

> >> 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.

As I mention above, I will revise shortly to make the alternative license availability notice more generic.  There's no reason it ought to be specialized, and I'd welcome use of L0-R quite without one.

I realize I may have fallen short of clarity on two points.  Just in case:

Any specific values I have in mind for the placeholders in the license would be choices available to licensors, not values baked into the license as it might be approved or standardized.  I've used placeholders to mark out parts of the text that should and must be changed---necessarily mutable!  Specific licensors should fill them out for specific projects, as they fill out copyright notice placeholders now.

I've meant "agency", in discussion and the text proposed to date, in the sense of an individual or organization that an IP holder appoints to issue alternative licenses on their behalf.  In that sense, their "agents", like "real estate agent", not "Central Intelligence Agency".  A lawyerly usage, perhaps.

> 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?

Under L0-R, the result is that they have all the permission granted under the terms of the L0-R public license.  A BSD variant with a strong copyleft condition.

> * what if the contact information changes?  how do you update licenses in the field?

Licensors might like to update the information, but it isn't necessary, on the licensee side, for them to do so.  Stale information, or an inability to access it, may make it more difficult to assess whether the automatic waiver has triggered.  But the difference that makes is only between copyleft and permissive terms.

> > 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.

Agreed!  Thanks for helping me see as much.  Revision to come shortly.

> > 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.

Excellent.

To my mind, the whole substantive difference boils down to the copyleft condition and the automatic waiver of it.  The rest is adding content to the notice that must be preserved.  As a practical matter, I could put all that kind of information in an Apache-2.0 NOTICE file today, and get the same effect.

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