Licensing: MIT/Apache-2 vs. MPL-2.0

I am confused by the general preference of the Rust community to dual-license under both MIT and Apache-2.0, as opposed to simply licensing under MPL-2.0.

I have made the following observations:

  1. Apache-2.0 is chosen as it provides an explicit patent grant for using the code in question.
  2. Apache-2.0 is known to be incompatible with GPL-2.0 and LGPL-2.1, which are still quite popular.
  3. MIT is brought in to address this compatibility issue.
  4. MIT does not provide an explicit patent grant of any kind.
  5. Apache-2.0 is not in effect when using the licensed code as a part of a larger work under GPL-2.0 or LGPL-2.1, but rather, MIT is.
  6. A user could be vulnerable to patent litigation due to the terms imposed on the combined work by GPL-2.0 or LGPL-2.1.

Now let us consider MPL-2.0 and what it offers:

  1. MPL-2.0 is a non-viral, file-level license.
  2. MPL-2.0 has no impact whatsoever on individual files that are not explicitly placed under that license.
  3. MPL-2.0 code may be freely combined with code under a different license to form a larger work.
  4. MPL-2.0 is explicitly compatible with GPL-2.0 and later, LGPL-2.1 and later, and AGPL-3.0 and later.
  5. In all of these cases, MPL-2.0 provides an explicit patent grant.
  6. The GPL-2.0 patent vulnerability with Apache-2.0 code is closed.

Strategically, it appears that licensing under MPL-2.0 would be both more concise (single-license), and provide a patent grant in all situations.

1 Like

Reading MPL-2.0, it looks like it's copy-left. If I am reading it correctly, it requires that if something is distributed as an executable, the source must also be given. Is this true?

If so, I think that's a big disadvantage compared to the MIT/Apache-2.0 combo. I don't know much about Apache-2.0, but I know MIT completely legitimizes companies using open source software in proprietary applications. They're required to give credit, but no source. Having the ability to be used in proprietary software gives users a lot more freedom, and I think that's generally been understood as positive by the Rust community.

Edit: Even if it isn't actually copyleft, and I'm reading it wrong - I think the length and complexity of the MPL-2.0 could itself be a disadvantage? Like, I can read and at least believe I understand MIT pretty easily, and as a layperson, MPL-2.0 seems much more complicated. I want to be able to be 100% sure I'm OK to use libraries, and MIT makes that very easy.

Reading MPL-2.0, it looks like it's copy-left. If I am reading it correctly, it requires that if something is distributed as an executable, the source must also be given. Is this true?

No.

If you use unmodified MPL-2.0 code in your executable, then you're supposed to link to the repository that has that code. This is easier to comply with than MIT which requires you to aggregate and distribute all copyright notices.

If you modify any MPL-2.0 files and distribute them in your executable, then you're obligated to share those modifications, but for those specific files only. You may handle your own code as you see fit.

I think the length and complexity of the MPL-2.0 could itself be a disadvantage?

The MPL-2.0 license was an open forum process. I believe there were three published drafts. It contains the language it does to increase its enforceability outside of the United States. That complexity is there to protect you. MPL-2.0 is simpler and easier to comply with than MPL-1.1 was.

I want to be able to be 100% sure I'm OK to use libraries, and MIT makes that very easy.

It also leaves people open to legal attack.

2 Likes

I believe it is mostly herd flock effect as compiler and prominent crates are using MIT/Apache-2

Personally I prefer to use BSL-1.0

1 Like

The TL;DR of it is that people tend to use MIT OR APACHE-2.0 because the compiler and std are licensed under MIT OR APACHE-2.0. It's a lot easier to go with the community standard than to try to understand subtleties of licensing to choose an appropriate one.

MIT and APACHE-2.0 are also "well-understood" OSS licenses, whereas MPL is a much less widespread license, so developers are less likely to know what they can do with an MPL library than one under MIT.


So why did Rust go with MIT OR APACHE-2.0 rather than MPL-2.0? If I properly recall seeing one the people who were around early (graydon, even?) saying it, it's because MPL-2.0 didn't exist when Rust first started development, and was licensed under MIT OR APACHE-2.0, and if it had, it likely might have been licensed under the one license rather than the OR it is today.


And there's the tertiary benefit that as MIT and APACHE-2.0 are both relatively short, they're decently approachable to try to understand as a nonlawyer. MPL, while not terribly long by license standards (and, based on me scanning it while I should be asleep, so, not very well, reasonably approachable), still feels more imposing to try to digest.

Compound that with the greater "cultural understanding" of the more common MIT and APACHE-2.0, and you get a reasonable enough doubt to cause people to stick to what they (think they) know.


Now, with the full disclaimer that I Am Not A Lawyer, and nor do I actually pretend to properly understand these particular licenses,

As I understand it, MIT OR APACHE-2.0 presents mostly the same protections and rights as MPL-2.0.

I also fail to see how the patent clause is materially different. Pulling the text from APACHE-2.0:

§3 Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.

Definitions:

"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.

"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.

This is a patent grant from the Contributor(s) to the users of the software. This patent grant still exists even if the software is used under MIT. Just because you use the software under the terms of one of the OR'd licenses doesn't mean you don't also have the rights provided by the other license.

While, again, I am not a lawyer, I suspect any suit that attempts to argue that, for some given software revision that is available under MIT OR APACHE-2.0, that some user who is transitively using the software reexported only under MIT is in violation of patent law to be quite ill-advised and likely to be quickly lost.


Nothing prevents you from using a license term that is different from that of the standard library, or even one that isn't OSI approved. Just be aware that if your library isn't clearly, unambiguously compatible with being used by a MIT OR APACHE-2.0 library, it's much less likely to be used by a big name in the Rust OSS ecosystem (with the biggest being, of course, the stdlib and compiler itself).


Mostly off topic side note:

Most OSS licensing misses the "point" of OSS as a culture, anyway. OSS as in FLOSS matters to some people (and for who it matters it matters), and developers typically want their software to be freely usable as championed by the OSI.

But OSS "culture" isn't about distribution of a product, but rather about the production of a product. A project isn't really "open source" in the common understanding of the term if $megacorp releases a code dump under $osi-license every 6 months and proceeds to develop it behind closed doors like any other proprietary software.

I expect to see OSI lose control of the OSS term (more so than they already don't really have control over it) and OSS to migrate to mean more about "developed in the open" rather than "viewable source" or "OSI licensed." It'll be gradual with the new generation of developers, but the shift I feel is already happening.

3 Likes

This is what I'm having trouble with. I don't see how this can be the case. If you're using the software under MIT terms, then those are the terms you're using the software under.

Those rights (Apache-2.0 and GPL-2.0) contradict each other. The situation is legally ambiguous at best.

But to my knowledge, that hasn't been tested in court yet. And until it is, entities with awareness are not going to want to bet on a favorable outcome if it does happen.

Look at Sisvel and their behavior. They are, for crying out loud, trying to make patent claims against AV1 and the Alliance for Open Media, along with VP9 and Google. They are almost certain to lose, but they are being a massive source of irritation anyway.

Then, at least in my non-lawyer opinion, they shouldn't be using GPL2'd software at all, due to the lack of a patent grant for the software, regardless of patent grants of transitive dependencies.

I will freely admit I am more familiar with GPL3, which contains a patent clause.

But I think the key insight here is that if you transitively depend on library A, which is licensed under MIT OR APACHE-2.0, through use of software B, which is licensed under GPL-2.0, you're using A (premodification) under MIT, not under GPL. B cannot take away or in any way limit your rights to (premodification) A.

The main "attack vector" would be if you stopped offering A under those license terms, but the version licensed as such will always still be available via crates-io (if the package was published that way).

If you have the worry and the means, by all accounts, please do consult an actual lawyer on this account; I'd be interested in an actual (personal) opinion (even if it's void of any binding Legal Advice) of someone with actual qualifications to hold an opinion here.


Oh, and one (Not Legal Advice) legal note: if you use some software B, which uses library A, it is not enough to just reproduce B's copyright notices. You are supposed to include the required copies of the license for every dependency of B that requires it, which includes our very own A which is under discussion. This will, if you do your due diligence, mean going back to A upstream to get the original license, at which point you can pull the APACHE-2.0 license and carry that around as well as your ticket to patent rights (assuming software B did not modify A significantly enough to be relicensed).

When I first stumbled upon MPL, I thought it was a viral license.

1 Like

GPL-2.0 has a patent grant, it just clashes with the one in Apache-2.0. This is precisely why, according to the FSF, Apache-2.0 code may not legally be included in a GPL-2.0 project. They want everyone to use GPL-3.0, but a lot of people don't care for it for political reasons.

GPL mandates that any software combined with it is used under its terms. So everything brought into a GPL project must be compliant with its terms. Apache-2.0 is not compliant with GPL-2.0's terms. This is why Rust components are dual-licensed under MIT as a fallback. But GPL-2.0's patent protections don't apply to a piece of code included under the MIT license.

Dual licensing presents you with a choice. Apache-2.0 is unenforceable when used in a GPL-2.0 project. Your fallback is MIT. All use of dual-licensed code in a GPL-2.0 project can only be covered by MIT.

MIT requires you to collect copyright notices. Apache-2.0 requires bundling a copy of the license text in addition to all NOTICES. MPL-2.0 simply has you link against the project's source repo. Much easier.

If it were this easy, the FSF wouldn't be telling us that Apache-2.0 code can't be included in GPL-2.0.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.