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

[Kyle Mitchell]

Josh,

Thanks for following up.  My mail client must have marked your message of 9/22 read before I actually had a chance to read it.  Apologies!

> - People who want to use some or all of the code from the project in a
> larger work;
> - people who want to cherry-pick specific files or libraries from the code;

The analysis here is much the same as for BSD-2-Clause, whence L0-R comes.

L0-R retains BSD-2-Clause's preamble, granting permission for "redistribution and use in source and binary forms, with or without modification".  Conditions 1 and 2 apply to "redistributions".  The only changes to the original BSD extend the requirement to preserve copyright notice and terms to a new source availability notice.  Condition 3 applies to "uses", the other verb in the general grant of permission.

I think by "larger work" you mean another program with more than just code borrowed from a single L0-R-licensed codebase.

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.

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

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.

Just as it is possible to fork a dual-licensed GPL or AGPL project today, it will be possible to fork a dual-licensed L0-R-licensed project.  The community may or may not choose to continue using L0-R for its own contributions.  It may instead publish its modifications under BSD-2-Clause, for example.  The combination would then be L0-R for the "base", and BSD-2-Clause for copyrightable work "on top".  If the source is published, L0-R condition 3 for the base is satisfied.  The whole source of the program is "publicly licensed under licenses approved by the Open Source Initiative", namely BSD-2-Clause and (prospectively) L0-R.

Does this address what you meant by "organizations", "community", and "privilege"?

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

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.

As for downstream _contributors_, they have similar autonomy with respect to the license terms they apply to their own contributions.  Compared to BSD-2-Clause, that autonomy is modulated somewhat by condition 3, the copyleft condition, which requires OSI-approved terms.  The addition of that copyleft requirement is the better part of the difference between BSD-2-Clause and L0-R.  Much as 1(c) makes the better part of the difference between ALF-3.0 (permissive) and OSL-3.0 (copyleft).

How does the L0-R extension play out in practice?  Again assuming OSI approval of some version of L0-R, say that I release a library under L0-R.  You fork it later, add improvements, and license your work, on top of mine, on L0-R terms of your own.  You list yourself as a copyright holder, the repository for your modified version, your alternative licensing information, your grace and waiver periods.  Per the conditions of my license, you also retain my notices and terms in code and binaries.  Assuming you actually publish the source for your modifications, the whole---my code and yours---would meet the requirement of condition 3.  Users would receive a L0-R license from you, and a L0-R license from me.  Together, those licenses would cover at least all copyright interests in the code.

> We have rejected other license applications for the same reason, and
> even the ones not rejected are still in decision limbo.  You might want
> to take a second stab at that.

Might you be able to name a few of those licenses, so I can read up?  That would be much appreciated.

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.

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.

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