MPL 2: GPL Compatibility?

The Mozilla Public License 1.1 is not compatible with (any version of) the GPL – that is, you cannot put MPLed code into a GPLed binary. The alpha 3 draft of the MPL 2 has opt-in GPL compatibility which can only be chosen at the time the software is first licensed (section 11.2).

I personally believe that most or all groups who are currently licensing their software under the MPL (only) would not mind, or actively desire, GPL compatibility, and the new MPL should give them the opportunity to choose it. I think most free software developers see licensing as a pain, and license incompatibility as a double pain, and would much rather everything were upwardly compatible with everything else.

To test this belief, and so we can appropriately publicize the new version of the MPL when it comes out, I am creating a list of MPLed projects. If you know of an MPLed project please add it to the list. And I want to hear from those projects as to whether they are opposed to, in favour of, or indifferent to, GPL compatibility for existing projects being put into MPL 2. Have a discussion on your mailing list and let me know the outcome.

Particularly if you or your project chose the MPL specifically because it is GPL-incompatible, please contact me. I will treat your response in confidence if you wish.

I’m also looking to make a list of GPLed projects using MPLed libraries (with a GPL exception of some sort – or even without!). That list is at the bottom of the same wiki page. If you are a GPLed project and wanted to use MPLed libraries but couldn’t, I want to hear from you too.

Please spread the link to this blog post throughout the free software community – I want to make sure I’ve reached as many MPL-using projects as possible.

Note: this canvassing of opinion is not official and is not binding in any way on the MPL 2 drafting team.

10 thoughts on “MPL 2: GPL Compatibility?

  1. It would be so cool if such compatibility would work either way – but having implicit (L)GPL compatibility would make things much easier at least for those of us who have been under tri-license for a long time now, as we’d get back to a single license and still allow the same usages.

  2. Ed: Because neither of those licenses meets our goals. See the FAQ question on changing the scope of the copyleft.

    Neil: Yes, the hope is that the tri-license can be transitioned to the GPL compatibility provisions.

  3. I think that this is really important – thank you for making this effort to address license fragmentation.

    Which restrictions in the MPL are being waived to provide compatibility with (L)GPL projects – would it not be clearer if these were explicitly stated as such?

  4. > I think most free software developers see licensing
    > as a pain, and license incompatibility as a double
    > pain, and would much rather everything were upwardly
    > compatible with everything else.

    I wish that were so, but I have a hard time reconciling it with reality. It certainly does not *appear* to me as if most free software developers feel that way, based on their behavior.

    On the contrary, I’m pretty sure most free software developers have the desire to to retain a measure of control over the code and how it can be used. Specifically, most developers *don’t* want other projects that operate under various licenses to be able to freely use their code. In fact, this is something most free software developers specifically want to prevent.

    If this were not so, licenses like the GPL and MPL would be obscure niche licenses that most of the community would shun, and the majority of developers would be releasing their code under significantly more liberal terms (i.e., fewer restrictions — simple attribution licenses, or even public domain).