我们都知道，不同开源代码可能有不同的开源许可证。使用并分发开源代码需要符合开源许可证相关条例规定。因此，当我们希望把两段或者多段开源代码合并在一起，或者把其中之一融入到另一段开源代码时，我们就必须确保该行为满足这些不同许可证下的所有授权条款，这就是开源许可证的兼容性问题。
如果我们把两段开源代码合并在一起，需要注意以下方面：
- 判断是否兼容，即合并代码且同时遵循各个代码的许可证；
- 判断该代码的组合使用何种许可证。
我们把许可证分为三类：松散型，中间型（弱著佐权型）和著佐权型。松散型许可证不介意专有软件使用其代码。著佐权型许可证禁止专有软件使用其代码，它明确要求所有使用其代码的程序都要使用同样的许可证。中间型许可证限制但并不禁止专有软件使用其代码。
一般地，松散型许可证是互相兼容的。这是因为它们对添加到程序里的代码并无要求。它们甚至允许把整个（或带有修改的）程序添加到专有软件之中。在把使用松散型许可证的代码合在一起时，组合程序的每个部分都带有自己的许可证。当这些代码交织在一起无法分辨时，组合程序应该带上所有代码的许可证。由于这些许可证都是松散型的，均互相兼容，所以并不会有别的问题。
同理，松散型许可证通常也和著佐权型许可证兼容。在组合程序中，使用松散型许可证的代码仍然带着松散型许可证，而组合程序整体使用著佐权许可证。当然有一个很著名的例外：宽松型许可证Apache 2.0，由于带有特殊的专利条款，与GPL v2不兼容，但能与更新后的GPL v3兼容。同样特殊的还有原始的BSD许可证（BSD-4-Clause），它有一条特别的“广告条款”，要求使用任何该许可授权下的代码都要带有一个特定的声明。这种做法和大部分著佐权型许可证均不兼容。因此，目前大部分BSD许可都使用 “修改版 BSD 许可证”（删去了广告条款），原始许可证使用情况较少。
理论上说，两个不同的著佐权型许可证是无可避免地不兼容，除非两者之间有明确的兼容条款。这个不兼容性与著佐权的理念相关，是著佐权型许可证与生俱来的特点。著佐权的理念是“修改和衍生的作品必须延用相同的许可证”。如果使用许可证甲的开源代码A必须延用许可证甲，使用许可证乙的开源代码B必须延用许可证乙，而合并程序同时包含了A和B的代码，那么合并程序的许可证必须是甲，也必须是乙，这是不可调和的矛盾。这就是为什么即使同一著佐权型许可证的不同版本之间也不兼容，如GPL v2和GPL v3。
有两个常见的方法来摆脱不同版本的著佐权型许可证带来的先天不兼容性。
一种方法是开源代码的发布者在发布代码时，可以按“遵循该许可证及其后续版本”的方式发布其许可证。这样，如果A代码使用的是“GPL v2 or later”，B代码使用的是“GPL v3 or later”，当你将A和B代码合并在一起时，就可以先将A自主升级到GPL v3，再按GPL v3的许可发布整体的代码。同时，部分许可证本身就允许升级到最新版本，诸如Mozilla、PHP以及CC-BY-SA 4.0，就在其许可条款中明确说明用户可以将许可证升级到以后的版本的相同许可证。
另一种打破著佐权型许可证兼容性问题的方式是允许许可证的再授权，即使用许可证甲的A代码允许用户将代码按许可证乙重新发布。这样，当用户将A和B代码合并在一起时，就可以将整体代码按许可证乙发布而避免兼容性问题。
中间型许可证的情况较为复杂。中间型许可证通常也具有著作权的属性，通常对重新发布有一定要求，但因为其额外条款的存在、对次级许可的授权等，使其使用风险低于著佐权型许可证，因此又被称为弱著佐权型许可证。同时，也因为这些条款的存在，使得中间型许可证通常与著佐权型许可证不兼容。这类许可证解决兼容性问题的常用方式就是加上对次级许可证（通常是GPL系列许可证）的授权条款，使其可以按次级许可证再发布。
关于多许可的问题。部分开源代码提供了多个许可证，允许用户根据自身情况任选其一进行修改、发布。也有代码要求用户必须同时满足两个或多个许可证，如Elasticsearch采用的就是SSPL和Elastic License的双许可。对于多许可的兼容性问题，前者可以选择其中风险性较低的许可证避免兼容性冲突，后者则需要同时考察每个许可证的兼容情况。
文章内容用于学习和交流，仅供参考。如有不当，欢迎指正。
查看更多开源许可证：快速查询开源许可证｜柒巧板
柒巧板上新啦！
棱镜七彩作为国内专业开源成分管理及威胁情报服务的创新型科技企业，现全新推出柒巧板平台，免费提供一站式开源安全合规检测与开源测评服务，平台聚焦国内最主流的开源软件发展方向，助力开源行业安全与合规。更多讯息欢迎访问https://spdx.cn/
