| |||||||||||||
tri-licensing no longer necessary?tri-licensing no longer necessary?Posted Jan 4, 2012 19:31 UTC (Wed) by Kluge (guest, #2881)In reply to: tri-licensing no longer necessary? by louie Parent article: Mozilla Public License 2.0 released
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.
(Log in to post comments)
tri-licensing no longer necessary? Posted Jan 4, 2012 19:45 UTC (Wed) by louie (subscriber, #3285) [Link]
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."
Does the same problem not exist by a different name? Posted Jan 4, 2012 20:18 UTC (Wed) by coriordan (guest, #7544) [Link]
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.)
Does the same problem not exist by a different name? Posted Jan 4, 2012 21:32 UTC (Wed) by louie (subscriber, #3285) [Link]
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.
[RESOLVED] Does the same problem not exist by a different name? Posted Jan 4, 2012 23:39 UTC (Wed) by coriordan (guest, #7544) [Link]
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.
[RESOLVED] Does the same problem not exist by a different name? Posted Jan 5, 2012 0:22 UTC (Thu) by louie (subscriber, #3285) [Link]
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.
|
|||||||||||||