Both are called "weak copyleft". Only one of them constrains how you link.
For every way of shipping software, MPL-2.0 and LGPL-3.0-only reach the same verdict. Whatever separates them, it is not the obligation to disclose source. Read each license's own page for what else differs — patent grants and notice requirements are the usual answer.
Runtime dependency, dynamically linked. A build-time-only dependency reaches no user and carries no distribution obligation, whichever license it uses.
| How you ship | MPL-2.0 | LGPL-3.0-only | |
|---|---|---|---|
| Hosted SaaS | No obligation | No obligation | Same |
| Distributed binary | No obligation | No obligation | Same |
| On-premises delivery | No obligation | No obligation | Same |
| Internal use only | No obligation | No obligation | Same |
| Published library | No obligation | No obligation | Same |
File-level weak copyleft. Modifications to MPL-licensed files must be released under MPL, but your own files in the same project are unaffected. This makes it unusually easy to combine with proprietary code.
Weak copyleft built on GPL-3.0 with a linking exception. The practical question is almost always static versus dynamic linking, since static linking triggers the relinking obligation.
Full obligations for LGPL-3.0-only
Want to know which of these your project actually depends on?
Check your whole manifest →LicenseGuard reports information derived from published license texts and dependency manifests. It is not legal advice and using it does not create an attorney-client relationship. Results reflect license metadata as declared; they do not identify every obligation or violation. Consult qualified counsel for decisions that matter.
Listed in the official MCP registry, on Glama and on Smithery. Source on GitHub (Apache-2.0).