Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Mozilla Public License 2.0 released
Posted Jan 3, 2012 23:21 UTC (Tue) by pabs (subscriber, #43278)
Posted Jan 4, 2012 0:49 UTC (Wed) by louie (subscriber, #3285)
tri-licensing no longer necessary?
Posted Jan 3, 2012 23:50 UTC (Tue) by coriordan (guest, #7544)
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?
Posted Jan 4, 2012 0:48 UTC (Wed) by louie (subscriber, #3285)
Posted Jan 4, 2012 2:28 UTC (Wed) by pjm (subscriber, #2080)
Posted Jan 4, 2012 19:31 UTC (Wed) by Kluge (guest, #2881)
It sounds like simplification at the cost of clarity.
Posted Jan 4, 2012 19:45 UTC (Wed) by louie (subscriber, #3285)
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."
Does the same problem not exist by a different name?
Posted Jan 4, 2012 20:18 UTC (Wed) by coriordan (guest, #7544)
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.)
Posted Jan 4, 2012 21:32 UTC (Wed) by louie (subscriber, #3285)
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.
[RESOLVED] Does the same problem not exist by a different name?
Posted Jan 4, 2012 23:39 UTC (Wed) by coriordan (guest, #7544)
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.
Posted Jan 5, 2012 0:22 UTC (Thu) by louie (subscriber, #3285)
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.
What's new for patents?
Posted Jan 4, 2012 17:15 UTC (Wed) by coriordan (guest, #7544)
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.)
Posted Jan 4, 2012 19:44 UTC (Wed) by jmalcolm (guest, #8876)
Clearly, they feel that the new license offers greater patent protection than before.
Posted Jan 4, 2012 19:56 UTC (Wed) by coriordan (guest, #7544)
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.
Posted Jan 4, 2012 21:35 UTC (Wed) by louie (subscriber, #3285)
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.
Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds