开源许可证的兼容性

开源许可证兼容性的定义

​ 适用不同许可证的两个开源程序合并成一个较大的程序，或者把其中之一的代码合并入另一个时，如果各个许可证的限制或条件没有冲突，允许该种合并，我们就可以说这些许可证是兼容的。

常见开源许可证的特性

​ 判断许可证之间是否兼容，我们要先识别影响开源许可证兼容性的特性，通过分析常见许可证的官方原件，其特性列表如下图所示。

特性解释：

• 商业使用：该许可证下的代码和衍生品可以用于商业目的。
• 分发代码：该许可证下的代码可以被分发给第三方。
• 内部使用：该许可证允许修改源代码后在个人及组织内部使用，不必向外部分发。
• 专利授权：该许可证明确提出提供专利授权。
• 合并/修改代码：从要组合的开源软件中取出整体/部分代码，修改或不修改都可以，然后把它添加到你的代码中构成一个作品，分发时必须提供源代码。
• 使用库：在编译或运行时通过链接、导入或其他典型的机制（例如静态与动态链接）把开源代码与自有代码绑定在一起后，自有代码分发时必须提供源代码。
• 不允许修改许可协议：当使用“合并、修改、使用库”等方式组合开源代码与自有代码后，不允许自有代码使用不兼容的开源许可协议或闭源分发。

常见开源许可证的兼容性

​ 开源许可证兼容性列表的使用场景是针对开源项目选择许可证，假定有一个开源软件使用了一个许可证，而你想把它的代码组合到你要发布的开源项目中。

许可证的兼容性列表可以分为以下两种情况：

• 合并/修改代码：从要组合的代码中取出整体/部分代码，修改或不修改都可以，然后把它添加到你的代码中构成一个作品。
• 使用库：没有直接复制代码，在编译或运行时通过链接、导入或其他典型的机制（例如静态与动态链接）把要组合的开源代码绑定在一起。

备注：（下方内容可以对应到兼容性列表中有【1】【2】【3】的项）

【1】LGPLv2.1 允许你把代码重新按照 GPLv2 以后的 GPL 许可证发布。所以如果你可以把 LGPL 的代码按照合适的 GPL 版本发布，那么你就可以组合两方代码。

【2】MPL的代码和GPL系列的代码组合的结果是，MPL协议的代码遵循MPL协议，GPL系列的代码遵循GPL系列协议，所以原来按照 MPL 发布的那些文件还是可以使用 MPL 条款的，组合而成的作品整体上可以按照GPL系列的许可证发布。

【3】查看双方的许可证协议中是否包含一个条款允许你将协议升级到稍后的版本。例如，LGPLv2.1和GPLv3是不兼容的，但如果两方的许可证协议中都包含“可以升级到更高版本”的条款，那么LGPLv2.1就可以升级到LGPLv3，LGPLv3和GPLv3、AGPLv3是兼容的。

• LGPL+与GPL+代表许可证授予用户将许可证升级到未来版本的权利，例如LGPLv2.1+意味着用户可以把许可证升级到LGPL v2.1之后的版本。
• 下方的表格第一行展示了你的项目要使用的许可证，左边第一列是你要组合的软件带有的开源许可证，他们之间的交叉处显示了你是否可以组合他们。

合并/修改代码的许可证兼容性列表

使用库的兼容性列表

组合程序的开源许可证使用场景

​ 组合程序：组合开源代码与自有代码后形成的程序。

软件分发场景判断

​ 首先，我们要先判断我们的组合程序属于自用还是分发。如果组合程序属于自用，那么我们就可以无视开源许可证的规定与要求；如果组合程序属于分发，那么我们可以继续查看下图。

​ 当组合具有传染性许可证的开源代码时，用户会有不想使用传染性许可证或闭源发布作品的需求，那么我们就可以通过一些技术隔离方法来实现自有代码不被传染性代码传染。隔离方法按照强度可以分为强隔离与弱隔离，弱隔离可以隔离弱传染性许可证（LGPL），强隔离可以隔离强传染性许可证（GPL）。

弱隔离

静态与动态链接

​ LGPL许可证：如果将LGPL库与你的程序一起分发，无论是静态还是动态连接，那么你也必须分发该LGPL库的源文件。(1) 如果你是静态连接到LGPL库，那么你要提供程序的目标代码，这样用户就可以修改该库并重新连接成程序。(2) 如果你是动态连接到已在用户电脑上的LGPL库，那么你不必分发该库的源代码。

​ AGPL，GPL许可证：把AGPL，GPL许可证下的代码和其他模块静态或动态连接在一起就是在基于GPL作品合成一个作品。因此，GPL、AGPL许可证的条款和条件涵盖整个组合作品，你必须分发所有源代码。

强隔离

聚合体

​ 聚合体是由多个独立的程序组合而成的共同体。GPL允许你制作并发布一个聚合体，即使其他软件的许可证不是自由开源许可证，不是GPL兼容的许可证或闭源分发也可以。唯一的条件是你不能禁止用户行使每个独立程序许可证所允许的权利。

​ 如何区分是两个独立的程序，还是一个程序的两个部分呢？这本质上是个法律问题，会根据不同国家、不同地域的法律规定产生变化，但又无法脱离技术。从技术方面来看，独立程序的标准既依赖于通信机制，也依赖于通信语义（交换了什么样的信息）。

进程间通信的方式有很多，例如：

• 消息传递（管道、FIFO、消息队列）
• 同步（互斥量、条件变量、读写锁、文件和写记录锁、信号量）
• 共享内存（匿名的和具名的）
• 远程过程调用
• Socket通信

​ 如果两个模块都包含在一个可执行文件里，或者两个模块运行时共享内存，那么它们一定是同一个程序。反过来，管道、sockets通信和命令行参数通常都是两个独立程序的通信机制。但是如果两方的通信语义非常密切，共享内部数据结构，那么它们也被会认为是一个大程序的两个组合部分。

保密协议开发GPL修改版

​ GPL是不允许开发者使用保密协议发行软件的。也就是意味着如果有第三方从你这里获得了GPL代码的衍生品，他就有权发布该产品，你不能使用限制条款（例如NDA协议）来限制该产品发布。但是开发者可以签署一个“代表客户”开发GPL修改版的合同，规定只有在客户同意时才能发布你的修改。GPL许可证允许这样做的原因是GPL的代码并没有按照保密协议发布，没有在发布时添加任何限制条款。此时，你可以将你的修改按照GPL许可证发布给你的客户，但是只有在客户同意时才能把代码发布给第三方。

结论

​ 近些年来，开源技术发展迅速，开源软件在中国的市场份额与日俱增。但是随着市场竞争日益激烈，可以预想到与开源知识产权相关的法律纠纷会逐渐涌现。企业与个人在使用、参与或主导开源项目的过程中，需要更加关注开源许可证的合规使用与可能存在的风险。

​ 本指南根据开源许可证官方原件、开放源代码促进会（OSI）与自由软件基金会（FSF）网站许可证页面整理出常见许可证的特性和兼容性列表，阐述了开源许可证的使用场景，列出了开源许可证常见的违规使用风险。

​ 但是，指南内所有规则主要来源于国外的开源许可证，国内的法律与法院针对这些开源许可证也许有不同的看法。例如，在2019年的“柚子案”中，一审法院认为涉案的三个插件可以独立运行，分别存放在三个独立的文件夹中且三个独立文件夹中无GPL许可证，就此认定他们是属于独立程序；在“不乱买案中”，法院判断独立程序的规则是“展示方式、所用技术与分工不同”。所以在判断开源许可证是否合规使用时，我们需要考虑到不同国家、不同地域的法律规定。

​ 本指南并不是开源许可证兼容性的最终指南。相反，希望它可以作为开源许可证兼容性与使用场景深入讨论的起点，推动国内开源生态有序发展。