Mozilla 公共许可证 (MPL) 是一种弱 copyleft 许可证，它施加了特定的限制，以确保开放性，同时允许与专有代码集成。它的主要限制围绕着修改的源代码披露、与其他许可证的兼容性以及署名要求。这些规则在对 MPL 许可代码的直接更改强制执行开放性，以及允许在与其他代码库组合时具有灵活性之间取得了平衡。
第一个主要限制是，对 MPL 许可的源文件的任何修改都必须在相同的许可证下提供。如果您修改或添加到现有的 MPL 许可文件中，您必须公开分享这些更改，包括修改后的源代码。例如，如果您修复了 MPL 许可的库中的错误，则不能保持修复的专有性，它必须保持在 MPL 下。但是，这仅适用于原始 MPL 文件本身。如果您将 MPL 代码与不同许可证下的全新模块或文件（例如，专有或宽松许可证，如 MIT）组合在一起，则这些新组件可以保留在其原始条款下。这使得 MPL 比强大的 copyleft 许可证（如 GPL）更灵活，后者将要求整个组合作品开源。
第二个限制涉及与其他许可证的兼容性。MPL 2.0 明确允许将 MPL 许可的代码与 GNU GPL、LGPL 或 Apache License 2.0 下的代码组合在一起，但与其他许可证集成可能需要明确的许可。例如，如果您想将 MPL 代码与 MIT 许可证下的项目合并，您必须确保 MPL 的要求对于 MPL 许可的部分得到尊重。此外，如果您将 MPL 代码与 GPL 许可的代码组合在一起，则整个作品将受到 GPL 条款的约束。这创建了一个清晰的边界：MPL 的 copyleft 仅适用于其自身的文件，但在单个项目中混合许可证需要仔细遵守所有相关许可证的规则。
最后，MPL 要求维护署名和法律声明。任何 MPL 许可的代码的发布（无论是否修改）都必须保留版权声明、许可证文本和贡献者列表。例如，如果您发布包含 MPL 代码的已编译二进制文件，您必须包含许可证副本并注明原始作者，通常在文档或包含的声明文件中。这确保了代码来源和许可条款的透明度。这些要求不如 Apache License 2.0 等许可证中的要求（它强制执行明确的专利声明）那么繁重，但仍然强制执行对代码的使用和共享方式的基本问责制。