LWN: Comments on "Mozilla Public License 2.0 released"

[RESOLVED] Does the same problem not exist by a different name?

louie — Thu, 05 Jan 2012 00:22:24 +0000

Some people in the MPL-using community (as distinct from the Mozilla community) do think of that as a genuine feature, and we did not want to prohibit people from being incompatible in such a case.

But again, note the issue of defaults: in the old license, if your purpose for using MPL was to be GPL incompatible, you could simply use the license, and justify use of the license for other reasons (well drafted, liked file-level copyleft, etc.) Your actual intent would be ambiguous.

In contrast, in 2.0, if you are using the license specifically because you want to be GPL-incompatible, you have to publicly and explicitly choose that behavior. So if that's the behavior you want, great, but you have to come out and say it.

[RESOLVED] Does the same problem not exist by a different name?

coriordan — Wed, 04 Jan 2012 23:39:37 +0000

OK, I see the logic now. Thanks for that.

For other licences that might copy this approach, I wonder if there are ways to narrow the usage of the "Incompatible" tag... It exists to solve a specific problem (compatibility with some existing code), so I wonder if the problem could be defined in the licence, and the "Incompatible" tag could be allowed only when being used to solve that problem.

I'll look at the patent stuff on Friday, so I'll let you know then if I see any glitches in the redline.

What's new for patents?

louie — Wed, 04 Jan 2012 21:35:19 +0000

I don't have time myself today to go into a full explanation of this particular change, but a redline is up at http://www.mozilla.org/MPL/2.0/differences.html

The redline is partially hand-generated and you're likely the first person other than me to review it completely, coriordan, so if you find any obvious errors, do let me know via email.

Does the same problem not exist by a different name?

louie — Wed, 04 Jan 2012 21:32:43 +0000

Your analysis is almost right (no surprise ;) but there are several subtle changes that mean it is more than a renaming and more of a (hopefully) significant shift.

1) the license is now default compatible, whereas previously it was default incompatible.

2) There is a single bit to flip, instead of two (LGPL + GPL) (There is a non-trivial amount of "MPL+GPL" code out there Mozilla couldn't use.)

3) Only copyright holders (or someone jumping through several hoops) can make the code incompatible, whereas previously any licensee could do so.

We hope that this (particularly the change in the default - people will have to go out of their way to break things) will make a significant difference in terms of the amount of code that is compatible and acceptable into the codebase.

Does the same problem not exist by a different name?

coriordan — Wed, 04 Jan 2012 20:18:21 +0000

Along with the tri-licence, Mozilla had a policy of only accepting code from third-parties if it's tri-licensed. That ensured that the whole codebase could be distributed under GPL.

The equivalent policy for MPL-2.0 would be to only accept code from third-parties if it hasn't been marked as "Incompatible with Secondary Licences". I presume Mozilla will adopt that policy.

So third-parties can still create code that the original project can't use, by marking their bits as incompatible.

So the problem has just been renamed, not fixed?

(There's nothing inherently wrong with renaming problems. I'm just asking if there's an actually fix or reduction of the problem that I just haven't seen.)

(I hope I don't sound like I'm playing devil's advocate. I'm just asking questions about stuff I might be explaining to others in the future.)

What's new for patents?

coriordan — Wed, 04 Jan 2012 19:56:20 +0000

I didn't realise that that was new. What section contains that stuff? Or is it a consequence of the new 5.2 wording (which replaces the old 8.2)?

I'll have to break down the sentences to find the differences, but not before the end of this week. Any starting points would be appreciated.

tri-licensing no longer necessary?

louie — Wed, 04 Jan 2012 19:45:08 +0000

It's a complex issue; I recommend reading my whole opensource.com post on the question: http://opensource.com/law/11/9/mpl-20-copyleft-and-licens...

What I wrote there in specific response to your question is:

"Can we do better than a dual-license?

The traditional solution for compatibility between copyleft licenses is to dual-license the code, allowing someone to use under either license as necessary. This approach obviously works, but it allows anyone to trivially create incompatible code by distributing changes under only one of the licenses, instead of both (or in the Mozilla case, all three) licenses. Once that happens, voila - whether intentionally or not, you've created code that the original project can't use, defeating the whole point of the copyleft license and making it harder to use the new code. This can't be completely avoided, but we wanted to find a different approach that would limit the circumstances where this could happen."

What's new for patents?

jmalcolm — Wed, 04 Jan 2012 19:44:20 +0000

The comment is a lot less ambiguous if you include the whole sentence. I think that leaving in "and allows an entire community of contributors to protect any contributor if they are sued" goes a long way to answering your question.

Clearly, they feel that the new license offers greater patent protection than before.

tri-licensing no longer necessary?

Kluge — Wed, 04 Jan 2012 19:31:24 +0000

Other than eliminating a relatively small amount of verbiage, what is the motivation for eliminating the tri-license?

It sounds like simplification at the cost of clarity.

What's new for patents?

coriordan — Wed, 04 Jan 2012 17:15:20 +0000

Are there any blogs / pages / mailing list threads with discussion of the patent changes? Is section 2.0's section 5.2 just a simplified version of the old 8.2? Slightly broader? Slightly different?

Any other interesting changes for patents?

I'd like to do a comparison myself, but it'll be a few days before I find the time.

(BTW, the announcement wording might be bad for some audiences: "patent protections for you and your contributors more in line with those of other open source licenses" - is that more protection (in line with GPL) or less protection (in line with revised BSD)? :-) That sort of ambiguous description is used by companies to avoid mentioning the details when they're *reducing* their offer.)

tri-licensing no longer necessary?

pjm — Wed, 04 Jan 2012 02:28:10 +0000

Tri-licensing does at least mean that a person immediately knows they can deal with the code under GPL/LGPL terms without having to read and hope that they've understood the MPL.

Mozilla Public License 2.0 released

louie — Wed, 04 Jan 2012 00:49:42 +0000

A more complete list of acknowledgements is also in the <a href="http://mpl.mozilla.org/2012/01/03/announcing-mpl-2-0/">full announcement</a>.

tri-licensing no longer necessary?

louie — Wed, 04 Jan 2012 00:48:36 +0000

Yes, phasing out the tri-license is one of the goals; it should happen in the near future.

tri-licensing no longer necessary?

coriordan — Tue, 03 Jan 2012 23:50:11 +0000

Mozilla Foundation releases much (most? all?) of their software under a tri-licensing scheme MPL/GPL/LGPL.

With the compatibility clauses in MPL-2.0 (mostly section 3.3), is that still useful?

There's a difference between the two situations, but it might be unimportant:

With the tri-license, Firefox uses all three MPL/GPL/LGPL licences, so I can download Firefox and I immediately have the option of distributing it under the GPL.

If some software was released under *just* MPL-2.0, it seems I'd have to write some GPL'd code, merge my code with the MPL-2.0 code, and *then* I'd have the option of distributing the combination under GPL.

So, does MPL-2.0 aim to make the tri-license situation unnecessary (and phase-out-able)? Or is it still worthwhile keeping the "immediate-GPL" option?

Mozilla Public License 2.0 released

pabs — Tue, 03 Jan 2012 23:21:41 +0000

A blog post about the people who worked on the MPL 2.0:

http://tieguy.org/blog/2012/01/03/personal-mpl-acknowledg...