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

[Kyle Mitchell]

On 2017-10-24 23:10, Bruce Perens wrote:
> On Tue, Oct 24, 2017 at 9:46 PM, Kyle Mitchell <kyle at kemitchell.com> wrote:
> >
> > Please understand that I'm not doubting intent here, yours or that of
> > others who approved of the text later.
>
>
> And I just want to make sure that the users of this license don't run into
> trouble in court. One way to reduce ambiguity is not to include a
> not-for-purpose document by reference that will lead some judge into a
> rabbit hole when you could just copy a few sentences of language.

Incorporation by reference is not unknown to the courts.
Privately negotiated deals involve big stacks of documents
incorporated by reference, all the time.  Those documents
haven't the benefit of a single source of publication,
verifiable on the Internet.

That's not to say there aren't evidentiary issues connecting
separate documents.  But this is not new territory.

> > First, the sentences that follow use "must", not "may".
> >
>
> Must *allow* source code redistribution. Not must require it. All of the
> terms you want follow that, and are diluted by it.

That's a viable reading, but not the only viable reading.
And I'd argue it's far from the most natural.  To give you a
sense of where analysis might go, the subject of the leading
sentence is "software", not "license" or "distribution
terms".  The following sentence is passive.

> > 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.
> >
>
> People don't think of why the BSD license came about. The US Government,
> through ARPA, funded projects at UC Berkeley to add virtual memory
> facilities to Unix in order to support computer graphics, fast crash-proof
> filesystems and fsck (yes, there was Unix before fsck), and better
> networking. Since this was supported with your taxpayer dollars, the BSD
> license was created to give all taxpayers the maximal utility from that
> work. ARPA's mission was in part an economic one, not only to seed
> technology but to have the resulting industrial capabilities (both hardware
> and software) exist within US manufacturers in case they were needed for
> war. At the time, it was believed that facilitating the development of
> companies like Sun Microsystems and SGI was the best way to achieve the
> economic mission, and these companies were not out to redistribute source
> code.
>
> So, if the BSD license is silent on source code redistribution, it is
> mainly because they and their funder didn't expect anyone but them to do it.

Really appreciate this background!

Back to the matter at hand, at least under the law I'm
familiar with, courts will look outside the text of an
operative legal document, like a license, only when it runs
aground on a fact situation rendering it vague or ambiguous.
Otherwise, they stick to the "four corners", meaning the
language of the license itself.  The parol evidence rule
prevents introducing outside evidence to make terms
ambiguous, when they aren't on their own.

>From a different angle, the same point holds for MIT.  It
doesn't say anything about cost or preferred source form.

> > I'm convinced to use my own language, but neither
> > copying nor rephrasing come without cost.
> >
>
> There was a cost for referencing too, and we're not talking about a license
> the size of the GPL.

Forgive me.  I'm not sure what you mean.

Possible change to OSD?  We can solve that by date-locking
the reference.  That's very typical in contract drafting,
say for referencing a statute in force at the time a
contract is made.  No sweat.

> > That means a potential mismatch between "Open Source" as
> > defined by OSD and "Open Source" as defined by L0-R.
>
> I am just hoping to keep "Open Source" as it was intended to be when this
> organization was started, and that is fraught enough.

I'm in no position to contribute with authority to that
discussion.  But for what it's worth, lack of clarity there
makes the task of drafting new licenses to be proposed that
much harder.

> > 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.
> >
>
> If you reference the OSD to define what is a compatible license for
> modifications, you should also have a backup. As in "An OSI-certified Open
> Source license or a license no more restrictive than this one." And you
> will need separate language requiring source-code availability for the
> entire program.

Alas, from my lawyer's chair, "no more restrictive" doesn't
offer much clarity.  Restrictions---conditions or exceptions
to conditions---vary as often in kind as in extent.

I don't mean to be a spoilsport.  I'm sure I've seen that
language elsewhere.  But repeated usage doesn't make it any
more clear, I'm afraid.

> If the OSI minutes exist, dates and text of revisions can probably be found
> in it.

This is worth doing, no matter what comes of L0-R.

OSI may or may not hew to OSD as you originally intended it.
But the history shouldn't die.

I know it's work digging it all up, and repackaging for
outside consumption.  Alas, not all primarily documents make
it.  So it goes.

-- 
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933