BSD - Berkeley Software Distribution 软件开源许可协议 Unix 操作系统

BSD 是 Berkeley Software Distribution 的简写。

BSD 许可原先是用在 "加州大学柏克利分校" 发表的各 4.4BSD、4.4BSD-Lite 版本上面的，后来也就逐渐被沿用下来。1979 年 "加州大学伯克利分校" 发布了 BSD Unix 操作系统，被称为开放源代码的先驱，BSD 许可就是随着 BSD Unix 发展起来的。BSD 许可现在被 Apache 和B SD 操作系统等开源软件所采纳。

相较 GPL 和 MPL 许可的严格性，BSD 许可就宽松许多，只需附上许可原文；不过比较有趣的是，它还要求所有二次开发者将自己的版权资料放上去，所以，拿到以 BSD 许可发行的软件可能会遇到一个小状况，就是这些版权资料许可占的空间比程序还大。

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

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

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

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

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

智能编辑重构 批处理式 "数字 Python IDE" 集成开发环境 (集成快速高效 Cython PyInstaller 批处理小程序)

http://dt.digitser.cn/zh-CN/ide/idepy/index.html

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

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

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

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

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

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

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

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 许可证的方式强制对外许可。这样，就为借鉴别人的源代码作自己商业软件开发的行为，留了一个豁口。

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

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

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

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

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

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

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

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

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

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

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

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

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