23

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.

14

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.

  • As far as making new versions, the case of the FSF creating a provision to allow Wikipedia to relicense content as CC-SA is worthy to note. – Christian Dec 14 '13 at 18:32
  • Thanks! Just for clarification: @DougM said "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". I can still choose if my software remains licensed under the old version or if I want to change to the newer license version, right (see MPL2.0 section 10.2)? So if i'm intertrepeting the point about new versions correctly, only the users of my LPGL/MPL library are at an disadvantage if I choose to switch to a newer version and that newer version is not suiting them? – mucaho Dec 14 '13 at 19:11
  • 2
    Neither the LGPL nor the MPL have a mechanism for revoking a license grant. Once someone has the code, it's theirs under the terms of that license forever. And they get to pick whether or not the follow the then-extant license, or any successor license. (You can switch new distributions to a new version, but anyone who wants to fork cna do so as well. even if their "fork" doesn't change a single other part of your program.) – DougM Dec 14 '13 at 23:15
  • Ah, thanks for clarifying! Would you try to explain "they have the right to substitute the current version with a latter version", please? Does that mean (in an unlikely event) the FSF could institute a clause that says "all contributions to this software become our property" into the already existing LGPLv3.0 retroactively? – mucaho Dec 15 '13 at 8:49
  • 1
    They could try, but doing so would probably not succeed. They could, however, say "you can steal the name of any project you fork to LGPL4", or some other unexpected version. (They probably won't do that, but both they and Mozilla technically COULD, though the courts may not let them enforce such a clause.) – DougM Jan 25 '14 at 15:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.