[License-review] For Approval: License Zero Reciprocal Public License
Kyle Mitchell
kyle at kemitchell.com
Wed Oct 25 04:46:03 UTC 2017
On 2017-10-24 21:10, Bruce Perens wrote:
> > Licenses can't distribute source, so OSD is speaking to something other
> > than the license here.
> >
>
> Nope. It's specifying that the license must allow (not require) the
> distribution of source code, and then has some terms to prevent gaming.
Please understand that I'm not doubting intent here, yours
or that of others who approved of the text later. But there
are at least two reasons I can see that this language is
hard to read as you propose.
First, the sentences that follow use "must", not "may".
That's language of obligation, not discretion or permission.
Second, a great many approved licenses don't say anything
about reproduction cost or preferred form. BSD-2-Clause,
for example, is silent on them.
> But it's not attempting to be a software license, it wasn't written to be a
> software license, and if asked to testify I'd still say the use makes no
> sense because the subject of the document is not to be a software license
> but to specify the behavior of licenses as a class.
>
> And what you're doing is silly, because it's actually just a few sentences
> of the OSD you need to use to define how source is distributed, and rather
> than use them by reference you could just copy them or make a similar
> statement in your own language.
I'm convinced to use my own language, but neither copying
nor rephrasing come without cost.
As for copying, you pointed out that OSD may change, and
that point is well taken. That means a potential mismatch
between "Open Source" as defined by OSD and "Open Source" as
defined by L0-R.
As for rephrasing, there's no guarantee that I'll refactor
without changing meaning. In fact, there will almost
certainly be edge cases where different words fit the same
facts differently.
The end result is "slippage" between how OSD defines "Open
Source" and what L0-R requires. I guess that's breaks.
> Now, if you want to include the OSD by reference to specify that a
> modification must be under an OSD-compliant license, that makes logical
> sense but I still think it's bad writing, because you don't know what the
> OSD will say tomorrow. It would be much cleaner to specify that
> modifications must be under "this license".
The original L0-R proposal used publication plus licensing
under OSD conformant terms. I backed up to "Open Source
Software" as defined by OSD due to concerns about "publish",
and realization that OSD said a lot about distribution. If
there's reason to acknowledge OSD is incomplete as to source
availability, you're right, I should speak to it myself.
Requiring modifications under "this license" introduces a
far heavier compliance burden. That's been the case for
most copyleft licenses, like GPL 2. This is where the big
license-compatibility problems come from. It's a stated
goal of L0-R to implement a stronger trigger, but weaker
compliance requirements once copyleft is triggered.
The escape from same-license incompatibility problems is a
whitelist of approved licenses for derivatives,
combinations, and so on. (A)GPL-3.0 go toward this, with
mutual reciprocity, under section 13. I'm not entirely up
to date on what EPL-2.0 is doing for GPL compat, but I
understand an analogous approach was on offer there,
essentially yielding copyleft to GPL copyleft where
necessary.
L0-R can't do anything about GPL's exactitude. But it can
leave things more open as far as its own requirements go.
> > I can lock the reference to the OSD "as originally published" by OSI.
> >
>
> The one originally published doesn't include that text. Just the first
> sentence. I'm not clear when the rest appeared, it's not in the Debian Free
> Software Guidelines.
So it sounds like I need to reference as of a recent date.
Otherwise _I'm_ stuck defining "Open Source". Not
competition the OSI board is likely to welcome!
Since you mention it, any chance you could help OSI put
together a revision history? As I can attest, from personal
experience, to the value of that kind of thing for those
reading to catch up.
--
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933
More information about the License-review
mailing list