MPL 2 section 11

[Luis Villa]

On 11/22/10 4:10 PM, Wilson, Andrew wrote:
> Luis Villa  wrote
>
>> On 11/22/10 2:43 PM, Bruce Perens wrote:
>>> There will be little point in saying something is "MPL 2" because of the
>>> infinite number of appedici which can be added to modify the license.
>>
>> Could you clarify here, Bruce? I count only two such, aside from the
>> permission to make entirely new licenses.
>
> I count four variants: no Ex. A permissions at all, LGPL only, GPL only,
> and GPL+LGPL.

Ah. It is actually worse than that, given all the various "or laters". 
But it is better than that too; see below.

> My question, to which Bruce was responding, is how compatible these
> four variants are with each other.

They're all compatible, because Sec. 11's compatibility clause creates 
compatibility regardless of which Secondary Licenses a given file has 
previously been distributed under.

E.g.:

File A: licensed under MPL + compatibility language.

Work B: licensed under GPL 3-only.

Work C: licensed under GPL 2-only.

Distributor X combines File A with Work B and distributes Work B 
(including File A) to Distributor Y.

Distributor Y wishes to distribute the File A (as received from 
Distributor X) in combination with Work C.

Y can distribute File A by complying with the grants and requirements of 
GPL 3, MPL+compatibility language, or both.

If Distributor Y chooses GPL3-only, Y has a problem; they can't 
distribute in combination with Work C (under traditional interpretations 
of GPL.) Of course, this is also a problem in traditional dual-license 
schemes.

Distributor Y can instead choose to distribute under the permissions of 
MPL+compatibility language. Since MPL+compatibility language allows it, 
Y can combine with the GPL2-only Work C and distribute the resulting work.

If Y chooses "both", that is also acceptable; a recipient of Work C from 
Y will get File A under MPL+compatibility clause+GPL2+GPL3. Further 
hypothetical recipients could (if necessary) add LGPL, strip it back to 
"just" MPL+LGPL, etc., as long as MPL is maintained.

The key here is that, unlike in a dual/tri-licensing setup, you can't 
strip or alter the compatibility clause as long as MPL is present. So 
really, you don't have a plethora of licenses (MPL+GPL, MPL+LGPL, etc.): 
you have two, MPL+compatibility, and MPL-without. By building 
compatibility into the MPL itself, rather than using multi-licensing, I 
believe that we've increased compatibility and decreased fragmentation 
when compared to the situation with MPL 1.1 + multi-licensing.

Note that this analysis does not address any questions about the scope 
or breadth of GPL, but I believe that those problems are similar under 
both traditional multi-licensing approaches and our approach in Section 
11, so I don't think they should have any bearing on the acceptability 
of our approach.

Luis

-- 
Luis Villa, Mozilla Legal
work email: lvilla at mozilla.com (preferred)
work phone: 650-903-0800 x327
personal: http://tieguy.org/about/