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

Nigel T nigel.2048 at gmail.com
Mon Sep 25 21:54:35 UTC 2017


Kyle,

I'm sorry if you object to the word "trap" but you don't just evaluate
licenses from the perspective of everyone playing nice.

Here's a couple of "not nice" scenarios off the top of my head:

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.

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.

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.

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.

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?

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?

Regards,

Nigel


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

> Nigel,
>
> Thanks again.  You make many valid points.  However, those points go to
> whether you think L0-R advisable, or to what business models you think
> developers should and shouldn't attempt, and not to whether L0-R meets the
> Open Source Definition.
>
> I don't understand OSI license review as a process of conferring blanket
> OSI approval on any business model, company, or community, or of
> prescribing any particular approach among many that count as Open Source.
> OSI has approved a number of company-specific licenses; I don't take those
> as endorsements of the entities involved.  And OSI has approved some
> licenses now placed in a "redundant" category; that's clearly no
> promotional boon.
>
> The only help I ask from OSI is the help that it offers---the time
> unavoidably required to apply the Definition to L0-R, approve it as an Open
> Source license, or clarify which Definition criteria it misses and how it
> might be revised to comply.  I'm happy to answer any questions posed during
> the process, and the guide to the process makes clear that I should do so.
> Indeed, there are many good conversations to be had about the issues L0-R
> touches.  But most aren't the business at hand.
>
> On other writing:
>
> Others are welcome to read what I've written publicly on L0-R, L0-NC, and
> License Zero more generally:
>
> https://medium.com/licensezero
>
> Those posts touch on a few points of legal significance and license
> design, in passing, but in the main treat community, business, and,
> frankly, policy questions that I don't understand belong here on
> license-review.  Perhaps on license-discuss.
>
> I've been selective here, and followed the prescribed submission format,
> to respect the time of those involved.  A dump of all my prior writing
> would have had quite the opposite effect, punishing those generous enough
> to read straight through with a great deal that's irrelevant or simply
> out-of-date.  The same effect by sending a list of links, at the additional
> cost of a skeletal mailing list archive record.
>
> On copyright "traps":
>
> I'm afraid I must object to "trap", just as I objected to "coercion".
> "Trap" has been leveled at all strong copyleft licenses.  But license
> conditions as a legal mechanism, by definition, take permission away,
> making grounds for IP suits.  That's as true of attribution, list-changes,
> and other typical permissive-license conditions as it is of more involved
> copyleft conditions.  An anecdote: I'm fond of polling developers at events
> about Apache-2.0 NOTICE files.  Many don't believe when I tell them!
>
> Some conditions are more difficult to apply, in practice, than others.
> But neither relatively easy conditions, nor relatively hard ones, nor great
> heaps of condition language---AGPL is about four times the length of L0-R,
> I believe---apparently disqualify a license as Open Source.  Unless they
> trip over the criteria.
>
> On noncommercial terms:
>
> You're right.  I do want a noncommercial software license.  So I wrote
> one, L0-NC, based in part on CC-BY-NC, just as you mentioned.  That is
> obviously _not_ an Open Source license.  I won't be troubling OSI about it!
>
> With L0-R, I wanted something very different: a stronger-than-strong
> copyleft license,  a more aggressive legal implementation of community
> values that prize publicly available source code and Open Source terms.  In
> other words, Open Source values.  Yes, that want is partly motivated by a
> desire to offer license terms that incentivize some downstream users to pay
> for alternative terms, in financial support of developers who do work in
> the open.  The effect is to make dual licensing a viable model for
> independent developers.  Independent developers who can choose between a
> noncommercial and a reciprocal public license---L0-NC or L0-R---as they
> prefer.
>
> Your view of L0-R as a kind of back-door noncommercial license, and
> therefore not an Open Source license, sits uneasily with your point that
> developers could achieve the same practical effect with AGPL in lieu of
> L0-R.  Neither AGPL nor L0-R discriminates against commerce as a field of
> endeavor, or against commercial entities as groups, under the Definition.
> It is possible to run a business, as an individual or a large company,
> making and using strong-copyleft code.  Dual licensing opportunity springs
> from the fact that many people and groups---not just commercial
> ones---discriminate against Open Source in how they choose to go about
> their business.
>
> Permissive licenses practice Open Source values, but don't hold others
> accountable for them.  Copyleft licenses do.  You're right that AGPL is the
> go-to license choice for dual licensing businesses.  It's strongest,
> common, OSI-approved copyleft license going.  MongoDB has just filed to go
> public.  It won't be the last on that model.
>
> AGPL is an Open Source license.  Which criteria of the Open Source
> Definition does AGPL meet that L0-R does not?
>
> --
> Kyle Mitchell, attorney // Oakland // (510) 712 - 0933
> _______________________________________________
> License-review mailing list
> License-review at opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20170925/e60bf9d0/attachment.html>


More information about the License-review mailing list