软件从闭源为主到开源成为主流，经历了几十年的发展。世界范围内，由于知识产权越来越受到重视和法律层面的保护，开源软件许可证也已经被广泛视为一种具有法律效力的合约，它规定了在软件使用和分发过程中的权利和义务。
近年来，开源软件的合法使用在中国越来越受到重视，从数字天堂和两柚子案到罗盒案，由于具有强传染性的 GPL 协议导致的争议为很多企业敲响了警钟，许多有意识的企业开始对使用的开源组件进行梳理。特别是一大批有出海业务的企业，由于随时可能面临外部的审查，这种对开源组件治理的需求会更加迫切。但目前，我国大部分企业对于开源软件许可证的理解和认识尚处于初级阶段：
- 开源许可证这个概念起源于西方，且开源的概念也是从西方发起的，我们要迅速完成从被动参与者到主动贡献者角色转变的难度比较大。
- 开源许可证超过 2000 多种，大部分企业内部缺少专业的团队来对许可证条款进行详细解读。
- 开源组件的许可证通常是英文的条款，即便是对同一个条款，不同的法律人士解读的角度也会不同。
本文将为大家介绍一些常见开源许可协议。
首先聊聊开源许可证的种类，其实分类的方法有很多，但是笔者认为不同的分类并没有对错之分，更多的是为大家在进行开源治理的时候提供较为清晰的思路。
对等型许可证
许可证的代表为 GPL 和 AGPL，它们具有如下特点：
- 软件本身必须开源
- 具有强传染性，与其有链接关系的代码都必须以 GPL 许可对外开源，即与该软件在同一进程中运行的代码都必须开源。
GPL 全称为 GNU General Public License, 第一个版本发布于 1989 年，之后又在 1991 年和 2007 年陆续发布了 v2、v3，还有其他衍生的许可证。GPL 许可证被认为是使用最广泛的开源许可证，我们常用的 Linux 核心就是以 GPLv2 发布的。
GPL 各个版本主要规定的权利义务如下：
GPLv1 主要在两方面做了限制：1.如果拷贝或者分发了 GPLv1 协议下的软件，那么必须开放源代码，不可以可执行的二进制文件进行发布；2.基于 GPLv1 发布的软件不可以与其他限制性更强条款发布的软件相结合。
GPLv2 主要的特点是 Liberty or Death 条款，这个条款表明，被许可人只有在满足所有许可证的义务下才可以分发包含 GPL 授权的软件，即使他们可能拥有其他的法律义务。此条款是为了保障和尊重用户在许可证下的自由免受专利侵权或者其他诉讼的侵害。GPLv2 是运用最广泛的一个版本。
GPLv3 主要在 GPLv2 的基础上做了如下改进：
- GPLv3 对专利做了明确的说明
- GPLv3 对 TiVo 这类硬件做了要求
- 使用者可以按照要求加一些补充条款（主要是免责和保护版权人权益方面的）
Linux 的创始人 Linus Torvalds 对 GPLv3 表达了明确的反对，因为 GPLv3 的第六条要求 TiVo 这类的厂商提供签名的私钥，使得人们可以运行修改后的代码，而 Linus 认为软件开发人员没有权利规定硬件厂商的行为，所以 Linux 使用的依然是 GPLv2。
GPLv2 第 6 条规定：不能添加任何额外的限制。仅从这一点看，GPLv2 和 GPLv3 是不兼容的，因为两者的第 6 条规定是冲突的，因此不能将使用 GPLv2 许可的代码和 GPLv3 的代码合并在一起。
AGPL，全称是 The Affero General Public License, 是 GPL 的一个补充，主要是针对网络服务商做了一些限制，在 GPL 协议中，修改和使用其代码都需要开源，但是这是建立在软件分发的基础上，如果使用代码作为服务提供，而不分发软件，则不需要开源。
AGPL 许可协议将 Copyleft 这一概念延伸至网络上开源软件所交付的服务。在 AGPL 的规定中，如果其许可的程序与用户通过网络进行远程交互，那么就需要提供源代码给用户，所有的修改也需要提供给用户。常见的“通过计算机远程网络交互”的场景有：网络和邮件服务器、基于互动的网络应用程序和在线播放的游戏服务器等。在 2018 年之前，MongoDB 社区版的许可协议从 AGPL 更改为 SSPL（SSPL 发起人为 MongoDB，目前还未获得 OSI 的批准）。
弱对等型许可证
这类许可证的代表为 LGPL，具有如下特点：
- 软件本身须开源
- 具有传染性，与其静态链接部分的代码也必须以 LGPL 许可开源；动态链接则不被传染。
- 若对其进行修改，若修改后增加的功能实现依赖于产品软件的数据或功能，则产品代码也会被传染。
LGPL 全称是 GNU Lesser General Public License，顾名思义，与 GPL 比，它的限制更少（Lesser），GPL 的核心主旨是用户需要公开软件作品和其衍生作品的源代码，但是 LGPL 要求用户仅共享基于 LGPL 许可证的组件的源代码，而不是使用它的作品的源代码。且 LGPL 更针对 C 语言及类 C 语言。
友好型许可证
这类许可证的代表为 MPL，具有如下特点：
- 若无修改，则无需开源
- 若对其进行了修改，需将修改的部分开源
MPL 全称是 Mozilla Public License，MPL 允许在其授权下的源代码与其他授权的文件进行混合，包括私有许可证。但在 MPL 授权下的代码文件必须保持 MPL 授权，并且保持开源。因此 MPL 既不像 MIT 和 BSD 那样允许衍生作品完全转化为私有，也不像 GPL 那样要求所有的衍生作品，包括新的组件在内，全部必须维持 GPL 协议。通过允许在衍生项目中存在私有模块，同时保证核心文件的开源，MPL 同时激励了商业及开源社区来参与帮助开发核心软件。
宽松型许可证
这类许可证的代表为 BSD/Apache/MIT，此类许可证并无开源要求。
MIT 许可证发起人为麻省理工学院，它的使用非常广泛，比如 PuTTY, Ruby on Rails, Lua, VS Code 等等。
BSD 许可证发起人为加州大学伯克利分校，遵守 BSD License 的软件，允许用作商业用途，甚至可按照专属许可证进行再发布。它被认为是一种 copycenter 类的许可证。
BSD 和 MIT 的区别在于，BSD 禁止衍生软件用你的名字做宣传，而 MIT 允许这一行为。
Apache 许可证的发起人为 Apache 基金会，它与 BSD/MIT 的核心区别是每一个修改过的文件，都必须放置版权说明。
以下是一些许可证方面的 Q&A 供大家参考：
Q: 在发布一个开源项目的时候，如何选择许可证？
A: 其实这是一个需要系统梳理的工程，不过我们可以参考阮一峰老师翻译的这张图来做初步判断：
Q: 一个组件可以使用多个开源许可证吗?
A: 可以的，比如 Firefox 最初的时候使用了三个许可证发布：MPL，GPLv2 or LGPL 2.1。Perl 也使用了 GPL or Artistic 协议的多重许可方式。但是要注意多许可证的兼容性问题。
Q: 如何分析许可证兼容性?
A: 通常许可证的官网会提供该许可证与其他许可证的兼容性分析 Matrix, 比如 GPL: https://www.gnu.org/licenses/...; EUPL: https://joinup.ec.europa.eu/c...等等。但是我们也可以通过一个开源的组织 OSADL（Open Source Automation Development Lab）提供的相对比较全面的清单来做审查，当然如果想要获得更好的效果，还是需要借助专业的 SCA 工具来进行内部开源软件的治理。
相信通过以上内容的介绍，大家对常见的软件许可证有了初步的了解，在后续的分享中，安势信息会持续给大家带来更多关于软件许可证的文章。