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

[Kyle Mitchell]

Nigel,

Thanks again.  Lots of thinking here.

> 1) It is my impression that a developer could release their L0-R software
> in binary form to users under the OSI Open Source banner without the
> current source during the grace period.  As the original authors they can
> define this grace period to be any arbitrary period.  Users see that the
> project is under an OSI approved license so it must be safe to use and
> begin using it.  That the source in the repo is for a prior version doesn't
> register.

This problem is not peculiar to L0-R.  Or, rather, it's not a license problem.

OSD is a list of criteria for license terms.  Criterion 2 starts, "The program must include source code...".  That's an outlier in the Definition, because including source code is not something we want license terms to do.  Source code includes the license terms!

When it comes to the terms, Open Source licenses actually go in exactly the other direction.  The vast majority of them disclaim any warranty whatsoever.  That means no guarantee from any licensor that they actually "include source".

So I could pull the same stunt under AGPL.  Compile a shared library, slap AGPL terms on it, and send it off for distribution.  Pounce on the first unsuspecting user I can find who's making it available over a network and has arguably "modified" in some way.  Perhaps a peephole optimizer.  Anything.

> After the grace period ends the developer's agent begins demanding payment
> for the current version under a commercial license if the users cannot
> comply by publishing the source.  Oh and the grace period ended six months
> ago.  No one can comply because the developer has never released the source
> for the current version. They never needed to release the source since they
> aren't governed by the terms of the license. Regardless, by using the
> product after the grace period ended the users must have intended to buy a
> commercial license is their argument.

There are two mitigations here.

The first is in the license itself.  Source availability in the condition motivated source availability in the notice, and revising the obligation to preserve that notice on redistribution.  If you worry about providing source, check the source notice.  If you're concerned about binaries with non-public patches, compile it yourself.  If you can't find source, beware, whatever copyleft license applies.

The second is a legal one.  If you can't satisfy a condition because the other side has made it impossible, you've an argument for "impossibility" as well as "waiver".  (I'm an American lawyer.  Vocabulary and mechanics in other jurisdictions vary.)  You may also have a retort in tort law, sounding in fraud concepts.  Analogous, but not directly on point:  If I release code under the MIT License, but delete the copyright notice, can I see redistributors?  Why not?

Long story short, the law is not such a mantrap.  It has endured a great deal of skulduggery over the years, and developed some tools to deal with its most naked manifestations.  But again, L0-R licensees needn't rely on that.  They license template gives them means of reassurance and self-help.

> 2) Developer releases code under the OSI approved L0-R license.  It sounds
> useful (and safe) so other developers download the code to just to try
> out.  A year later the developer's agent sends a letter to everyone that
> has downloaded the code to demand a software audit to ensure
> compliance...or just buy a license for some fee that is less than the cost
> and hassle for doing an audit.  If the downstream developer ever combined
> the L0-R code with any proprietary code of value then it's an extra bonus
> payday.  They can't just dump the test projects onto GitHub.

This doesn't seem plausible, and to the slim extent it might be, I don't see how it's any better under L0-R, GPL, AGPL, or, frankly, a permissive license with a neglected attribution requirement.

I don't see a legal basis for demanding audits.  Fishing expeditions via pre-trial discovery don't get far, or make money.  Prenda Law has earned a (dishonorable) place legal folklore for attempting this kind of thing, and very unsuccessfully.  What they _claimed_, all of it dubious, wasn't any license condition.  It was no license at all.  Relatively strong.

It's not clear why the agent---if there will be an agent---necessarily has authority to sue others on the developer's behalf.  Or where it would get good information on who has used in excess of permission granted, but has not paid.  We see the same information problem with attribution-requiring libraries in web apps, in binary distributions.

Back to L0-R, I would be willing to argue that L0-R without the grace period would still be an Open Source license.  But again, the grace period mitigates somewhat the strength of the copyleft implementation.

> AFAIK (IANAL) an AGPL release can't do either of these things but it can
> meet the legitimate needs of open source developers that wish to dual
> license.

I think we don't see that kind of volume operation with AGPL for the reasons outlined above, which have little to do with AGPL itself, or how AGPL differs from L0-R, and would apply to L0-R also.

We have _certainly_ seen controversy about the motives and objectives of people enforcing copyleft conditions under FSF licenses.  Hence the recent "Principles of Community-Oriented GPL Enforcement".  (A)GPL-3.0 ensconces enforcement-for-compliance in retroactive forgiveness terms, right in license text.  L0-R licensors would have a choice on noncompliance.  Some might seek code.  Some might seek coin.  Some might seek both.

> Other questions include things like how long do I have to continue to
> publish as a developer?  At what point does L0-R consider that my
> development ended and I no longer have a requirement to publish?  There are
> FOSS projects that no longer exist that used to be on Java.net.  Can the
> upstream developers now force users to purchase a commercial license
> because the downstream project site went poof?

I'm sorry.  I don't follow.  The permissions granted under L0-R never go poof.  If they go anything, by neglect, they go permissive, by automatic waiver of the copyleft condition.

> What is "development" anyway?  Can I even look at the code in a code editor
> without triggering section 3?  That's usually my first step even before
> reading the docs.  Or does "development" happen the first time I compile
> the code?

All copyleft licenses face a challenge in defining the "trigger" for source and licensing requirements.  What is "interaction ... through a computer network" under (A)GPL?  What is "executing it on a computer"?  What is "distribution" under MPL-2.0?

Legal drafters have some tools and techniques to chip away at those challenges.  One of those tools is throwing in the towel and using terms from industry, as understood in industry.  An early draft of L0-R intentionally chose general terms _without_ any established meaning in software or law for the trigger.  The draft I proposed borrows "execute" and "develop" from software parlance, intentionally.  If the point is to write a license that software people can understand, the most best path to relative clarity is software-speak.

Legal drafters also learn to accept that perfect clarity is impossible, and that managing uncertainty is as important as reducing it.  Who should should bear irreducible uncertainty in L0-R's copyleft trigger?  The purpose of the license is to implement a very strong version of copyleft, in terse form, with structural escape valves in the form of a grace period and either alternative licenses or automatic, permissive relicensing.

In short, "What does 'development' mean here?" is actually a question to you and other software people.  What does "development" mean when you use it?  If "development" is ambiguous, L0-R lays that ambiguity at the feet of those angling to get by without sharing code, licensing Open Source, or supporting the developers.

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