Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
LSerranoPEReN opened this issue Jul 11, 2024 · 10 comments
Open

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

LSerranoPEReN opened this issue Jul 11, 2024 · 10 comments
Assignees
Labels
bug Something isn't working

Comments

@LSerranoPEReN
Copy link

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.

@LSerranoPEReN LSerranoPEReN added the bug Something isn't working label Jul 11, 2024
@dfeyer
Copy link

dfeyer commented Jul 17, 2024

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

@FredHappyface
Copy link
Member

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
Copy link

Any news on this?

@Triavanicus
Copy link

Triavanicus commented Dec 30, 2024

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
Copy link
Member

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
Copy link
Author

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
Copy link

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?

@jmehnle
Copy link

jmehnle commented Mar 19, 2025

There might be a general use case for specifying to licensecheck whether distribution is intended or whether software is merely used. I believe for many free-software-licensed products the right to distribute dependencies matters (otherwise you couldn't distribute a functional product that's still open source), but for proprietary/unlicensed SAAS(!) products, which are typically not distributed, it's usually only the right to modify and use (desiring not to trigger a duty to publish/distribute, like the AGPL would) that matters.

As for the MPL specifically, it strikes me that the MPL isn't all that unusual compared to other free-software licenses such as the GPL, in that modification of the MPL-licensed piece triggers a publication/distribution duty only if the bigger product is distributed, but if the bigger product isn't distributed, then no duties are triggered. So, agreeing with @LSerranoPEReN, I don't see how the MPL is different from many other free-software licenses regarding use (without modification) in proprietary products.

@FredHappyface
Copy link
Member

This tool is primarily designed for the foss / open source community where distribution of software is expected. You're more than welcome to ignore certain licenses if you so choose but the default functionality is to err on the side of caution.

Realistically, if you're never distributing software then most licenses give you a lot of freedom in any case, so this will not be supported functionality in the short to mid term at least.

Happy enough to talk about accepting a pr with such functionality but this is a passion project aimed at the foss community. Not really intended as free labour for various orgs, and non-standard workflows as these are challenging for a single person to maintain in their spare time (and given the IANAL status, may not meaningfully reduce risk for an organisation in any case)

I'd be willing to add an undocumented method to use your own compatibility matrix. Then ultimately any decision taken to deviate from the licensechecks understanding of license conpat can be a risk an org takes on. Would this be an acceptable outcome?

@jmehnle
Copy link

jmehnle commented Apr 30, 2025

Actually, being able to customize the compatibility matrix would be amazing. I didn't even consider that option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants