Mozilla to update the MPL

[Posted March 10, 2010 by corbet]

The Mozilla Foundation has launched a process to update the Mozilla Public License. The project is described this way:

We've been using version 1.1 of the Mozilla Public License for about a decade now. Its spirit has served us well, helping to communicate some of the values that underpin our large and growing community. However, some of its wording may be showing its age. Keeping both those things in mind, we're launching this process to update the license, hoping to modernize and simplify it while still keeping the things that have made the license and the Mozilla project such a success.

While the update process is inspired by the GPLv3 update, the objectives are far less ambitious: Mozilla would like to smooth various rough edges without making major changes to the license. They hope to have the process complete - after releasing three drafts for comments - by November of this year.

to post comments

Document everything!

Posted Mar 10, 2010 18:02 UTC (Wed) by coriordan (guest, #7544) [Link] (1 responses)

For my assistance in the GPLv3, I chose to work on documentation and facilitating public comment. That's something I think's really important for the long term. I hope that material is now useful for this process, and I really hope the people of this process document everything so that it will also contribute to the next process.

We can't start from zero each time.

Document everything!

Posted Mar 11, 2010 0:42 UTC (Thu) by louie (guest, #3285) [Link]

That's my job, coriordan :) And we've learned quite a bit from the GPL v3 process, both good and
bad; thank you for your work in it.

Mozilla to update the MPL

Posted Mar 10, 2010 19:29 UTC (Wed) by bjacob (guest, #58566) [Link] (13 responses)

Not long ago I explored existing weak-copyleft licenses. Surprisingly, there are essentially two of them: the LGPL, and the MPL.

I couldn't use the MPL because it had strange clauses about resolving legal disputes in California, which really didn't make sense in the context of my own project.

The LGPL and MPL are fine licenses but they both are a bit more complicated than they have to. I went with LGPL v3 but even it has strange clauses about static linking (in section 4) which would be a problem if my project were a binary library (fortunately it's a pure template library).

My prediction: the absence of a minimalist weak-copyleft license leaves a huge gap to fill. Any license filling this gap first will meet great success. Indeed, weak copyleft is quite consensual as everyone hates proprietary forks of FOSS project.

Mozilla to update the MPL

Posted Mar 10, 2010 19:55 UTC (Wed) by jengelh (subscriber, #33263) [Link] (1 responses)

>clauses about resolving legal disputes in California

So one thing they should change in the MPL is s/California/residence of the copyright holder/.

>LGPL v3 but even it has strange clauses about static linking (in section 4) which would be a problem if my project were a binary library

Well, you are free to add an exception to your library's copyright wording.

Mozilla to update the MPL

Posted Mar 11, 2010 2:33 UTC (Thu) by paravoid (subscriber, #32869) [Link]

I think you are forgetting the fact that it's common for a work to have multiple copyright holders. Especially for free software, it's common from those holders to be from all over the world. What then?

Also, exceptions are nice and some of them extremely useful (e.g. the GPL/OpenSSL exception) but you can't call the result exactly GPL/MPL/whatnot. In terms that we are used to, you're essentially forking the license. Replying "but you can always add an exception" is similar to replying "but you can fork the software". You can do that obviously, but the point was, as far as I understood, that there's a "bug" somewhere in the original license.

Mozilla to update the MPL

Posted Mar 10, 2010 19:55 UTC (Wed) by josh (subscriber, #17465) [Link] (5 responses)

Regardless of any perceived problems, the LGPL represents the standard choice for a weak copyleft, much as the GPL represents the standard choice for a copyleft. It also has the advantage of GPL-compatibility <http://www.dwheeler.com/essays/gpl-compatible.html>.

The clause you mention about static versus dynamic linking just means that users of a program that uses an LGPLed library must have the ability to upgrade to a compatible but newer version of the library. Dynamic linking trivially satisfies that. If you really want to allow static linking of your library, but you still want some copyleft rather than an all-permissive license, then you could add an explicit exception allowing static linking.

Mozilla to update the MPL

Posted Mar 10, 2010 21:11 UTC (Wed) by elanthis (guest, #6227) [Link]

Sadly, some devices have no options for dynamic linking.

I really would like to use the LGPL in more circumstances, but pure
practical necessity makes it impossible and I end up using the revised BSD
or MIT/X license instead.

I realize that those locked down devices are explicitly something that the
FSF wants to abolish and hence they have no problem with the GPL/LGPL
blocking use of code on those devices. My priorities are simply different
than theirs, though, so I end up having to avoid the copyleft licenses
entirely and opt for highly permissive licenses.

Some companies or individuals will sell non-copyleft licenses to their
projects for developers working on locked devices. SDL through Galaxy
Games is going to do that with its 1.3 release so that it can be used for
iPhone development, for example. This is overall a worse situation for
downstream developers than if the project had just been licensed under a
more permissive license in the first place. A less restrictive iPhone SDK
would be best all around, but as a downstream developer, I don't have the
choice of making the iPhone unpopular, I only have the choice of tapping a
large market or not, and that in turn puts the burden on me to find and use
libraries licensed in a way I can use them. Best of all, of course, is
that a permissive license works perfectly fine with Free Software just as
easily as it does with restrictive software, so I am not forced to be
directly hostile to Free Software developers just in order to usable on
proprietary platforms.

I have considered the MPL in the past, and may consider it again for
certain uses in the future depending on what this revision updates.

Mozilla to update the MPL

Posted Mar 11, 2010 0:08 UTC (Thu) by renox (guest, #23785) [Link]

I disagree that the LGPL is really the standard choice like the GPL: people tend to use the GPL 'as it is' but this isn't rare to add an explicit exception to the LGPL..

Which is a pity because each different wording of an exception means a different license with potentially legal issue.
There should really be one license for this case.
I think that it would even be easy: functions defined in such programs would be seen as a public interface and
-it would not be allowed to 'hide' those function by another one without providing the sources of the new function (transitively).
-any modification to these functions should be available (transitively ie if you add a call to a function this function sources must be available too).
No need to add a clumsy restriction on the type of linking.

LGPL+exception

Posted Mar 11, 2010 23:12 UTC (Thu) by spitzak (guest, #4593) [Link] (2 responses)

Yes you can add an exception to the LGPL to allow static linking. I have done this as well. However I think the original poster (and me) want a clear unambiguous *short* name for this type of library. So far nobody has come up with one.

Rules for this license:

1. It is compatible with the GPL, in that somebody can legally take the code, add some GPL code to it, and redistribute the result as GPL (this disallows quite a few commercial attempts such as CDDL).

2. It does "what people think the LGPL does". You can use the resulting code in any way whatsoever as long as you do not alter it (ie you can link it into your closed-source program or compile it into a shared library). However if you do alter it you must include the source code for your altered version under the same license.

The LGPL's dynamic-linking requirement makes it useless for small projects that are not considered part of the operating system. First of all the need to include the shared library file with any distribution of the executable makes the software a pain to install. Second is that the whole idea of "relinking" does not work, such libraries want and need to be free to change their ABI.

It seems to me that the "exception" makes so much of the LGPL's text irrelevant that the actual license would be much much shorter. All I want is an official well-known name and text for such a license. A thousand similar exceptions are not a solution.

LGPL+exception

Posted Mar 12, 2010 0:05 UTC (Fri) by josh (subscriber, #17465) [Link] (1 responses)

If you don't want the rest of what the LGPL does either, you could simply use the GPL itself with a linking exception. The classpath exception would work as a model.

LGPL+exception

Posted Mar 12, 2010 19:00 UTC (Fri) by spitzak (guest, #4593) [Link]

I agree that GPL+this exception is equivalent to LGPL+exception. The exception completely exceeds anything the LGPL adds to the GPL.

The problem is that I found it necessary to make sure the name of the license included the "L" somehow. Otherwise people immediately assumed they could not use it for closed-source software. The name "LGPL" at least got them to look and perhaps discover the license.

I am still hoping for a short 3/4-letter named license that is in popular use that I can use. Having the letters "G" and "L" in the name may be a good idea, too.

Mozilla to update the MPL

Posted Mar 10, 2010 22:42 UTC (Wed) by mjthayer (guest, #39183) [Link] (3 responses)

> I went with LGPL v3 but even it has strange clauses about static linking [...]
LGPL plus Glibc exception?

Mozilla to update the MPL

Posted Mar 10, 2010 22:48 UTC (Wed) by bjacob (guest, #58566) [Link] (2 responses)

I like using plain unmodified mainsteam licenses. Makes it easy for my user to convince themselves that there's no licensing issue with my software --- "it's just the plain old LGPL".

Mozilla to update the MPL

Posted Mar 11, 2010 8:28 UTC (Thu) by mjthayer (guest, #39183) [Link] (1 responses)

That was the reasoning behind my suggestion - "LGPL, no additional restrictions, the same
exception as Glibc" is also likely to be reassuring for library users, as a high proportion will
likely be linking with Glibc too.

Mozilla to update the MPL

Posted Mar 11, 2010 16:45 UTC (Thu) by bjacob (guest, #58566) [Link]

Ah, that makes sense.

That also makes me wonder what happened in the brains of the FSF people when they wrote the LGPL in such a way that even _themselves_ (well, GNU) had to add an exception to it for their own C library!

Mozilla to update the MPL

Posted Mar 11, 2010 0:48 UTC (Thu) by louie (guest, #3285) [Link]

Certainly one of the things we're looking at with MPL is to make it simpler; we'll look hard at some
of the issues you've highlighted.