[License-discuss] Boilerplate license text for permissive licenses?

[Luis Villa]

On Mon, Nov 26, 2012 at 2:55 AM, Gervase Markham <gerv at mozilla.org> wrote:
> Dear license-discuss,
>
> Short version: can the OSI please consider providing generic, appropriately
> wrapped, plain-text, copy-and-pasteable versions of the MIT, BSD (2 and 3
> clause) and HPND licenses, linked from that license's main license page, to
> cut down on license proliferation?
>
> Long version: I am currently attempting to make sure Firefox OS complies
> with the open source licenses of all the bits of code we are using. As you
> can understand, an entire operating system is quite a lot of code.
>
> I have written a script to analyse the codebase and extract all of the MIT,
> BSD and HPND license blocks in it. Each of these licenses requires the
> license text to be reproduced "in other materials provided with the
> distribution", or some similar words. My script counts as "the same" the
> ones where the differences are merely whitespace-based. We were advised that
> if two license blocks differ by more than that, e.g. if they mention a
> specific person or organization in the disclaimer, then they are "different"
> and cannot be merged.

Let me preempt those on the list who disagree with this: I don't think
it's a very worthwhile discussion; it is understood that people have
different interpretations of this language, and no amount of
discussion here will change that.

> Here's a count of the number of different variants in my current draft
> licensing file, by license type:
>
> BSD2Clause: 30
> BSD3Clause: 55
> BSD4Clause: 12
> MIT:        23
> HPND:       42
>
> In other words, we will have to reproduce at least 160 different but similar
> license blocks in the documentation for Firefox OS.
>
> Some of this is unavoidable; the MIT and BSD licenses have changed over
> time, and some of this code is very old. Some of these differences may
> indeed have some legal effect.
>
> However, it seems that sometimes, people might be copying and pasting from
> the OSI website, but then they have to fill in the blanks and/or replace
> HTML-based formatting such as bullet points, and everyone does it slightly
> differently. For example, for bullets, we have "*" vs "a)" vs "1." vs "-" vs
> " ". I have seen BSD 3-clause variants, otherwise identical to the OSI
> version, with all of these bullet types.
>
> The trouble is, without getting into very detailed heuristics, simple moves
> like saying "OK, apostrophe, hyphen, period and digits don't count for
> determining license sameness" start to run the risk of removing significant
> differences. And the text says you have to reproduce "this license notice",
> after all.
>
> The MIT license on opensource.org is good, because it can simply be copied
> and pasted as-is: http://opensource.org/licenses/MIT Accordingly, a lot of
> uses of the MIT license in the codebase are that exact license.
>
> However, the BSD3Clause version has a placeholder in clause 3 for
> <ORGANIZATION>, which means that everyone who copies and pastes it will
> create a new license variant when they replace that part.
> http://opensource.org/licenses/BSD-3-Clause
> Whether there are other variations or not, this is a very common way of
> creating a whole new license.
>
> The BSD2Clause version does not have that, obviously. It's noteworthy that
> there are 2x as many 3-clause variants in the B2G codebase as there are
> 2-clause variants.
>
> Although it's now deprecated, and so maybe not used much, the HPND is even
> worse:
> http://opensource.org/licenses/HPND
> There are so many optional bits there that anyone attempting to use that
> license based on the OSI copy is almost bound to produce something unique!
>
> We can't prevent people from modifying license texts. But we can avoid
> _requiring_ them to do so! Can the OSI help with this?

Seems like a reasonable request to me.

I don't see any obvious reason offhand why our 3-clause and HPND
variants couldn't be fixed in the same way our MIT and 2-clause
"templates" are. But there would need to be (ideally not by me, for
time reasons) a more detailed review of a specific set of changes. I
do also wonder if anyone here has the historical memory to explain why
this is.

I wonder if there is an easy way to visualize the various changes you
have in your data set, to see where people agreed/disagreed/edited,
outside the obvious changes. Daniel German, cc'd, may have already
tackled this, or have other ideas along these lines.

Luis