Mozilla Public License (MPL 2.0) vs Lesser GNU General Public License (LGPL 3.0)

Question

I would like to release a software library written in a class-based, object-oriented programming language (Java) on a web-based source code hosting service, that allows forks of the project to be merged into the main project (GitHub via pull requests). I have researched on the web and given a lot of thought on how to license the software. Am I correct in the following assumptions (from an IANAL perspective)?

• Both LGPL and MPL promote sharing of modifications to the LGPL/MPL licensed software being used inside other software projects. Instead of requiring the users of the modified library to host a seperate fork of the library, I can promote contributing to the original library (e.g. via pull requests).

• The major difference is how MPL / LGPL licensed code must be linked into the project. MPL source code files can be directly copied into a (possibly) proprietary software project (static linking), while LGPL licensed code must be dynamically linked (loosely linked to the possibly proprietary software project, so that end-users can switch out the licensed software library for another version of the licensed software library).

• Dynamic linking and thus LGPL imposes extra obstacles for packaging the proprietary software product, without promoting more contributions to the open source software library than by having static linkage (and thus MPL). There is a modified LGPL which allows static linking.

• There are no other relevant differences (from an IANAL perspective).

• The older license versions don't suit my needs as good as the newest ones.

As you can see my main requirement is that modifications of the software library which could prove useful to the general public stay open-source, without imposing restrictions on using the software library in a proprietary product.
There is no license that also requires extensions of the software library that are relevant to the original work to be released as open-source, as the scope of the term relevant can be arbitrarily small / huge, thus ending up as GPL that can not be used in a proprietary product (without releasing the whole source).

I am tempted to use the modified LPGL, but on the other hand discouraged by the unpopularity. Based on the above points I prefer MPL.
Question: Are my above statements correct? Which license should I pick considering my requirements?

---

Solution: With the help of the discussion in the accepted answer, I choose to stick to the MPL because of the popularity, freedom in linking and because it is an official, unmodified license.

Answer 1

I believe you've stated the differences between the Mozilla Public License and the GNU Lesser General Public License accurately, and either may suit your needs just fine, but you are skipping over the most important difference between the two licenses:

Who can make new versions?

Both the MPL (section 10) and the LGPL (section 14) include in their license grants the right to substitute the current version with a latter version, and there are no actual limitations as to what can go into those licenses. While it's highly unlikely that either the Mozilla Foundation or the Free Software Foundation will do something as crazy as, say, institute a clause that says "all contributions to this software become our property", it's not beyond the realm of possibility that one of the organizations will release a new license version that you don't like.

Which brings up another point about using a "Modified LGPL".

---

A modified license is not the same license!

While you have fairly amazing ability to specify your own licensing terms, and could in essence say "you can distribute this as per the GPL, but you need to put my name in your credits and pay me 1% of any revenue you generate", any time you do so you are creating a new license based on someone else's work. This means that you're NOT using the MPL or the LGPL, you're using a new "mucaho license".

What that means is that you probably won't get any help from your original license's author if you need to defend your interpretation of the license inside of a courtroom, and it's entirely possible that they might file suit to say that THEIR version should apply and not yours.

---

Of course, both of these are minor points. Even "license popularity" doesn't matter unless you expect your code to be directly incorporated into larger projects.

Personally, I think the MPL is a better choice if you like proprietary compatibility, or if the choice is between the actual MPL and a different license you have to manually edit based on the LGPL. Unless you have a reason not to use the MPL, go with something backed by a foundation instead of one that might leave you in a courtroom without any aid whatsoever.

Answer 2

The answer of DougM and AER makes a fair point. MPLv2 and LGPLv3 with static exception are the same regarding the events that would trigger the copyleft. However, I think we are missing another very important difference between LGPL and MPL. When the copyleft is triggered, the copyleft applies to:

• for MPL: to the very exact same files of your original library
• for LGPL: to the "work based on the library" as opposed to the "work that uses the library". So the LGPL can potentially extend its copyleft to new files.

Edge-case: Using MPL enables users not to share their improvements

MPL is a file-level copyleft license. It means that if somebody embed it in a larger project (statically or dynamically) and make a change to your file, he only has to release the change made to this particular file.

If you are concerned about keeping the integrity of your code base open, there are edge cases in which this copyleft effect of MPL might not be sufficient.

For example, someone could take one of the main file of your project, add "import my_private_new_file", and modify your main method for example by adding "my_private_new_file.newAwesomeFeature.run()".

And this way he could add new features to your project while only releasing the modified main file and keeping the actual logic of the new feature closed source in "my_private_new_file".

Having the main file back to the community just give you the information that "hey you added a new feature" but it doesn't enable you to incorporate this new feature in the open... It can be annoying if the new feature is closely-related to the problem that your library is trying to solve.

Obviously, that's an edge-case and it is quite unlikely someone would want to do that, but it is a risk that you must be aware of when using the MPLv2.

The LGPL is written to forbid such behaviours. See:

• https://www.javalobby.org//java/forums/t15903.html#91819035
• Does the LGPL allow me to do this?

I quote the original LGPL license:

Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run.

The copyleft applies to the "work based on the library" only. Now what is a "work based on the library" in practice? It leaves space to interpretation. Which is not only a nice thing as it means complying with your license becomes more complicated and therefore scary. It could lead some people simply not using your library.

In this sense, LGPL is more restrictive than MPL, but also more protective of the integrity of the project.

MPL makes it easier for users from the proprietary world to fix your library and use it, while still having to share the fix

An advantage for MPL is that if a user finds a bug in your library, he can fix it directly in the file, without having to give away all his code but only providing the fix. Practically speaking, when distributing his work to a client, he can just provide a link to a fork of your project containing the fix, and he is good.

By using LGPL, things are more complicated. If somebody forks your project, fixes a bug, and embeds it statically into his proprietary software, he must distribute to his users the "work based on the library" under the LGPL. Which is a rather obscure notion, especially when the library is statically embedded... In this regards, I think it was the original reason why there is no such thing as a "static" exception in the original LGPL. It makes the identification of the "work based on the library" trivial: it is the dynamic library you call in your proprietary software.

As a result, MPL makes it interestingly easier for proprietary vendors to use AND send fix to your library than LGPL.

At the same time, most times proprietary vendors do not have the resources nor the time to dive into your complicated library, and would most likely not fix it by themselves. They would rather open an issue on your GitHub repo, or send an e-mail in the mailing list and wait for your fix.

In this regards, LGPL enforces more this kind of behaviour. But is enforcing really needed?

Conclusion

Choosing between LGPL and MPL is a tricky question and, as usual with software license, depends on your goal. Both licenses are very similar but at the same time extremely different. They were designed for very different goals and philosophy.

LGPL was made by the the Free Software Foundation to enable the widespread use of Free Software libraries in the proprietary world but with always in mind the idea of promoting Free Software and fight against proprietary softwares. It is all part of a strategy towards their ideology. See: https://www.gnu.org/licenses/why-not-lgpl.html

MPL is a practical license designed by Mozilla to enforce some kind of share-alike to the original library, while still encouraging people to make proprietary softwares and add-ons on top (including Mozilla itself), which is a practice that the FSF authorizes via LGPL but still considers harmful.

By essence, MPLv2 is considered by many as a permissive license, while LGPLv3 including with static exception is rarely called this way.

EDIT

I forgot to mention something important. LGPLv3 (with or without static exception) forbids tivoization. You may think it is a "detail" but it is actually not, depending on your goal. Do you care about users Freedom? Then it is not a detail. Do you care that your library can be used on most portable devices? VLC cares more about being used, so they decided to use LGPLv2 which doesn't contain such restriction. Similarly, that's one of the reasons why Linux keeps using GPLv2. MPLv2 also doesn't have any tivoization restriction, obviously as it is a license created with the more "practical" Open Source philosophy in mind, not the FSF ideology.

There might be other "minor" things like this that I missed.

Answer 3

Dynamic linking and thus LGPL imposes extra obstacles for packaging the proprietary software product, without promoting more contributions to the open source software library than by having static linkage (and thus MPL).

This sentence is confusing. Also, "extra obstacles ... without promoting more contributions" is an opinion phrased as a factual statement.

The different requirements around static vs dynamic linking are related to the ability for packagers, distributors and end users to replace one library to another.

This can be required, for example, to fix security issues in a library, switch to a newer version with more features, to switch to a different implementation for reasons like hardware compatibility or licensing or due to patents and so on.

This allow an ecosystem of dynamically linked libraries to thrive. OTOH statically linked libraries are bound to the application and can became stale or struggle to develop a community of contributors.

LGPL encourages dynamic linking over static linking.