OpenCV 拟更改授权协议，从 BSD 变更为 Apache License 2

技术编辑：徐九丨发自 思否办公室

---

2020 年 5 月 22 日，OpenCV 技术委员会在一次会议中提出，拟将授权协议从 BSD 协议改为 Apache License 2 协议。和 BSD 相比，Apache License 2 是一个更规范和更详细的开源协议。

更改协议为哪般？

对于开源授权协议的定义，我们可以参考百度百科词条：

自由软件/开源软件是自由的，免费的，源代码开放的，我们可自由下载安装和使用。同时，为了维护作者和贡献者的合法权利，保证这些软件不被一些商业机构或个人窃取，影响软件的发展，开源社区开发出了各种的开源许可协议。

开源许可协议有很多种，OpenCV 现在采用的是 BSD 协议。

BSD 许可协议原先是用在加州大学柏克利分校发表的各个 4.4BSD/4.4BSD-Lite 版本上面（BSD 是 Berkly Software Distribution 的简写）的，后来也就逐渐沿用下来。1979 年加州大学伯克利分校发布了 BSD Unix，被称为开放源代码的先驱，BSD 许可证就是随着 BSD Unix 发展起来的。BSD 许可证一度也被 Apache 和 BSD 操作系统等开源软件所采纳。

但这是一个只有三条简单条款的「简陋」协议，在某些情况下无法有效的保护用户。对此，OpenCV 举了一个例子来说明：

某名为“发明”的公司为某算法申请了专利，并发表了论文。因算法效果优秀，某 CV 爱好者依论文编写了代码，并以 BSD 协议将代码提交到 OpenCV。这个过程中没人知道算法已申请专利，隐患便被埋下。

另一名为“发财”的公司将 OpenCV 中的这个算法应用到其产品中。依照现有 BSD 协议，此公司可以商业销售产品，只需注明产品使用了OpenCV，而无需对用户开源。

“发明”发现“发财”使用了其专利技术，遂起诉“发财”要求赔偿和停止侵权，并顺带起诉或要求开源社区停止侵权。一旦发生这样的案例，“发财”肯定要破财。开源软件声誉也会受到负面影响。

为了避免发生类似的情况，OpenCV 技术委员会才决定将 BSD 协议改为 Apache License 2 协议。

该协议和 BSD 类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。但 Apache License 2 更规范也更详细：

1. 需要给代码的用户一份 Apache Licence
2. 如果你修改了代码，需要在被修改的文件中说明。
3. 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
4. 如果再发布的产品中包含一个 Notice 文件，则在 Notice 文件中需要带有 Apache Licence。你可以在 Notice 中增加自己的许可，但不可以表现为对 Apache Licence 构成更改。

其第三条「Grant of Patent License」明确规定了专利所有人通过代码向使用者进行“永久性的，全球性的，非排他性的，免费的，免版税的，不可撤销的”授权。也就是说，专利所有人同意永久授权，不可再起诉用户侵权。

目前 OpenCV 核心团队正在讨论更换协议的详细步骤。

常见的开源协议

开源软件的许可证都是基于开源许可协议的，常见的开源许可协议除了我们上文中提到的 BSD 和 Apache 之外，还有 GPL(GNU)、LGPL、MIT。

一、GNU 通用公共许可证 - GPL

General Public License，简称 GPL，也可简称为 GNU。该许可协议最初由自由软件基金会的理查德·斯托曼为 GNU 项目所撰写，并授予计算机程序的用户自由软件定义（The Free Software Definition）的权利。

GPL 是一个 Copyleft 许可协议，这意味着派生作品只能以相同的许可条款分发。这与宽松自由软件许可协议有所区别 ，如 BSD 许可协议和 MIT 许可协议就是其中被广泛使用的例子。GPL 是第一个普遍使用的 Copyleft 许可协议。

GPL 同其它的自由软件许可协议一样，许可社会公众享有：运行、复制软件的自由，发行传播软件的自由，获得软件源码的自由，改进软件并将自己作出的改进版本向社会发行传播的自由。

GPL 协议最主要的几个原则：

1. 确保软件自始至终都以开放源代码形式发布，保护开发成果不被窃取用作商业发售。任何一套软件，只要其中使用了受 GPL 协议保护的第三方软件的源程序，并向非开发人员发布时，软件本身也就自动成为受 GPL 保护并且约束的实体。也就是说，此时它必须开放源代码。
2. GPL 大致就是一个左侧版权（Copyleft，或译为“反版权”、“版权属左”、“版权所无”、“版责”等）的体现。你可以去掉所有原作的版权 信息，只要你保持开源，并且随源代码、二进制版附上 GPL 的许可证就行，让后人可以很明确地得知此软件的授权信息。GPL 精髓就是，只要使软件在完整开源 的情况下，尽可能使使用者得到自由发挥的空间，使软件得到更快更好的发展。
3. 无论软件以何种形式发布，都必须同时附上源代码。例如在 Web 上提供下载，就必须在二进制版本（如果有的话）下载的同一个页面，清楚地提供源代码下载的链接。如果以光盘形式发布，就必须同时附上源文件的光盘。
4. 开发或维护遵循 GPL 协议开发的软件的公司或个人，可以对使用者收取一定的服务费用。但还是一句老话——必须无偿提供软件的完整源代码，不得将源代码与服务做捆绑或任何变相捆绑销售。

GPL 协议和 BSD、Apache Licence 等鼓励代码重用的许可很不一样。GPL 的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代 码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种 linux，包括商业公司的 linux 和 linux 上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。

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

历史上，GPL 许可协议系列一直是自由和开源软件领域最受欢迎的软件许可之一。根据 GPL 许可的优异自由软件程序的例子有 Linux 内核和 GNU 编译器集合（GCC）。大卫·A·惠勒认为，GPL 提供的 Copyleft 对于基于 Linux 的系统的成功至关重要，给予向内核贡献的程序员保证他们的工作将有益于整个世界并保持自由，而不至于被不提供反馈给社群的无良软件公司所剥削。

二、GNU 宽通用公共许可协议 - LGPL

GNU 宽通用公共许可协议（英语：GNU Lesser General Public License，简称：LGPL）是由自由软件基金会公布的自由软件许可协议。它允许企业与软件开发者使用，或将 LGPL 授权的软件集成至他们自己的软件内（即使该软件是私有软件也被允许），同时不会受到 Copyleft 特性的许可证强制对软件开源的限制。该许可协议常被用于一些（但不是全部）GNU 程序库，在宽松程度上与 BSD、Apache、XFree86 许可协议相似。

GPL(General Public License)和 LGPL 是 GNU 的两种 License。LGPL 是 GPL 的一个为主要为类库使用设计的开源协议。

和 GPL 要求任何使用/修改/衍生之 GPL 类库的的软件必须采用 GPL 协议不同。LGPL 允许商业软件通过类库引用（link）方式使用 LGPL 类库而不需要开源商业软件的代码。这使得采用 LGPL 协议的开源代码可以被商业软件作为类库引用并发布和销售。

但是如果修改 LGPL 协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用 LGPL 协议。也就是说采用 LGPL 之项目本身虽然仍有「Copyleft」之限制条件，但这些限制不感染仅仅只链接到本项目的软件。不过此等软件仍会受到其他限制。

因此 LGPL 协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以 LGPL 协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。但 GPL/LGPL 都致力于保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。

三、MIT

MIT 许可协议（英语：The MIT License）是许多软件许可条款中，被广泛使用的其中一种。

MIT 许可协议之名源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称「X许可协议」或「X11许可协议」。

MIT 内容与三条款 BSD 许可协议（3-clause BSD license）内容颇为近似，但是赋予软件被许可人更大的权利与更少的限制。作者只想保留版权，而无任何其它的限制。

也就是说，你必须在你的发行版里包含原许可协议的声明，无论你是以二进制发布的还是以源代码发布的。MIT协议又称麻省理工学院许可证，最初由麻省理工学院开发。被授权人权利：

1. 被授权人有权利使用、复制、修改、合并、出版发行、散布、再授权及贩售软件及软件的副本。
2. 被授权人可根据程式的需要修改授权条款为适当的内容。

被授权人义务：在软件和软件的所有副本中都必须包含版权声明和许可声明。

---

远古时期，乌克兰程序员 Paul Bagwell 画了一张如何选择开源协议的分析图，国内大佬阮一峰对其做了汉化，有利于大家理解不同开源协议之间的差异：

开源授权协议的陷阱

开源授权协议的产生，是为了更好地好糊开源项目的产权。开源协议作为一种契约和授权方式，是用户合法使用软件作品的一个凭证，就相当于软件作者与用户之间签订的一份合同，而且是在有相应行为就默认接受的。

违反协议将侵犯专利所有人的知识产权，专利所有人可以提起诉讼。但随着商业公司逐渐成为开源的主要力量，开源变得越来越不那么「纯粹」，逐渐成为企业盈利的一种方式。

开源软件开发模式的选择、开源许可协议的选择、开源软件的盈利模式的选择，都是一脉相承、紧密相关的。例如，开源基金会主导的开源软件，往往会选择 Apache、BSD、MIT 这样的宽松的开源许可协议，以吸引更多的商业公司参与。商业企业主导的开源软件，往往会选择 GPL 这类强著佐权型许可协议，以保证其双许可商业模式的实现。

企业只有理解了开源的游戏规则，才能在开源中获利，有效降低知识产权侵权风险。

如果一个开源项目是一家商业公司主导，而这家企业又拥有代码全部的著作权，那么这家企业有权力随时变更该开源软件的开源许可协议，甚至不再开源。

这样的变更会让是用了 这些开源软件的企业陷入两难境地。在成熟的产品中更换开源软件，可能会造成很高的替换成本；如不更换开源软件，新的许可协议往往需要将私有代码公开甚至不允许商业销售，从而让企业面临更大的困境。

因此，开源虽好，但在选择开源软件进行项目开发时一定要慎重，不仅仅要对其性能进行检测，也需要对充分考虑其采用了哪种开源协议、是否存在知识产权风险。