MPL协议对文件级开源有何规定

本文目录导读：

1. 核心原则：基于文件的“复制粘贴”式传染
2. 具体规定拆解
3. MPL与其他许可证的区别
4. 实践中需要特别注意的点

MPL协议（Mozilla Public License，Mozilla公共许可证）对文件级开源有明确且具体的规定，其核心特点是 “文件级保护” 和 “弱著佐权”，这意味着它既不像GPL那样具有强传染性，也不像MIT/BSD那样完全自由。

以下是MPL（当前主流版本为2.0）对文件级开源的具体规定和理解：

核心原则：基于文件的“复制粘贴”式传染

MPL 2.0 的许可证边界是 单个源文件，它的关键在于：受MPL许可的文件，其代码（以及对其所做的修改）必须继续保持MPL许可，这个文件可以与其他许可证（如Apache 2.0、MIT，甚至专有许可证）的文件进行组合，形成一个更大的作品，而不会污染这些其他文件。

具体规定拆解

对“修改代码”的规定

这是MPL最核心的条款（通常称为“文件级保护”）：

• 如果你修改了一个原本是MPL许可的文件，这个 被修改的文件 必须 继续 以MPL许可证进行分发，你不能将一个MPL文件中的部分代码提取出来,放到一个私有文件中使其变为私有。
• 例子：你下载了一个MPL许可的 utils.js 文件，你修改了其中的一些函数，当你把修改后的 utils.js 分发给别人时，这个 utils.js 文件必须仍然是MPL许可的。

对“组合代码”的规定

这是MPL区别于GPL的关键点,当MPL代码与其他许可的代码组合成一个更大的程序时：

• MPL代码在各自文件中保持独立：只要MPL文件本身没有改动，并且作为独立的文件存在，它就可以与任何其他许可的代码（包括闭源/专有代码）链接、编译或打包在一起。
• 组合后的整体作品：对于整个最终产品（例如一个可执行程序、一个库文件），其整体许可证 可以不是MPL,你可以选择用闭源许可证分发整个产品。
• 重要条件：你必须提供一种方式，让最终用户能够获取到产品中使用到的所有MPL文件的源代码（包括你对它们的修改，如果有的话），典型的做法是在产品中包含一个README或LICENSE文件，说明MPL代码的来源,并提供下载源码的链接或方式。

对“新增文件”的规定

如果你在项目中 新创建了一个文件，且这个文件是你自己独立编写的（不包含其他任何MPL代码或衍生代码）：

• 你可以自由选择许可证：你可以选择MPL、GPL、Apache 2.0、MIT、闭源、或任何其他许可证,这个新文件不受项目中原有MPL文件的影响。

对“专利授权”的规定

MPL 2.0 包含了明确的 专利授权 条款：

• 任何贡献者在提交代码时，自动授予了用户对其实施该代码所必需的专利的 免版税、非独占 许可。
• 反诉条款：如果用户（你）因为某个MPL代码的专利问题起诉了原作者,那么原作者授予你的这项专利许可将自动终止。

MPL与其他许可证的区别

实践中需要特别注意的点

1. 不要误解“组合”：MPL的“组合”指的是链接、打包、编译等操作，不包括直接复制粘贴代码，如果你把MPL文件中的一段函数复制到你自己写的文件中，那么那个你自己的文件就变成了MPL的 衍生作品,必须用MPL许可。
2. 修改后的MPL文件的完整定义：你修改后的那个MPL文件本身，必须包含你的修改声明、修改日期，以及完整的MPL许可证文本（或指向其副本）,这通常通过文件头部的注释块完成。
3. 如何提供源代码：即使你的最终产品是闭源的，你也必须确保用户能获得你所使用的所有MPL文件的 对应源代码（Source Code），你可以在产品中附带链接、放在GitHub仓库、或直接提供压缩包。
4. 命名约定：MPL不要求修改后的文件有任何特殊的命名后缀（不像LGPL有时要求）,但强烈建议你清晰表示这是修改版。

• 对于想要保护核心代码同时允许商业应用的公司：MPL非常合适，你可以将核心算法库用MPL开源,同时允许其他公司在闭源产品中调用这个库。
• 对于个人开发者：MPL能有效防止别人直接复制你的单个文件后闭源,但仍允许他人自由使用和组合。
• 如果你想实现“全开源”（即所有衍生作品都必须开源）,选择GPL。
• 如果你想最大程度方便他人使用，不关心别人是否开源,选择MIT。

一句话总结MPL对文件级开源的规定：你修改的MPL文件必须继续开源，但你可以把MPL文件与其他闭源文件打包成一个闭源产品。