Section 3.2 of MPL-2.0 states:

If You distribute Covered Software in Executable Form then:

(a) such Covered Software must also be made available in Source Code Form, as described in Section 3.1, and You must inform recipients of the Executable Form how they can obtain a copy of such Source Code Form by reasonable means in a timely manner, at a charge no more than the cost of distribution to the recipient; and

(b) You may distribute such Executable Form under the terms of this License, or sublicense it under different terms, provided that the license for the Executable Form does not attempt to limit or alter the recipients’ rights in the Source Code Form under this License.

I am interpreting this to mean that a distributed product must disclose all uses of MPL-2.0 code within it, and be specific about where that code comes from, even if it is unmodified. This would seem to apply, for example, to using MPL-2.0 components via build systems like Gradle and Cargo. Not just for immediate dependencies of the product, but for all cascading dependencies as well.

This seems prohibitive. I have a library, for example, that handles logging. It's made for other library developers to use. But if a library depends on my logging code, then any application using that library has to disclose that they're also using my MPL-2.0 library as a consequence.

Am I understanding this correctly?


Yes, your understanding is correct.

You may find it prohibitive, but it is actually a requirement of many open source licenses such as MIT, BSD, or Apache-2 that at least the license text is made available to users of a product that contains (indirect) dependencies under that license. The only thing that the MPL 2.0 adds on top of that is that those users are also informed where they can obtain the source code.

Some licenses go even further, because if you have an indirect dependency on a component under the GPL license, you must even make sure that everything, including your own code, is made available under a GPL-compatible open source license.

In the end this means that any project needs to check what indirect dependencies they pull in when adding a new dependency (version) to their build system and what licenses those dependencies have, so that they know what obligations they are entering into.

| improve this answer | |

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.