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

[Kyle Mitchell]

On 2017-09-25 23:09, Nigel T wrote:
> On Mon, Sep 25, 2017 at 7:20 PM, Kyle Mitchell <kyle at kemitchell.com> wrote:
> > > 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.
> >
>
> It is a L0-R specific problem if you cannot show another OSI approved
> license that would allow this scenario to occur.
>
> You cannot because no other OSI approved license triggers on use.

I don't think the L0-R licensor has much of any chance suing for infringement in the scenario you outline.  Even if L0-R were just BSD-2-Clause, the source notice, and the copyleft condition, without any grace period or automatic waiver.

Moreover, the hypo unduly focuses on one element of a larger set of bad behaviors about which Open Source licenses can do, and largely attempt to do, nothing.  Open Source without source is inherently problematic---and not Open Source, under criterion 2---under any license, even an OSI-approved one.  Ne'er-do-wells slap Open Source licenses on code they haven't any right to license, and push them into distribution, all the time.  Patent-infringing code gets published under inviting Open Source terms intentionally chosen for unclear patent scope.  And so on.

These are serious challenges.  But licenses aren't the tools for them.

> > 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.
>
> Users don't make AGPL code available over the network.  Developers do. They
> use AGPL code over a network.
> They don't modify code.  They use code that developers may have modified.
>
> Triggering on use opens a host of issues for users.  This doesn't happen in
> AGPL so no, you can't pull the same stunt.

I mentioned AGPL because it smudges the line between "use" and "distribution".  Which is providing software for remote interaction over a network?

Use versus distribution was never a sharp legal line to begin with.  "Use" is a term of art in patent, not in copyright.  Neither US law speaks of "distribution" among exclusive rights.  The distinction is less and less a practical one, too.

Wherever the line was or seemed to be, L0-R intentionally crosses it, by hooking into BSD-2-Clause, which uses the old vocabulary.  The question is whether a copyleft BSD variant _has_ to tap "redistribution" rather tan use, even if those terms aren't so rigorous, and if so, where that line is drawn in the Open Source Definition.  I can't find it.  The mechanism is neither discriminatory in the ways prohibited, nor does it affect licensing of other software packaged with.

We disagree on the basic distinction you draw between users and developers.  We may not resolve that disagreement, and we may not need to.  I think I know where you're coming from.  To give you a sense of where I'm coming from: I couldn't help noticing, browsing through lists of AGPL projects on Wikipedia, how many are either databases (MongoDB, Neo4j extensions) or network applications (Diaspora, Gitorious).  Software very often run with, or for, others.

> > > 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.
>
> Users have not redistributed.  They are just using.  However, they still
> have to insure that the source is published somewhere to be in compliance
> because L0-R triggers on use, not redistribution.
>
> They may not ever get source code in order to publish even if the repo
> exists at the location provided because there's nothing in the license that
> requires that access to the public repo be free,  I can meet the terms of
> L0-R by sticking the repo behind a $100,000 paywall that is publicly
> accessible to anyone willing to pay.  Or sticking it on a public facing
> server in North Korea.  Good luck getting source then.

Open Source has never required free-as-in-beer distribution.  Early license drafters expected payment for copies of source, and media and shipping weren't cheap.

For distribution-based copyleft licensees, there were all the same questions.  Do I have the source I need to distribute with my own changes?  Did I really get all the source from the last guy?

Sure, hooking copyleft into use requires users to concern themselves with source, as hooking copyleft into distribution required distributors to concern themselves with source.  What principle makes the former unacceptable, and the latter permissible?  If it's merely a matter of extent, that concern for use-based copyleft licensees is greater, why?  And is that a structural limit on how strong Open Source copyleft can be?

I'd be surprised to ever find myself arguing that strong copyleft of any kind is convenient.  But I will readily argue that, on balance, strong copyleft and its inconveniences can forcefully promote Open Source values.  More forcefully than utterly convenient, wholly permissive licenses.  Is a license that encourages fretting about whether OSD criterion 2 has been met, outside the four corners of the license terms, bad for Open Source?

As for North Korea, again, the law is not so willing to raid pocketbooks on behalf of transparent tricksters.  Nor is L0-R itself.  I doubt FTP in Pyongyang counts as "publication" in court, except perhaps in Pyongyang.

> >   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.
> >
>
> If users have to be this proactive on OSI licensed code then the value of
> OSI approval for licenses for users approaches zero.

OSI approval goes only to license terms.  No OSI-approved license guarantees that source is in fact available, that those purporting to license have the right to do so (Larry Rosen's licenses have a warranty, but that provides only a remedy), that licensing contributors hold all relevant patents, that use of the software is legal, and so on.

> Users under other OSI approved licenses do not need to worry about copyleft
> because no other copyleft license triggers on use.

"Users" of multi-account network software under AGPL do have to worry.  If they do anything that counts as modification, and can't provide Corresponding Source, they're in technical violation.  Anything requiring copyright permission.  Customizing a blog platform.  Installing the wrong plug-in.

> I'd rather the OSI "beware" when approving licenses then users needing to
> be wary when using open source software.

I don't mean to harp on, but what's the limiting principle?  Why shouldn't OSI "beware" when approving licenses so _distributors_ needn't be wary when using copyleft software?

> > 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".
>
> It isn't impossible to satisfy.  They can just buy a license.  That's in
> the L0-R license terms and the objective of the author of the L0-R code.

I quoted "impossibility" in the legal sense, as an excuse for performance of a duty.  A legal escape from the copyleft condition's requirement.  Not literal impossibility.

Suffice it to say I don't think courts would require licensees to agree to entirely new terms as you describe.  New terms are not access to source, which is what the condition requires.  The fundamental legal principle, generalizing very broadly, is that intentionally making it impractical for someone to hold up their part of a deal with you doesn't put them at your mercy.  It lets them off the hook.

> > 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.
> >
>
> The reassurance is that there is some agency willing to sell "them" a quite
> "reasonable" license to use...

Incorrect, and a red herring.

Nothing about an agency appears in my most recent revision of the text, or needs to.  To my knowledge, nothing about any OSI-approved copyleft license precludes dual licensing, directly or through an agent.

Neither copyleft enforced for compliance, nor copyleft as the basis of a dual licensing business, offends the Open Source Definition, or would rank with the odious schemes you've offered as hypotheticals, if they were viable.

> > I don't see a legal basis for demanding audits.
>
> Fishing expeditions via pre-trial discovery don't get far, or make money.
>
> https://www.cio.com/article/2389840/it-organization/how-it-departments-can-prepare-for-a-software-license-audit.html

I skimmed this briefly.  Enough to get a sense, I think.

Audit rights are a common feature of contracts for proprietary software.  Microsoft.  Adobe.  That kind of deal.  I'm not aware of any public license for software that tries to secure an audit right, via a condition.  L0-R certainly doesn't try.

Suing for infringement in the US can get you "discovery", which works a bit like an audit, but far, far less efficiently.  When I see licensors go that route, they have pretty good evidence on hand of license violations, going in.  The point is to settle, not to actually drag through "disco".

> > 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.
>
> How does the grace period mitigate anything? If I start "developing"
> software based on L0-R but quit development within the grace period do I no
> longer have the requirement to publish?  If not why not?
>
> If I never produce any shippable result why should I need to publish?  The
> license never says I don't have to publish if I stop development.  Only
> that I have a grace period from the start of development before I must
> either publish or seek a commercial license.
>
> Where does it say I no longer have these responsibilities to publish source
> if I stop development?

The preamble ("Redistribution and use...") grants blanket permission, BSD style.  The conditions peel some of that permission back.  Condition 3, indented for structure:

  Uses
    in the execution or development
      of any computer program,
        the entire source code of which
          is not published and publicly licensed
          under licenses approved by the Open Source Initiative,
  must be limited
  to a period
  of <Grace Period> consecutive calendar days.

I would appreciate feedback from all on this language.  But even as currently written, if development of a computer program that is not published, or not licensed Open Source, starts and stops within the given number of days, the condition is satisfied.  That's the only condition on use in the license.

Note: L0-R only mentions alternative licenses for purpose of the automatic waiver.  The part of the license that writes the condition above out of the terms.

> > > 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.
> >
>
> No.  AGPL does not trigger on use or on development.  These two cases are a
> direct result of triggering on use or development rather than distribution.

You're right that use-based copyleft is new, but the examples you give either specialize a broader class of problems that afflict all licenses, or pose no credible threat, for practical or legal reasons that don't depend on how copyleft is triggered.

> > 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.
>
> The license doesn't offer anything in its text to hinder excessively
> aggressive compliance penalties despite your being aware that the motives
> of some developers are questionable and they have misused (or attempted to
> misuse) AGPL in the past.
>
> Why not?

I don't believe the Definition takes any position on what licensors should and should not do when their OSI-approved conditions aren't met.  Neither does GPL-2.0.  Neither does L0-R.

FSF and SFC published a guide to community-oriented enforcement, and the OSI published an approving release.  Both struck a balance between prioritizing compliance, on the one hand, and shoring up the incentives copyleft uses to promote community values, by use of the legal system and its remedies when necessary, on the other.  Copyleft is designed to promote community values, employing the power vested in IP owners under the law to do so.  If that kind of community self-defense is Open Source on paper, then it is Open Source in practice, in a courtroom if need be.  Though it almost never comes to that.

If you want my personal view, you can largely find it in the Principles.  I acknowledge recent controversy around GPL enforcement, but don't jump to question anyone enforcing their terms as excessive or aggressive.  We are learning; the Principles are just two years old.  And there's a very contextual, conscience-based, moral dimension to decisions about noncompliance.  There very well may be collective action problems that call for hard, prescriptive action, from FSF and perhaps one day OSI.  I don't think we're there yet.

> > > 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.
> >
>
> I have triggered #3 by developing code based on L0-R.  I must now publish
> the code.

For completeness: or cease executing or developing it, or cease using the L0-R code in doing so.

> At what time can I stop publishing the code?

When you stop executing and developing the program.

> > > 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?
> >
>
> I am not asking an abstract question.  I am asking you as the license
> author what "develop" means to you for the purposes of evaluating a license
> submission.
>
> This should be a very simple question to answer and instead I get evasion.

The overarching question is whether L0-R meets the Open Source Definition.  I generalized to make the point that all copyleft licenses have a definitional problem in drafting their trigger provisions.  That isn't new.

> > 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.
> >
>
> I thought your objective was to reduce the uncertainties?

The rationale behind L0-R was to implement a stronger variant of copyleft, to enhance dual licensing opportunity, while reducing license pondering on the _community_ side. That is, among those working under the public license.  Sometimes communities waste time on licensing questions because there's no clear answer in the license.  But often they waste time when there _is_ a clear enough answer, but nobody around can decipher it with confidence.

I'm a big fan of existing copyleft licenses, especially the GPL-3.0 and MPL-2.0.  Partly because licensing is what I do, and I'm equipped to handle them.  But those classics are long, structurally complex, and substantively expansive.  In dual licensing ecosystems around them, the parties best equipped to grapple with that material, the ones with lawyers and dollars to buy tools and compliance pros, are usually the ones happily buying their way onto other terms.  The folks without lawyers end up grappling with terms that are neither as terse, tight, or empowering as an old academic license, nor as rigorous as an enterprise contract.  God bless FSF and Mozilla for what they do, in guides and commentary.

L0-R moves the needle on copyleft, but it also moves the needle on accessibility, which runs with the inverse of license length.  The law gives drafters the ability to incorporate usage of trade.  I could probably do more precision than "execute" and "develop" from trade in legal language, and double the length of the license.  But most coders wouldn't grasp 100% of the result.  Using their language gets us maybe 75% there, but much closer to 100% comprehension, and keeps the license short.

> > 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.
> >
>
> No, the intended structural escape is a commercial license NOT permissive
> relicensing.  Permissive relicensing may never happen until the copyright
> itself expires and the grace period only delays when you must publish
> source, not that you don't need to.

Nigel, brother, it's hard to read retorts about my own intent with a level head.

> > In short, "What does 'development' mean here?" is actually a question to
> > you and other software people
>
> No. The question is to the license author.  If you can't explain when your
> license requirements are intended to trigger then it's not a license that
> should ever be approved by the OSI.

I've explained my choice as drafter: reliance on usage of trade.  If the license is applied or litigated, it will be interpreted as written, as the court believes the licensor intended it and the licensee should have understood it, and not by interviewing me or combing through my drafting notes.  If those concepts seem strange or contrived, please feel free to sound out other lawyers on the list.

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