<div dir="ltr">On Mon, Sep 25, 2017 at 7:20 PM, Kyle Mitchell <span dir="ltr"><<a href="mailto:kyle@kemitchell.com" target="_blank">kyle@kemitchell.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Nigel,<br>
<br>
Thanks again. Lots of thinking here.<br>
<span class="gmail-"><br>
> 1) It is my impression that a developer could release their L0-R software<br>
> in binary form to users under the OSI Open Source banner without the<br>
> current source during the grace period. As the original authors they can<br>
> define this grace period to be any arbitrary period. Users see that the<br>
> project is under an OSI approved license so it must be safe to use and<br>
> begin using it. That the source in the repo is for a prior version doesn't<br>
> register.<br>
<br>
</span>This problem is not peculiar to L0-R. Or, rather, it's not a license problem.<br></blockquote><div><br></div><div>It is a L0-R specific problem if you cannot show another OSI approved license that would allow this scenario to occur.</div><div><br></div><div>You cannot because no other OSI approved license triggers on use.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
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.</blockquote><div> <br></div><div>Users don't make AGPL code available over the network. Developers do. They use AGPL code over a network. </div><div>They don't modify code. They use code that developers may have modified.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> After the grace period ends the developer's agent begins demanding payment<br>
> for the current version under a commercial license if the users cannot<br>
> comply by publishing the source. Oh and the grace period ended six months<br>
> ago. No one can comply because the developer has never released the source<br>
> for the current version. They never needed to release the source since they<br>
> aren't governed by the terms of the license. Regardless, by using the<br>
> product after the grace period ended the users must have intended to buy a<br>
> commercial license is their argument.<br>
<br>
</span>There are two mitigations here.<br>
<br>
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.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> 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.<br></blockquote><div><br></div><div>If users have to be this proactive on OSI licensed code then the value of OSI approval for licenses for users approaches zero. </div><div><br></div><div>Users under other OSI approved licenses do not need to worry about copyleft because no other copyleft license triggers on use.</div><div><br></div><div>I'd rather the OSI "beware" when approving licenses then users needing to be wary when using open source software.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
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". </blockquote><div><br></div><div>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.</div><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> (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?<br></blockquote><div><br></div><div>Users don't typically redistribute. If they do not then the attribition requirements of MIT don't apply.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
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.<br></blockquote><div><br></div><div>The reassurance is that there is some agency willing to sell "them" a quite "reasonable" license to use...<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> 2) Developer releases code under the OSI approved L0-R license. It sounds<br>
> useful (and safe) so other developers download the code to just to try<br>
> out. A year later the developer's agent sends a letter to everyone that<br>
> has downloaded the code to demand a software audit to ensure<br>
> compliance...or just buy a license for some fee that is less than the cost<br>
> and hassle for doing an audit. If the downstream developer ever combined<br>
> the L0-R code with any proprietary code of value then it's an extra bonus<br>
> payday. They can't just dump the test projects onto GitHub.<br>
<br>
</span>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.<br></blockquote><div><br></div><div>Under GPL, AGPL, etc I don't trigger copyleft on "development" but distribution.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
I don't see a legal basis for demanding audits. </blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Fishing expeditions via pre-trial discovery don't get far, or make money. </blockquote><div><br></div><div><a href="https://www.cio.com/article/2389840/it-organization/how-it-departments-can-prepare-for-a-software-license-audit.html">https://www.cio.com/article/2389840/it-organization/how-it-departments-can-prepare-for-a-software-license-audit.html</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
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. </blockquote><div><br></div><div>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? </div><div><br></div><div>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.</div><div><br></div><div>Where does it say I no longer have these responsibilities to publish source if I stop development? </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> AFAIK (IANAL) an AGPL release can't do either of these things but it can<br>
> meet the legitimate needs of open source developers that wish to dual<br>
> license.<br>
<br>
</span>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.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
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. </blockquote><div><br></div><div>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. </div><div><br></div><div>Why not?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> Other questions include things like how long do I have to continue to<br>
> publish as a developer? At what point does L0-R consider that my<br>
> development ended and I no longer have a requirement to publish? There are<br>
> FOSS projects that no longer exist that used to be on Java.net. Can the<br>
> upstream developers now force users to purchase a commercial license<br>
> because the downstream project site went poof?<br>
<br>
</span>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.<br></blockquote><div><br></div><div>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?</div><div><br></div><div>This is a very simple question that you should be able to answer. </div><div><br></div><div>This is relevant because software repos have disappeared in the past. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> What is "development" anyway? Can I even look at the code in a code editor<br>
> without triggering section 3? That's usually my first step even before<br>
> reading the docs. Or does "development" happen the first time I compile<br>
> the code?<br>
<br>
</span>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?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>This should be a very simple question to answer and instead I get evasion.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
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.<br></blockquote><div><br></div><div>I thought your objective was to reduce the uncertainties?</div><div><br></div><div>When do I trigger #3 as a developer. This should be in your FAQ. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
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.<br></blockquote><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
In short, "What does 'development' mean here?" is actually a question to you and other software people</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">. 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.<br></blockquote><div><br></div><div>And I am laying the definition of "development" at the feet of the license author seeking OSI approval. </div><div><br></div><div>This is not an unreasonable request and I am not asking for "perfect clarity".</div><div><br></div><div><br></div><div><br></div></div></div></div>