Updating the MPL

Posted on by Luis Villa

Yesterday Mozilla announced that we will be updating the MPL, with the aim of making the license simpler, easier to use, and more robust. Mitchell’s post captures what we want to do in more depth; if you’re interested in the process, you should go read it and our full website at mpl.mozilla.org.

I have the privilege of being heavily involved in this project. I use the word ‘privilege’ because, since right around the time I went to law school, my home page has said something to the effect of ‘Luis’s goal is to help innovators do their thing with minimal interference from and maximum assistance from lawyers.’ ‘Helping innovators do their thing’ is exactly what this project is all about, so I’m excited to be part of the process.

Firefox Cupcake

Firefox Cupcake, by M i x y, used under CC-BY

We’re looking to involve the Mozilla community, of course, and we’re also looking to involve people who aren’t normally part of the Mozilla community, like licensing lawyers. So the process will involve a lot of very smart, experienced, and often opinionated people, some of whom will have been working with the license for a decade. I will get the luxury of being the project manager/cat-herder: working on this much of the day, encouraging involvement, organizing feedback, sifting it for gems, and collating all of it into the starting points we’ll use for further discussion and improvement. I’m just the organizer, though- Mitchell (as original author and tentative module owner) has the final say on the text, and the voice of the community will be the community themselves- we’re looking for broad involvement from anyone who has something valuable to say about the license or their experiences with it. If you’re interested in helping out in any way, check out our participate page for more information.

The day-to-day work that this huge community of volunteers does to produce software actively chosen by 100 million people is much more important than the legalese that binds them. But the legalese does matter- it communicates our values and helps structure how we work with each other. So improving this legalese is important for the community, and a great opportunity for me to help out, and I’m excited to get started on it.

Published by Luis Villa

11 thoughts on “Updating the MPL”

  1. Obviously my only ask for the MPL is that you get a license out the other end that is GPLv3 compatible. I have no other requests/comments but that. Is that even on the table? Should I even bother to comment about that?

  2. Bradley: That was one of my first questions too. I think it has to be one of the top priorities. The real question is how, since we already know it is very hard to make any copyleft license “compatible” with GPL. Would you propose using explicit waivers like EUPL does, or what?

  4. Having a file based “weak” copyleft license like the MPL being (L)GPLv3 compatible would be very nice! Go for it!

    Or is the intention to keep using the triple-license MPL/LGPL/GPL choice for all Mozilla code?

  5. This seems to be a bit of a FAQ; I’ll probably have to write a blog post on it soon.

    Nutshell: the tri-license is effective-but-ungainly, so we’ll investigate trying to replace that with clean compatibility. If we can do it, we probably will. But as Simon points out, it is not easy to do with even a mild-copyleft license, which, by nature, includes language to the effect of ‘you can’t place additional restrictions on the code.’ Suggestions on how to do it (at Simon’s suggestion, we’re looking at the EUPL as one route) are welcome.

  7. From my outsider point of view with very little legal insight, I’d say it’s pretty easy to use a copyleft license that is compatible with the GPL : simply use the GPL.

    This also improves the “issue” of having so many different licenses to choose when writing a new project.

    I guess there are other reasons why this can’t be done, could you talk about it for us legal-newbies? :)

  8. There’s no need for a tri-license with both LGPL and GPL, as the LGPL lets you re-license as GPL anyway. It only needs to be MPL/LGPL.

    Interesting point with regards to including Apache code within the Mozilla project (e.g. from Chromium) – they’ll have to update LGPL/GPL to version 3+ rather than 2+.

    To be honest, I’d prefer just dropping the MPL and using the LGPLv3+ for all of the code. That also allows taking *any* code from WebKit, including that which is only LGPL-licensed.

  9. I guess there are other reasons why this can’t be done, could you talk about it for us legal-newbies? :)
    The FAQ talks about it, but nutshell is that (L)GPL- particularly v3- has vastly different copyleft requirements than MPL, which would place very different requirements on our contributors and distributors than we used to. Switching gears like that mid-stream without incredibly good reason is not a good idea. (Frankly, we’d be more likely to switch to Apache than GPL, if I had to guess, though I should stress heavily that neither of those is planned!)

    Ian: Chromium is primarily BSD-licensed, not Apache.

Comments are closed.