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

Sat Sep 23 17:18:07 UTC 2017

The issue isn't downstream compliance but that users have downstream compliance to publish source.  

My, perhaps incorrect, belief is that users typically can gain a use license from the upstream open source project even if the downstream developer is out of compliance. 

They can't distribute further because then they would trigger distribution requirements but typically users don't.

So I disagree that the difference between users and developers dissolves for most FOSS use cases.

Arguably this is the same problem as patents rights and the ability to use software but my disagreement with requiring patent clauses is one of scope rather objective.  

I'm for patent grants.  I'm against accidental patent grants of patents created by other inventors.

This license complicates use under FOSS copyright and not patents which most developer don't own anyway.

The other issue is if I ever play with L0-R code privately I'm compelled to publish that test code because I've presumably triggered the copyleft by "developing".  If that code ever touches any proprietary code libraries I might be using normally I'm screwed. I can't comply even if I never release anything.

Nobody but me would know (unless downloads or clones are being tracked) but that's besides the point.  I dislike being compelled to be dishonest even if no one else knows and I'm also not happy to be compelled to litter my github repo with test projects for code I never end up using for anything.

Sent from my iPhone

> On Sep 23, 2017, at 12:09 PM, Kyle Mitchell <kyle at kemitchell.com> wrote:
> 
> Nigel,
> 
> Thanks for your response.
> 
> If you'll forgive me generalizing a bit, I
> think you broached two main topics:
> 
> 1. Triggering source publication requirements
>   on use, rather than distribution of
>   modifications.
> 
> I hope you'll forgive me starting out by
> saying that while this is absolutely the part
> of L0-R most worth discussing, I don't
> believe this choice of trigger affects
> whether L0-R meets the Definition.  I don't
> read any part of OSD to compel any particular
> kind of trigger for copyleft requirements.
> 
> I usually refer to troubles complying with
> license conditions for software that you've
> received from someone else "downstream
> compliance issues".  Alas, downstream issues
> aren't peculiar to L0-R, or even to copyleft
> licenses generally.
> 
> Take a typical attribution requirement under
> a permissive license, like the two-clause BSD
> License.  If A writes software and licenses
> BSD-2-Clause, B makes modifications and gives
> C a copy without A's copyright notice, then C
> might fail to meet the attribution condition
> of A's license if C makes a copy for D
> without A's notice, and end up without a
> license C needs.
> 
> The same can happen with GPL-style copyleft
> conditions.  If A writes software and
> licenses GPL-2.0, B makes modifications and
> gives C a binary copy with access only to B's
> new source, then C's at risk of failing to
> meet the source condition of A's license if C
> distributes with further modifications, and
> only B and C source.  More generally, one
> purpose of GPL-style copyleft, as an
> implementation of Software Freedom, is to
> ensure that any licensee can also be a
> developer.  The distinction between user and
> developer dissolves.
> 
> The only solution to eliminating downstream
> compliance issues I'm aware of is permissive
> licensing utterly without condition, such as
> under The Free Public License / 0BSD or The
> Unlicense.  Under a direct-licensing model,
> where everyone receives permission directly
> from the copyright holders, through the
> public license, any condition gives a license
> teeth that can bite anyone downstream.  L0-R
> has license conditions, and therefore
> potential downstream issues.  But it tries to
> mitigate headache in a couple of ways.
> 
> First, condition 3 requires that source code
> _be_ published, but not that any or every
> specific licensee _do_ the publishing.  If A
> licenses code L0-R, B makes modifications,
> licenses those modifications under an Open
> Source license, and publishes code, users of
> B's modified version don't trip over
> condition 3 by executing or developing with
> A's software.
> 
> Second, L0-R preserves BSD-2-Clause's
> redistribution conditions.  It modifies them
> only to require preservation of notice of a
> source code repository, in addition to the
> copyright notice.  This is meant to help
> ensure that not only license-terms
> information, but also source availability
> information, travels with the software
> wherever it roams.
> 
> 2. Issues related to license changes.
> 
> You pointed out at least two ways in which
> the licensing situation under L0-R can drift
> away from the situation when the license text
> is originally applied to the code.  Both
> involve situations where licensees might have
> to look beyond the particular form of the
> software they've obtained to assess rights.
> 
> First, there's the automatic waiver.  The
> concern that provision tries to address is a
> kind of "orphan code" tragedy, where the
> creators would be willing to make a deal for
> other license terms, or relicense, to permit
> non-Open Source use further down the line,
> but can't be found or bothered. Dual
> licensing stops, and all that's left is a
> very exacting public license.
> 
> The most rigorous way to address that concern
> is simply to tell licensors that they ought
> to relicense their software under permissive
> terms when and if the time comes.  Or to set
> up some facility to offer alternative
> licenses indefinitely.  I have little hope
> for either of those approaches lasting the
> test of time.
> 
> That being the case, we need some kind of
> trigger for, effectively, automatic
> permissive relicensing.  Automatic in the
> sense of requiring no further action by the
> licensor.  One approach would be to set a
> date in the license, but licensors would only
> very rarely guess the right date ahead of
> time.  Assessing whether a licensor has
> _failed_ to take some action, like offer
> alternative licenses, gives licensors more
> control, over time, of waiver. But from the
> licensee point of view, it involves proof of
> a negative.  The language puts the burden of
> that uncertainty where it belongs, on those
> who should seek an alternative license if
> they can get one.
> 
> As for retroactive changes to the agent, and
> other changes to license information for a
> project, over time and over versions, I'm
> afraid those issues aren't peculiar to L0-R,
> either.  Fundamentally, the model of terms in
> public licenses distributed the same way as
> the software creates issues for those who
> want to make changes in what's already been
> distributed far and wide.
> 
> If you license version 1.0 of a project under
> GPL-2.0, and later decide to move to
> GPL-3.0+, you're faced with the problem of
> informing folks with copies of 1.0 that only
> mention GPL-2.0.  If you're using a third
> party distribution service, you probably try
> to alter the artifacts they distribute.  And
> you likely publish a notice on your website
> and in README or similar of later versions of
> your project, mentioning that prior versions
> have been relicensed.  You'd do much the same
> for an L0-R agent change.
> 
> The information dissemination problems here
> are mitigated somewhat by the copyright and
> repository notices.  If you're curious
> whether the licensing agent for a project has
> changed, you may find the information you
> need at the repository.
> 
> 3.  Concerns about the licensing agency.
> 
> I'll put some thought on dropping the current
> language about an agent in favor of a
> requirement to preserve any separate notice
> about where alternative licenses are
> available.  Perhaps:
> 
>    ...
> 
>    Alternative Licenses Available:
>    <Information>
> 
>    ...
> 
>    1. ... must retain all the notices
>       above...
> 
>    2. ... must reproduce all the notices
>       above...
> 
>    3. ... This condition is waived if
>       alternative licenses permitting those
>       uses cease to be available for <Waiver
>       Period> consecutive calendar days.
> 
> The constraint foremost in in mind is
> ensuring that downstream recipients have some
> way to identify where alternative licenses
> can be got if needed, and some evidence to
> authenticate those purporting to offer
> alternative licenses as those actually
> capable of doing so.
> 
> In general, it falls on licensors to maintain
> a dual-licensing practice to avoid the
> automatic waiver.  There is always an issue
> of trust, and verification, when delegating
> important duties to others.  Also opportunity
> and specialization.  The core idea behind
> licensezero.com is a "dual-license vending
> machine" that stands ready to vend
> alternative licenses, 24/7.  To give
> small-scale companies and independent
> developers the machinery they need to run
> dual-licensing businesses.
> 
> 
> As long as there be law, there will be
> pondering.  And lawyers, I'm afraid.  My goal
> with L0-R could not be perfect clarity, but a
> relative clarity, constrained in brevity.  A
> natural tension, there.
> 
> Thanks once more for time and thoughts.
> 
> Best,
> 
> K
> 
> -- 
> 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