

大咖分享 | 开源许可证变更思考

安势信息

2023-06-19

导读：6月3日OpenChain开源治理论坛已经圆满结束。本文为大家带来丁紫薇女士的《开源许可证变更思考》分享解读。

6月3日OpenChain开源治理论坛已经圆满结束。本次论坛有众多开源大咖为我们带来了精彩的关于开源治理的演讲分享。今天为大家带来来自openKylin社区合规 SIG 的maintainer丁紫薇女士的分享——《开源许可证变更思考》。

如何变更开源许可证？

所有的开源软件都有其特定的开源许可证，但开源许可证也不是一尘不变，当开源许可证与公司的发展道路不一致时，就需要变更开源许可证，谁有权利变更开源许可证呢？项目的版权人，项目的版权人虽然有权变更许可证，但项目版权人可能不止一个，所以当想要变更许可证就会变成一个非常复杂的过程。

举几个例子：

►►►

例子一：LLVM

LLVM，从出现至今，关注者众多，一直是一个活跃的状态，截止目前，LLVM社区贡献者已经达到2975人，连续十多年代码提交持续保持热度。

图一：2001-2023年贡献者commit总览图

可以看到近几年的代码提交量仍然保持一个平稳的热度。

图二：近一周commit数量整理

而现在LLVM也在着手于变更开源许可证这一工作。

从2015年开始，LLVM社区就已经发起了对代码进行重新授权的提案，希望能够从现有的NCSA许可证更改为Apach 2.0。NCSA就是BSD和MIT的许可证，它的目的主要：一是为了降低代码贡献的门槛，能够鼓励更多的人参与LLVM社区；二是提供对现有贡献者专利的保护；三是确保LLVM可以被其他开源或者专有的编译器使用。

LLVM社区是如何变更开源许可证的？

主要分为这三个步骤：

在2015年前，LLVM社区就发现他们原来的许可证存在一些局限问题；
2015-2017年，就根据这些局限问题选择出最合适的开源许可证类型；
而近几年的工作致力于让这个新许可覆盖所有代码。

发现了哪些局限性问题呢？

局限一：发现原开源许可证中存在为LLVM做出贡献时给予不必要的广泛专利权获取的要求。

也就是说如果开发者在LLVM社区作出贡献时，要求他的专利权也必须给予到社区，这样的要求导致很多开发者在LLVM社区做出贡献而丧失热情，尤其是企业开发者，让企业的开发者望而却步。

局限二：开源许可证不统一

提到这个局限性之前，和大家提一下Compiler-RT，是LLVM中一个重要组件，它的主要作用是为硬件不支持的低级功能提供特定的支持，但由于LVVM和Compiler-RT组件的许可证不统一，所以导致很多代码都不可复用，这个问题也很影响LLVM的使用。

局限三：专利部分的措辞模糊

指的是原开源许可证专利部分是由一名研究生写的，并不是由专门的专业的律师编写的，所以导致缺少一定的法律的保护，这就导致很多潜在的用户觉得使用LLVM会有一定的使用风险，所以他们就不会支持LLVM。

在了解了这三个局限性后，LLVM社区决定一定要变更开源许可证，提出了三种方案：

第一种方案：制定一定新的许可证（缺点：过多的耗费精力）；
第二种方案：要求新的贡献者签署Apache、CLA协议（缺点：只能保证后面的新贡献者能够避免前面提到的三种局限）;
第三种方案：让Apache 2.0的协议覆盖掉所有LLVM代码。

所以他们经过探讨，提议采用 Apache 2.0 开源许可证，但是在上面做了额外条款补充，形成了一个专门针对 LLVM 的特殊版 Apache 2.0（Apache-2.0 WITH LLVM-exception）。在确定了变更方案之后，下一步就是LLVM社区就要着手联系所有的参与过社区贡献的版权人，确认其同意以Apache 2.0的协议分发，这无疑是一个浩大的工程，LLVM社区也知道这是一个复杂的过程，所以他们绘制了以下的图表，通过这个图表实时监控确认的进展。

图三：版权人贡献量和确认情况

近一每个矩形代表一个人所做的贡献，每个矩形的大小代表该人贡献了多少行代码

当矩形为绿色时：表示版权人所有贡献都完全包含在再许可协议中；

当矩形为橙色时：表示还没有收到确认的邮件或者电话确认；

当矩形为橙色并带有绿色星星时：这意味着该人的某些贡献被覆盖。

当然，除了绘制上面的图之外，他们还绘制了一些图表，每年都会持续更新这个图表，直到今年2023年还在持续更新中。

可以看到更改开源许可证难就难在获得所有版权人的同意，原则上很难百分百的获得协议覆盖所有历史贡献。

总结：根据我们刚分享的LLVM变更开源许可证过程描述，可以看到变更开源许可证大体上分为以下几个步骤：首先，会有一个原本的开源许可证；然后这个开源许可证已经难以满足现状，出现了一些局限性，那么我们就要根据这些局限性选择出一个合适的开源许可证。在确定了开源许可证之后，我们就统计所有的代码量，统计这些版权人的信息、邮件等信息，这样我们就可以通过邮件或者电话的方式获得所有版权人的同意，在获得所有版权人同意之后，我们就可以重新许可以新开源许可证授权原来的代码。

可以看到整个流程是比较复杂的，时间跨度较长。LLVM社区变更开源许可证时间跨度如此之长，主要原因就是在于它已经有了众多的版权人，如果要变更开源许可证，就要要求所有的版权人共同同意才能变更开源许可证。

►►►

例子二：LLVM

Linus Torvalds在1992年使用GPLv2发布了Linux 0.99版本至今已经有三十多年时间，GPL版本也有了GPLv3等其他版本，那为什么三十年间它依旧使用的是GPLv2，没有变更开源许可证呢？

第一个原因：Linux创始人Linus Torvalds在GPLv3诞生之初就强烈抵制GPLv3；
第二个原因：他们觉得更改开源许可证后会减少贡献者的热情；
第三个原因：三十多年了，时间太长，版权人太多，如果要一一取得他们的同意，几乎是不可能的事情。

综上所述：既有知道变更许可证是一个复杂的、但坚持要变更开源许可证的LLVM社区；也有因为觉得变更许可证是个比较复杂的过程，所以不变更开源许可证的Linux Kernel。

大家都知道变更开源许可证是复杂的，那么我们能如何尽量避免变更开源许可证这个复杂的过程呢？我们可以选择签署CLA或DCO，它可以一定程度上减少类似于开源许可证变更时的复杂过程。

CLA：社区属性比较弱，公司属性比较强，可以签署公司级别的CLA，而且它的签署是一次性的；DCO：社区属性较强，公司属性较弱，它需要在每次提交时，在commit信息中添加相应的信息。在CLA中我们可以提前在预设相应的条款，允许项目管理者拥有变更开源许可证的权利，但对于DCO来说，其他它变更开源许可证的权利就较弱了，它只是可以表明用户（提交者）遵守的是当前的协议，如果是变更开源许可证就比较困难了。

总结：如果是为了更注重个人贡献，考虑社区属性，可以使用DCO。但是对于大型项目，有众多合作方的项目，建议使用CLA。签署CLA，对贡献者而言意味着贡献者提供的贡献将授权给社区使用；企业或组织往往会以保护贡献者版权为由，要求签署CLA。如果为了后期的变更开源许可证，我们就可以在签署CLA条款中添加一条：同意项目管理者变更开源许可证不需要一一通知所有的版权人了。

总结：刚提到的例子，都是项目中只有一个开源许可证的情况，如果一个项目中有多个开源许可证，那么变更的开源许可证就要考虑一个因素：是否与项目的其他开源许可证兼容的问题。根据上述示例的描述可以看出变更开源许可证是个非常复杂的过程，在这里做个小小的扩展：其实现在变更开源许可证情况大体上都是开源软件孵化成了商业公司，然后我们需要通过开源软件获得商业的利益，这种情况一般都是从较为宽松的开源许可证变成较为严格的开源许可证，这种变更一般来说就更困难了。那么我们除了变更开源许可证，其实还有第二条路：使用双许可证的方式，在我们原来的开源许可证上提供商业授权许可即可。也就不需要这么复杂的变更许可证的过程了。

开源许可证变更对下游的影响

开源许可证的作用：约束的用户的权利、义务、限制，告诉用户能做什么、必须做什么以及如果这么做要附加哪些条件。

而开源许可证变更分成了两类：

一、从严格开源许可证到宽松许可证：对一般用户来说没有什么影响，大体都是从闭源项目转化成开源项目，没有影响反而方便参与者使用和贡献代码，吸引更多的开发者参与其中。

二、从宽松许可证到严格许可证：越来越多的厂商都是这类许可证的变更，这类许可证可能会伤害包括下游开源社区在内的开源软件用户，以及阻挠了开发者优化的代码反馈到上游社区。

这类案件也比较多，看几个案例：

1、Facebook：原先是想React协议改为BSD加专利许可，这个协议规定了公司如果采取专利主张或者其他方式起诉Facebook产生专利方面的纠纷，那么使用React许可就会被立刻撤销，当然这遭到了下游的抵制，最后Facebook只能妥协，重新将React协议改为MIT协议。

2、MongoDB修改许可证：修改的许可证对一般用户没什么影响，但要求云服务厂商如果想销售基于MongoDB的云服务，就需要完全公开其服务的源代码。

3、Elastic修改开源许可证：规定如果将本程序或修改版的功能作为服务提供给第三方，则必须根据本许可的条款，通过网络下载免费向所有人提供服务源代码。

以上变更开源许可证的案例，更加严格的限制了用户的使用，这也就有可能导致用户放弃对该软件的支持和贡献。

所以，除了对下游的影响，可能对项目本身也有影响，会失去开发人员的支持，甚至开发者创建新的分支，取代原项目，比如Xfree86、MariaDB、Wireshark等。因此如果计划变更开源许可证，也需要慎重考虑，可能会对现有的商业模式造成重大影响。

上述提到的开源许可证对公司未来的发展或对下游产生的影响，那开源许可证变更是否会影响历史版本呢？下列是GPL 3.0原文，第2条，提到：本协议一切更改都是对本程序的版权而言，并且在所述条件都满足时不可撤销（也就是说某软件使用了GPL 3.0，在本许可证的授权是不能撤销的）。

图四：GPL 3.0原文，第2条

另外，目前业界主流认为授权协议都是法律意义上的合同，因此原则上任何更改都不能溯及既往。也就是说：开源许可证的变更一般不会影响历史版本的使用。

如何处理开源许可证变更

分为两种情况：

►►►

从严格的开源许可证变更为宽松的开源许可证

1.一般不会影响用户的使用

2.确定变更的开源许可证条款及附加条款

►►►

从宽松的开源许可证变更为严格的开源许可证

首先，要确认开源许可证变更的种类，除了关注开源许可证的改变，还需要关注是否添加了附加条款。

在了解清楚变更的开源许可证条款之后，就可以判断下游能否继续使用软件，如果可以继续使用，我们就只能配合更改自身的合规规范，如果我们使用的是多许可的情况，我们还需要考虑上游变更的开源许可证与我们项目中其他开源许可证是否兼容,还需要修改项目License声明规范，如果存在附加条款要求，也需要配合修改；如果判断后不能继续使用，那就只能放弃使用这个软件，寻找替代方案。

什么情况下我们才需要关注到开源许可证变更？

1、作为用户完整的使用这个开源软件

2、开发者将开源软件以组件的形式引入、集成或耦合到自己的产品中

业界目前比较好的实践：建立一个中心仓，公司内使用的所有开源组件，引入中心仓前进行合规检测，引入后进行版本变更升级时，需再次确认相应的开源软件许可证是否变更。

正是因为有开源软件使用、开源组件引入等情况，尤其是可能耦合到产品中时，就需要认真考虑License等兼容性问题，因此要摸清产品所涉及到的开源组件就显得尤为重要，这就是为什么需要SCA工具和SBOM的重要原因之一。

结尾：根据我们这边列出来的案例，采用开源许可证变更的方式进行防御终究不是长久之计，还是需要大家共同寻求一个双赢之法。

以上就是来自于丁紫薇女士的分享，更多关于这次活动的大咖分享关注我们，将陆续推出！

关于安势信息

上海安势信息技术有限公司成立于2021年，致力于解决软件供应链中的安全和合规问题。作为中国领先的软件供应链安全治理工具提供商，安势信息以SCA（软件成分分析）产品作为切入点，围绕DevSecOps流程，着力于从工具到流程再到组织，坚持持续创新，打造独具特色的端到端开源治理最佳实践。

欢迎访问安势信息官www.sectrend.com.cn或发送邮件至 info@sectrend.com.cn垂询。

点击蓝字关注我们

【声明】内容源于网络

安势信息

安势信息是国内先进的软件供应链安全治理解决方案提供商，提供包括清源SCA（软件成分分析）、清本SAST（静态代码扫描）、清正CleanBinary (二进制代码扫描)、安全服务等解决方案，提供各行业的软件供应链安全治理最佳实践。

内容 170

粉丝 0

安势信息安势信息是国内先进的软件供应链安全治理解决方案提供商，提供包括清源SCA（软件成分分析）、清本SAST（静态代码扫描）、清正CleanBinary (二进制代码扫描)、安全服务等解决方案，提供各行业的软件供应链安全治理最佳实践。

总阅读310

粉丝0

内容170