Bug: MPL-2.0 (dep) should be compatible with proprietary

[LSerranoPEReN]

My project is under proprietary license and I have a MPL-2.0 dependency, that is shown to be incompatible with my project.

IANAL but my understanding is that the MPL-2.0 only cares about source code modifications, so there should be no compatibility issue here, since LicenseCheck is looking at compatibility with installed packages.

Am I missing something or is this a bug?

Many thanks.

[dfeyer]

I feel the same, but I'm not a legal person ... our projet is also impacted.

[FredHappyface]

Thanks for flagging this!

Disclaimer: IANAL (I am not a lawyer )

I've done some initial research to check I'd be happy addressing this, and it does appear that the advice around MPL 2.0 is significantly more permissive than say, GPL. One source is https://opensource.stackexchange.com/questions/10493/using-of-library-under-mit-license-with-dependency-on-library-under-mpl-2-0. Here is another source that suggests this is permissibale https://opensource.stackexchange.com/questions/12068/licensing-a-library-under-the-mpl.

My take on this is that it'd be permissible to use an MPL library in an MIT/ Proprietary/ etc project as long as you disclose the lib, and provide the source/ access to the source. Before I make any changes, I'd like to consolidate my understanding best I can (as this would be a large impact change!)

For now the best option would be to include --ignore-license mpl

[PhorstenkampFuzzy]

Any news on this?

[Triavanicus]

I've done some research on MPL 2.0. If you are developing a product that is designed to be distributed internally, then for all intents and purposes, MPL is permissive; however, if you are to distribute the MLP-licensed work externally (and not just using the code to perform some development operations), you must provide access to the source code of the files for MPL-licensed code, therefor if you make no modifications you can link to the original work (or provide it). If you have, then you will have to make your modifications public.

Mozilla provides a FAQ about their license, for which I obtained some of this information: https://www.mozilla.org/en-US/MPL/

Regarding this project, having the MPL as a failing license for proprietary works is the safer option, as it could prompt someone to look at what obligations are required for the MLP or avoid it altogether. If you agree to the MPL terms, you can edit the configuration or add --ignore-licenses mpl or --ignore-packages ....

[FredHappyface]

Thanks so much for looking further into this. I hadn't recognised that distinction. With that in mind, I agree that continuing to warn would be a safer option for now.

The design of this library will remain to err on the side of caution and by its nature, cannot replace human review. It's possible to ignore licenses or offending packages from the commanding or config though in the case of false positives

[LSerranoPEReN]

While I agree with the research of @Triavanicus, I don't agree with the conclusion for this specific case of checking compatibilities with python dependencies.

The MPL FAQ makes very clear that no source code modification means you can use the license you want for your own code:

Q11: How 'viral' is the MPL? If I use MPL-licensed code in my proprietary application, will I have to give all the source code away?

No. The license requires that Modifications (as defined in Section 1.10 of the license) must be licensed under the MPL and made available to anyone to whom you distribute the Source Code. However, new files containing no MPL-licensed code are not Modifications, and therefore do not need to be distributed under the terms of the MPL, even if you create a Larger Work (as defined in Section 1.7) by using, compiling, or distributing the non-MPL files together with MPL-licensed files. This allows, for example, programs using MPL-licensed code to be statically linked to and distributed as part of a larger proprietary piece of software, which would not generally be possible under the terms of stronger copyleft licenses.

In our case, we are checking the license of a python project against its dependencies, but we do not modify these dependencies. Therefore, we make no modification of MPL-licensed code and can release our project in another license, if we want.

Sure, we have to make the source code of the MPL dependencies available, but :

• if a dependency is pure python, the source code is already available, since it's the dependency itself.
• if a dependency is binary, the source code should have been made available by the package maintainer if they respected the MPL license.

Please tell me if I'm missing something here.

[PhorstenkampFuzzy]

I would aggre. Just providing a list of sources / packages would be enough to fullfill the obligations there. But using MPL comes with that obbligation. Maybe just add a notice that an SBOM is needed to the report?