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
It sounds like simplification at the cost of clarity.
tri-licensing no longer necessary?
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds