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

[Kyle Mitchell]

McCoy,

Thanks again.  A few notes below.

On 2017-11-06 22:11, Smith, McCoy wrote:
> >>**This software comes as is, without any warranty at all.
> >>As far as the law allows, those giving this license will
> >>not be liable for any damages related to this software or
> >>this license, for any kind of legal claim.**
>
> Do you believe this to be sufficiently "conspicuous" to
> satisfy the requirements of, inter alia, UCC & UCITA?

Yes.

As a general matter, if the first term in a short license,
surrounded by asterisks, is not "conspicuous", then
conspicuous does not mean conspicuous.

More specifically, per UCC 1-201:

  "Conspicuous", with reference to a term, means so written,
  displayed, or presented that a reasonable person against
  which it is to operate ought to have noticed it.  Whether
  a term is "conspicuous" or not is a decision for the
  court.  Conspicuous terms include the following: ... (B)
  ... or set off from surrounding text of the same size by
  symbols or other marks that call attention to the
  language.

I don't have my print copy of UCITA handy, but here's from
Virginia, enacted:

  "Conspicuous," with reference to a term, means so written,
  displayed, or presented that a reasonable person against
  which it is to operate ought to have noticed it.  [...]
  With respect to a person, conspicuous terms include ...
  (ii) ... or set off from the surrounding text by symbols
  or other marks that draw attention to the language ...

If you'd like a prior from the OSI-approved corpus, MPL-2.0
uses asterisks in its canonical plain text rendering, linked
from this page:

https://www.mozilla.org/en-US/MPL/

Frankly, I'm not sure asterisks are necessary for a term at
the top of a license this short.  But it's nice to see a few
pretty things in the otherwise cold, dead world of legal
language that I've made my professional home.

> Do you think this language is sufficient to properly
> disclaim the UCC & UCITA warranties of merchantability and
> for a particular purpose?

Yes, under UCC 2-316(3)(a) and Virginia 59.1-504.6(b).  A
rare case of true legal "magic words".

> There's a reason why fairly specific language, and the
> SHOUTING ALL CAPS, has become ubiquitous in open source
> disclaimers, and I'm curious if you believe that is
> unnecessary.

Currently approved licenses are uniform in their general
approach, but vary widely in specific substance,
copy-and-paste jobs excepted.  The approach is unnecessary.
The substance we can make shorter, and no less effective,
without actively discouraging close reads with eyestrain.

That's more work, and more homework, but worthwhile.  Fair
License got it almost exactly wrong.  I thin L0-R gets it
right.

re long disclaimers:

There is "gotcha" case law out there to be found, where
courts in search of a way to read an egregious wrong out of
a disclaimer find a lengthy list of terms wanting for a
precise description of exactly the claim brought.  But
addressing those outcomes in the usual way, with a taller
and taller stalagmite of accreted legal terminology, is
ultimately self-defeating when the goal isn't a narrow
slicing and dicing of risks, but a general, blanket
disclaimer.

For a few reasons.  First because the more specific-sounding
words you use, the more the aggregate reads with intent to
disclaim and limit risks specifically.  Second because
courts will attempt to give different words different
meanings, opening up distinctions through which specific
claims can slide.  Third because describing every form of
new and old legal risk, in specific terms, at finite length,
is impossible, like painting a house with Crayola markers in
a rainstorm.

Some disclaimers go even longer, by stating general classes
of risks and following them with incomplete lists of
specific terms.  That's self-defeating, too.  Courts cannot
"unsee" the examples, even if the terms ask them to, and
they try to oblige.  The specifics will tend to limit
construction of the general class.

re all-caps formatting:

The belief that the law requires ALL CAPS to be conspicuous,
or that ALL CAPS are sufficient to make text conspicuous, is
widespread and wrong.  The UCC definition does not require
them.  As for sufficiency:

  Lawyers who think their caps lock keys are instant "make
  conspicuous" buttons are deluded.

  American General Finance, Inc. v. Bassett, 285 F.3d 882
  (9th Cir. 2002)

This came to my attention first through Ken Adams' A Manual
of Style for Contract Drafting.

As for how the misconception arises, I subscribe to Matthew
Butterick's hypothesis from Typography for Lawyers: that was
what typewriters could do, universally and easily, to make
text stand out.  So purpose and practice linked up, and got
stuck that way.

> >>You may do everything with this software that would
> >>otherwise infringe copyright in this software, or any patent
> >>anyone giving this license has or obtains that would have
> >>read on this software just after any of their contributions,
> >>on these conditions:
>
> Is there are reason why the statement about copyright is
> not limited to "anyone giving this license" but it is
> about patents?

The scope of the copyright license is bounded to the
copyrights in the software itself, which is itself the
potentially copyrightable work.  Which patents get licensed
isn't so grounded in the software, so the patent grant has
to specify them.  In doing so, it refers to those giving the
license.

I could have specified "copyrights that those giving this
license hold in the software", but that goes without saying.

> Also, is there are reason for copyrights
> you use "infringe" but for patents you use "read on"?

I use "infringe" to describe actions that licensees need a
license to take without liability.  I use "read on" to
describe the relationships between patents and the software,
to bring them under the patent permission.

I sometimes here "infringing product", though that seems
less correct to me than "accused product" or "the product
the patent they're accused of infringing reads on".  Always
grateful for others' takes on my usage.  My intent here was
to leverage the language I use with patent colleagues.

> The inconsistencies in language could result in
> inconsistent interpretations of the licenses granted.

For each license, I aimed to say, first, what licensees may
do, and second, under what IP.

- For both permissions, copyright and patent, the first is
  the same: "everything ... that would otherwise infringe".

- For copyright, the second is "copyright in the software".

- For patent, the second is "any [contributor] patent ...
  that would have read on this software just after any of
  their contributions".

A shot in the dark: might adding a verb clear things up, in
your reading?

  You may do everything with this software that would
  otherwise infringe copyright in this software, or infringe
  any patent anyone giving this license has or obtains that
  would have read on this software just after any of their
  contributions...

I could also split the grant language in two, at the cost of
some redundancy:

  You may do everything with this software that would
  otherwise infringe copyright in this software.

  You may do everything with this software that would
  otherwise infringe any patent anyone giving this license
  has or obtains that would have read on this software just
  after any of their contributions.

> Also, is "contribution" intended to encompass the original
> author's work, or just subsequent modifications? Many
> licenses make it clear (via a definition) that both are
> included, but I wonder if you think such a definition is
> unnecessary because it would be understood and interpreted
> in that way.

I don't think the plain meaning of "contribution", in
general or in the industry, distinguishes either early work
from later work, or original licensors' work from outside
licensors' work.  And reading "contribution" that
restrictively potentially makes the patent grant a nullity
for the original not-a-contributor, who's potentially the
only one giving the license.

Looking back at a few of the OSI-approved definitions of
"contribution" that come to mind, I think I would have
defined "contribution" in those licenses, too.  But largely
to counteract ambiguity arising from other terms and
structure.

That seems to be what happened in Apache 2.0, for example.
If you replace "any work of authorship" with "the original
version of the Work" in that definition, you end up with an
oddly circular sentence about submitting the original Work
to the Licensor for inclusion in the Work.  I'd be
interested to look back at the drafts.

> >>2. You may not make any legal claim against anyone accusing
> >>   this software, or any derivative work based on it, of
> >>   infringing any patent that would read on this software
> >>   alone, without modification or extension.
>
> Is the subject of the verb "accusing" "You," or "anyone"?
> The way this is written, it appears it is the latter (and
> makes the clause nonsensical:  "You can't sue for personal
> injury or defamation anyone who has made an accusation of
> patent infringement against this software"!).  I'd suggest
> more careful grammar.
>
> Also, what is the difference between a "modification" and
> an "extension"?  "Modification" is one act that falls
> within the definition of a derivative work in 17 USC 101.
> Extension does not.  I'd suggest you define the latter
> term if it is intended to describe something different. If
> it is meant to mean the same thing, then you should use
> the correct 17 USC based terminology.

Thank you for these points.  They strongly echo feedback
from others, off the list.

Here is where my revision stands at the moment:

  2. You must not make any legal claim against anyone for
     infringing any patent claim that would read on this
     software alone, accusing this software, with or without
     modification or extension, alone or included in a
     larger piece of software.

I've rearranged the clauses.  I think this order helps. It's
also the order I see in my early drafts.  I fiddled with it
too much.

Derivative work looked a tempting shortcut, until I
remembered where that road leads.  The accused-product
language now mirrors the copyleft conditions.

> >>3. If you modify or extend this software, you must release
> >>   source code for your modification or extension.
>
> Same comment as above with regard to "extension" vs.
> modification.

I've been all over the 17 USC 101 definition for other
projects these past few weeks, and failed to remember that
"modification" appears there.  I would prefer to dive _away_
from non-obvious, specific legal meaning in the copyleft
conditions.

I'll look into whether "modification" in the Copyright Act
has been read in any particular direction.  It may be that
"modification" alone works fine.

I'll also put some thought on whether "change" would work
here.  As in:

  3. If you change this software, you must release source
     code for your changes.

> >>4. If you include this software in a larger piece of
> >>   software, you must release any source code for that
> >>   larger piece of software that has not yet been
> >>   released.
>
> Is "include" the meaning in everyday English (inter alia, "to take in or comprise as a part of a whole or group"), or in everyday computer programming?  If the latter, you should make that clear.  If the former, I think you have a potential OSD 9 problem, since this would dictate the licensing of software merely on the same medium.
> Note that if you mean English "include" but also want to limit this requirement to non-distributed software (to get around the interesting anomaly in OSD 9 that it recites/possibly requires distribution), doesn't this suggest a rather odd OSD 9 avoidance loophole?  I.e., OSD 9 does not allow you to have a license that requires as a condition of distribution that software on the same medium be open source.  But surely that condition also applies in the circumstance for software on the same medium that is not distributed -- else one could avoid the requirement to disclose source by distributing the code.  This is one reason why I believe Richard's observation that Freedom Zero is inherently part of the OSD -- because if it is not, it results in rather bizarre results like allowing for licenses that require source disclosure for internal use, but which preclude that requirement for external use.

Bruce responded on this one, too, quoting your comments.
I'll respond there.

> >>5. If you run this software to analyze, modify, or generate
> >>   software, you must release source code for that software.
>
> I will echo Bruce's comments on this part.  "Analyze" and
> "generate" are verbs, outside of the rights articulated in
> 17 USC (and also not entirely clear on their own) which in
> most instances would not require an exercise of the
> copyright rights of the "this" software (other than the
> Freedom Zero right to use/run).  I believe this to be a
> violation of OSD 9 (if not by its actual wording -- since
> it recites distribution -- then its logical implication,
> as outlined above).  "Modify" may require use of the
> "this" software (to the extent that modification results
> in creation of a derivative work of the "this" software;
> in the instance when it is not, then it reverts back to
> the same problem (for example, a simple LZPL text editor
> used to write a piece of software but which does not
> import any of its own code into the created software --
> this imposes conditions upon the created software as the
> result of doing nothing more than exercising the Freedom
> Zero right to privately run the licensed software.

I'll take this up in the context of Bruce's comments, as well.

> >>To release source code, you must license it to the public
> >>under either these terms or terms approved by the Open
> >>Source Initiative, and promptly publish it, in the preferred
> >>form for making modifications, to a freely accessible
> >>distribution system widely used for similarly licensed
> >>source code.
>
> "Terms or terms approved by the Open Source initiative" is
> a bit unclear -- this could mean a license which has gone
> through the license approval process within OSI, or the
> "terms" of the OSD.

Agreed.  The terms/license distinction isn't clear, and
bringing it up isn't helpful.

I've revisions ready to go that speak here in terms of "this
license" and licenses approved by OSI.

> >>Any unknowing failure to meet condition 3, 4, or 5 is
> >>excused if you release source code as required within 30
> >>days of becoming aware of the failure.
>
> You might want to clarify that the "release [of] source
> code" articulated here are under the conditions above

Do you mean by something like...?:

  Any unknowing failure to meet condition 3, 4, or 5 is
  excused if you release source code as _required by the
  condition_ within 30 days of becoming aware of the
  failure.


Many thanks!

K

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