MPL - The Mozilla Public License 开源软件许可协议 Netscape 公司

Qt/C++

MPL - The Mozilla Public License 开源软件许可协议 Netscape 公司

MPL 是 The Mozilla Public License 的简写，是 1998 年初 Netscape 的 Mozilla 小组为其开源软件项目设计的软件许可证。

MPL 许可出现的最重要原因是：Netscape 公司认为 GPL 许可证没有很好地平衡开发者，对源代码的需求和他们利用源代码获得的利益。同著名的 GPL 和 BSD 许可相比，MPL 在许多权利与义务的约定方面与它们基本相同 (因为都是符合 OSIA 认定的开源软件许可)。

但是，MPL 还有以下几点显著不同：

1、MPL 虽要求对经 MPL 许可发布的源代码的修改，也要以 MPL 许可证的方式再许可，以保证其他人可在 MPL 的条款下共享源代码。

但是，在 MPL 许可中对 "发布" 的定义是 "以源代码方式发布的文件"，这就意味着 MPL 允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以 MPL 许可证的形式对外许可外，源代码库中的源代码就可以不用 MPL 许可证的方式强制对外许可。这样，就为借鉴别人的源代码作自己商业软件开发的行为，留了一个豁口。

10 倍以上效率提升 智能站群 所见即所得 "HTML5 Bootstrap4 网页 IDE" 开发工具

http://ideweb.digitser.cn/

http://forum.digitser.cn/thread-2322-1-1.html

百度网盘

https://pan.baidu.com/s/1i5tKlZB

软件仓库

https://github.com/digitser

https://digitser.sourceforge.io/

https://pan.baidu.com/s/1TV70__Be1ta0ney1-tudFQ

2、MPL 许可第 3 条第 7 款中允许被许可人，将经 MPL 许可获得的源代码同自己其他类型的代码混合得到自己的软件程序。

3、对软件专利的态度，MPL 许可不像 GPL 许可那样明确表示反对软件专利，但是却明确要求源代码的提供者不能提供已受专利保护的源代码 (除非他本人是专利权人，并书面向公众免费许可这些源代码)，也不能在将这些源代码以开放源代码许可形式许可后再去申请与这些源代码有关的专利。

4、MPL (1.1 版) 许可中，对源代码的定义是："源代码指的是对作品进行修改最优先择取的形式，它包括：所有模块的所有源程序，加上有关的接口定义，加上控制可执行作品的安装和编译的脚本，或没有与初始源代码存在显著不同的源代码，或是被源代码贡献者选择的从公共领域可得到的程序代码"。

5、MPL 许可第 3 条有专门的一款，是关于对源代码修改进行描述的规定，就是要求所有再发布者都得有一个专门的文件，对源代码程序修改的时间和修改的方式有描述。

GPL (Gun General Public License)

著名的开源 Linux 操作系统，就采用了 GPL 协议。GPL 、BSD、Apache Licence、等开源许可协议，鼓励代码重用的开源范围有些不一样。

GPL 协议的出发点是代码开源、免费使用、引用-修改-衍生代码的开源-免费使用；不允许修改后和衍生的代码，作为闭源商业软件部分进行发布、销售。这也就是为什么我们能使用各种免费 linux 操作系统，包括商业公司的 linux 和 linux 上各种各样的由个人、组织、以及商业软件公司开发的免费软件的根本原因。

GPL 协议的主要内容，是：只要一软件使用  (类库引用、修改后的代码或衍生代码) GPL 协议开源代码，则该软件也必须采用 GPL 协议 (也必须开源和免费，这就是所谓的 "病毒传染性" 和 "不允许闭源的商业发布")。

由于 GPL 严格要求使用了 GPL 类库的软件也必须使用 GPL 协议，对于使用 GPL 协议开源代码的商业软件或对代码有保密要求的，就不适合集成作为类库和二次开发的基础。

GPL LPGL Mozilla BSD MIT Apache Licence 许可协议

BSD (Berkeley Software Distribution)

BSD 开源协议，是一个给予使用者很大自由的协议。基本上说，使用者可 "为所欲为"，可自由使用、修改源代码，也可将修改后的代码，作为开源或专有软件再发布。

但是，"为所欲为" 的前提是，当你发布使用了 BSD 协议的代码，或以 BSD 协议代码为基础做二次开发自己的产品时，需要满足 3 个条件:

1. 如再发布的产品中包含源代码，则在源代码中必须带有原代码中的 BSD 协议。

2. 如再发布的只是二进制类库、软件，则需在类库、软件的文档和版权声明中，包含原代码中的 BSD 协议。

3. 不可使用开源代码的作者、机构名字、原产品名字做市场推广。

以规则的目的，只有一个：他人的东西，别人以 BSD 开源了，就不能不做任何声明而占为己有，更不能用他人的名义来做商业推广，只对自己的东西拥有绝对控制权。

BSD 协议鼓励代码共享，但需尊重代码原作者的著作权。由于 BSD 允许使用者修改和重新发布代码，也允许使用或在 BSD 代码上开发商业软件并发布和销售；因此，是对商业集成很友好的协议。

很多公司、企业在选用开源产品时，都首选 BSD 协议；因为，可完全控制这些第 3 方源代码，在必要时还可修改或二次开发。

Source Code 和 Object Code

Source Code 指的是，以各种编程语言写成的源代码，通过 Source Code 结合文档，可了解整个软件的体系结构及具体到某个功能函数的实现方法等。

Object Code 指的是 Source Code 经编译后，生成的类似于 "类库"，提供各种接口供他人使用的目标码，也就是常见的 *.dll *.so *.pyd 等格式文件。

区分这两个概念的目的，在于：有些开源只发布 Object Code，当然，大多数发布的是 Source Code。很多开源协议也对 "发布哪种 Code 时应怎样" 有明确约束。

Contributors 和 Recipients

Contributors 指的是，对某个开源软件或项目提供了代码 (包括最初的，或修改过的) 的人或实体 (团队、公司、组织、等)。

Contributors 按参与开源软件的时间先后顺序，可分为 an initial Contributor 和 subsequent Contributors。

Recipients 指的是，开源软件或项目的获取者，显然，subsequent Contributors 也属 Recipients 之列。

Derivative Module 和 Separate Module

Derivative Module 指的是，依托或包含 "最初的" 或 "从别人处获取的" 开源代码而产生的代码，是原 "源代码" 的增强 (不等于增加)、改善和延续的模块，译为 "衍生模块"。

Separate Module 指的是，参考或借助原 "源代码"，开发出的独立的、不包含、不依赖于原 "源代码模块"，译为 "独立的模块"。

理解这两个概念的目的，在于：很多协议对涉及商业发布时，会有哪些是衍生的，哪些是独立的，有着明确的商业发布规定。

"长按二维码" 或 "扫一扫" 关注 "德云社区" 微信公众号

版权声明：
本文为独家编译稿件，版权归 德云社区，未经许可不得转载；否则，将追究其法律责任。