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

[Nigel T]

On Mon, Sep 25, 2017 at 7:20 PM, Kyle Mitchell <kyle at kemitchell.com> wrote:

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

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.


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


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


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

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

I'd rather the OSI "beware" when approving licenses then users needing to
be wary when using open source 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.

In any case, would a user, who isn't a lawyer, prefer to argue this in
court or simply pay the very reasonable $50 for a license and move on?


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

Users don't typically redistribute.  If they do not then the attribition
requirements of MIT don't apply.


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


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

Under GPL, AGPL, etc I don't trigger copyleft on "development" but
distribution.


> 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


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

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


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


> > 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.  At what time can I stop publishing the code?

This is a very simple question that you should be able to answer.

This is relevant because software repos have disappeared in the past.


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


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

When do I trigger #3 as a developer.  This should be in your FAQ.

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.


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


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

And I am laying the definition of "development" at the feet of the license
author seeking OSI approval.

This is not an unreasonable request and I am not asking for "perfect
clarity".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20170925/2d3cc877/attachment.html>