作者：肖滢；策划：h4cd

今年 1 月，Elastic 公司把 Elasticsearch 和 Kibana 的源代码，由 Apache 2.0 许可授权变更为双重许可模式，即 SSPL 1.0 和 Elastic 许可。二者都没有获得 OSI 的开源认证。 

对此，开源社区非常不满。为 Elasticsearch 做出贡献的开发人员约有 1600 名，但除了谴责之外，无能为力。因为每一个贡献者在提交代码之前，都签署了一份贡献者许可协议 （Contributor License Agreement，简称 CLA），这赋予了 Elastic 公司随心所欲使用每个开发者贡献的权利，并且完全合法。 

CLA 是什么？ 

大部分开源项目的贡献指南里，第一件事不是让你加入社区，而是让你先签署一份 CLA。没有CLA，你提交的 PR，不会被受理。 

CLA 跟开源许可证不一样，开源许可证也就 100 多种，CLA 那是成千上万种，每一个项目都有自己的 CLA。不过这些 CLA 之间也有共同点，因为大部分都是从 Apache 软件基金会制定的 CLA 演变过来的。 

一份 Apache 风格的 CLA 大体上包含这些内容： 

• 关于签署该 CLA 的主体和贡献的定义；
• 授予版权许可给拥有该软件知识产权的企业或组织；
• 专利许可的授予；
• 签署者保证依法有权授予上述许可；
• 签署者确保所有的贡献内容均为原创；
• 签署者为贡献提供支持的免责描述；
• 说明贡献者提交非原创作品应该采用的方式；
• 保证在获悉任何方面不准确的事实或情况之时通知签约方。 

CLA 的条款内容冗长，且里面涉及很多法律术语，除了律师之外，大部分普通人都很难理解这些术语代表什么意思。如果你要弄懂，可能得花时间花钱找律师咨询。 

比如 Elasticsearch 的《 个人贡献者许可协议 》中关于版权许可的条款，是这样的： 

Grant of Copyright License. Subject to the terms and conditions of this CLA, you hereby grant to Elasticsearch and to recipients of software distributed by Elasticsearch a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute your Contributions and such derivative works.

 

 授予版权许可。根据本协议的条款和条件，您特此授予 Elasticsearch 和 由 Elasticsearch 发布的软件接受者永久的、全球的、非排他性的、免费的、免版税的、不可撤销的版权许可，用于复制、准备派生作品、公开展示、公开表演、再许可，并分发您的贡献和此类派生作品。

 诸如此类的内容，实在令人头疼。普通人不会知道，一个简短的词会让自己放弃哪些合法权利。 

为了打消贡献者的顾虑，作为管理项目的法律实体，一般是企业或组织，会在签署前告知或提示：“它不要求您将任何版权转让给我们，其所有权仍完全归您所有”，这一说法看起来不会有任何损失，但一旦签署了 CLA，贡献者将不能掌控自己交出去的代码。 

签署 CLA 之前的提示

比如，企业或组织可以根据上述条款中的“再许可”约定，直接更换开源许可证，甚至不需要通知贡献者。如果贡献者要求撤回或删除其提交的代码，也是不被支持的，因为协议中明明白白写着授予“不可撤销的版权许可”。 

不过也有例外，W3C 的贡献者许可协议就给贡献者留下了反悔的时间。在贡献代码后的 45 天内，贡献者可以书面形式，以任何理由发出撤回贡献的通知。 

也有部分 CLA，要求贡献者转让版权，而不是许可。二者的不同点在于，转让是转移版权的所有权，获得版权的组织可以再次将上述版权转让出去，而许可只是让被许可人获得了版权作品的使用权。 

自由软件基金会（FSF）就支持版权转让。不过有个前提，那就是 FSF 获得了原始软件包的版权，才会要求后来的贡献者将版权转让。FSF 认为，只有版权持有者或被转让的版权持有者才能进行版权执法。现在，要求转让的情况已经越来越少见，许可授予的权利足够多了，几乎跟版权转让一样多。 

大部分 CLA 的签署都是数字签名，在线签署或者把文件发送到指定电子邮箱，签署一次，就可以涵盖贡献者现在和未来对项目的所有贡献，对于中途签署的 CLA，还会覆盖到此前所贡献的代码。也有少部分像 Zabbix 一样，要求手写签名的 CLA 纸质副本才会被视为有效承诺。 

在线签署 CLA

为什么要贡献者签署 CLA?

企业或组织往往会以保护贡献者版权为由，要求签署 CLA。还提出了假设，如果他们想起诉开源违规行为，有了 CLA 授予的版权许可，这时就不必一一通知所有贡献者。但事实上，这种起诉很少发生。大部分起诉的出发点都是为了限制竞争对手。 

更大的原因可能是为了降低合并他人代码的风险。版权许可能避免撤销贡献者的代码，专利许可能避免贡献者起诉它们专利侵权，并且，条款中还有贡献者原创声明——如果合并后的代码侵犯他人版权，那么这是贡献者的责任。 

而利用 CLA 更换许可证，则是更为常见的做法。 

除了 Elasticsearch，MongoDB 也是这么做的。它要求开发者在贡献之前，必须先签署 CLA ，该协议将版权所有权分配给了 MongoDB 公司。这为其在 2018 年将许可证从开源的 AGPL 更换成非开源的 SSPL 扫清了障碍。 

甚至有不少开源软件为了更换许可证，也开始要求贡献者签署 CLA，而此前并不需要。 

Muse Group 是一家专注做音乐编辑软件的公司，旗下拥有 Ultimate Guitar、Audacity、MuseScore、StaffPad 等多款软件。今年 5 月，其战略主管 Daniel Ray 宣布引入 CLA，Audacity 的贡献者需要签署该协议才能为项目贡献代码。Audacity 是一款有着 20 多年开发历史的软件，其源代码在 GPLv2下发布，最近计划将许可证更新为 GPLv3，以支持 VST3。VST3 是一项新技术， 与 GPLv2 不兼容，但与 GPLv3 兼容。 

Daniel Ray 解释说，过去和未来的贡献者都将受该协议的约束，该协议赋予 Muse Group 对贡献的代码，具有如何使用、如何许可的无限权利。“该文件明确指出，从技术上讲，原始贡献者仍然是所述代码的所有者，他们可以在其他项目中自由使用它，但一旦合并到 Audacity 项目中，贡献者对它的命运没有发言权。” 

没有签署 CLA 会怎么样？

 没有签署 CLA，则表示贡献者没有授权，如果企业或组织要重新签署 CLA，或更换开源许可证，又或者起诉他人侵权，总之所有需要有版权才能做的事情，那么都必须一一通知贡献者并取得对方同意。 

对于贡献者较少的开源软件来说，这很容易；倘若是一些大型和长期项目，这个过程可能会耗费很长时间，因为企业或组织要找的可能不仅仅是数量众多的贡献者，还有他们的继承人。 

Audacity 此前并没有获得授权，所以在签署 CLA 这件事情上，Muse Group 也不得不联系该项目的所有个人贡献者，共 117 位，请求他们允许更改协议。 

Daniel Ray 表示，目前大多数人已完成签署，CLA 已经涵盖了代码总量的 90% 以上 ，其余的贡献很容易进行简单的重构。他还指出，只有做出重大贡献且源代码仍存在当前软件中的贡献者，以及所有新贡献者才必须签署。 

同样没有获得授权，LLVM 更换许可证的过程要更加艰难。 

2015 年，LLVM 社区发起了对代码进行重新授权的提案，希望能从现有的 NCSA 许可证更改为 Apache 2.0 License。六年过去了，这项工作还在进行中。 LLVM 社区正在追踪一些过去的贡献者，以收集他们对协议变更的认可。目前有 94% 以上的旧代码获得重新许可的批准，预计 2023 年可以接近 100% ，届时就可以合法地变更许可证。 

听起来有些不可思议，但没办法，大家都是这这么做的，Mozilla 也是花了数年时间（2001-2006 年）重新授权 Firefox、Thunderbird 和相关软件。 

CLA 的替代者：开源许可证和 DCO 的组合

 不过，CLA 并不是必须的，换句话说，CLA 不是获得版权许可唯一合法的方式。 

有些开源许可证就已经包含了版权和专利许可的表述。比如 Apache 2.0 License 就有相关条款，内容与 CLA 大体一致，这已经足够让企业或组织把分散在贡献者的版权集中在自己手里。贡献者提交 PR 的同时，已经将版权许可和专利许可授予出去。 

需要指出的是，如果开源协议中没有相关内容，又没有签署其它授予文件，那企业或组织就无法获得版权许可。 

这种根据软件开源协议贡献代码的方式，被称为“入站 = 出站”（“inbound=outbound”）。 GitHub 已经将这一方式加入其服务条款中，并默认开启。也就是说，贡献者在 GitHub 上提交 PR，则表示他同意以“入站 = 出站”的方式许可自己的贡献。 

 

CLA 中除了有版权和专利相关规定之外，还有一个重要内容，那就是贡献者原创声明，这也是 Apache 2.0 License 缺少的。将他人代码尤其是属于雇主的代码，私自贡献出去，最后被原始作者追究版权或专利，这种事情并不少见。因此，不少基于 Apache 2.0 License 的开源软件，如果没有签署 CLA，则会要求贡献者签署开发者原创证明（Developer Certificate of Origin，简称 DCO)，以规避这一风险。 

DCO 是 Linux 基金会在 2004 年提出的，用来记录代码提交的过程，以明确 Linux 源代码的来源和所有权。与 CLA 相比，DCO 条款简单，没有版权和专利许可的内容，它仅要求贡献者保证内容是原创，并且有权提交贡献，如果不是原创，则要保证自己没有修改。 

 DCO 的主要内容

总之，像 Apache 2.0 License 这样明确授予版权和专利许可的开源许可证，与 DCO 的结合，已经基本能覆盖 CLA 中的条款。 

为什么放弃 CLA?

 现在，越来越多的企业或组织放弃 CLA ，采用 DCO。 

2014 年，Node.js 的创始人 Timothy J Fontaine 取消了 CLA。他认为， CLA 是项目自我审核的一种方式，在必要时，CLA 会让项目在未来重新获得许可。虽然 Node.js 的 MIT 许可证已经很古老了，但未来不会改变许可证，签署 CLA 并不必要。他还表示，必须签署 CLA 有时可能会成为贡献的绊脚石。 

Gitlab 是一个开源软件，2017年在 Debian 开发人员的建议下，从 CLA 切换到了 DCO。Gitlab 方面认为，审查冗长的法律合同会推迟开发者的贡献，而且其中的条款会让他们放弃一些权利，CLA 不受开发者的欢迎。DCO 则为开发者的贡献提供了更大的灵活性和可移植性。 

GNOME 董事会董事 Carlos Soriano 对 Gitlab 的改变表示赞许，他认为 DCO 可以让知识产权保持在创作者的手中。 

2018 年，Helm 也转移到 DCO，它是一款 Kubernetes 包管理器。Helm 方面认为，签署企业贡献者许可协议（CCLA）的流程过于复杂，在 DCO 下贡献通常更容易。“在企业决定贡献后的第一步，是签署和交换法律文件，完成此操作后，再将开发者与这些法律文件联系起来，所有这些都需要时间。在某些公司中，此过程可能需要数周或更长时间。” 

低代码编程工具 Node-RED 正计划从 CLA 转移到 DCO，维护者 Nick O'Leary 认为，CLA 是冗长的法律文件，签署之前需要雇主的额外批准，会阻碍开发者做出贡献。DCO 的方式更加直接。开发者无需签署法律文件，而是“签署”承诺，为了表明他们已根据 DCO 的条款做出贡献并且有权这样做。 

Red Hat 在《开源参与指南》中表明了立场，其主导的项目不使用 CLA、版权转让或其他正式的贡献者协议，但鼓励使用 DCO。因为 CLA 机制可能是项目建立社区的重大障碍。  

支持还是反对？

业内对是否应该签署 CLA 一直存在争议。从体验上看，签署 DCO 过程更容易，几乎是一边倒地支持 DCO 。 

DCO 的条款只有 4 条，措辞简单，易于理解，有且只有一个标准，而且它也不需要把文件打印下来才能签署，开发人员通过“git commit”添加“-s”选项添加签名即可。 

DCO 签署方式

CLA 可自由制定，每个项目的 CLA 几乎各不相同，条款的复杂性会让大部分人跳过阅读直接签署，从而很容易让贡献者承担法律风险。 

Richard Fontana 是红帽公司法律部门产品和技术团队的高级商业顾问，他认为，开源开发的特点是无障碍（frictionless）贡献，这可以通过“入站 = 出站”来实现，然而 CLA 否定了无障碍贡献。在贡献被接受之前，签署不寻常的法律协议会造成官僚主义障碍，从而减缓发展并阻碍参与。 

有的 CLA 要求贡献者提交详细的个人信息，比如公司名称、公司邮件、电话等等，这被认为会泄露隐私。 

此外，CLA 通常只需签署一次，但每次提交 PR 仍然必须签名，与 CLA 管理库进行比对，否则贡献将不被接受。如果贡献者很多，管理 CLA 本身也需要人工成本。 

从法律的角度来看，双方则各执一词。 

GitHub 安全主管 Ben Balter 反对将 CLA 添加到开源项目。他认为，CLA 将版权侵权、专利侵权，以及其他故意或不良行为的法律风险转移到最缺乏防御能力的贡献者身上。“贡献者通常是个人。如果他们是学生或业余爱好者，他们可能没有（或负担不起）律师，并且不太可能接受知识产权最佳实践方面的广泛培训。”贡献者处于最不利的谈判位置，并且经常自愿为项目的利益付出时间，签署 CLA 对他们很不公平。 

律师 Kyle E. Mitchell 则认为 CLA 解决了真正的法律问题。“入站=出站”的方式是默示许可规则，在某些方面与合理使用规则一样不利，甚至更不明确。而 CLA 可以避免这种不确定性。 

 Kyle E. Mitchell 描述 DCO、CLA、许可证之间的关系 

虽然个人贡献者许可协议（ICLA）遭到诸多反对，但企业贡献者许可协议（CCLA）却获得了更多认可。一是企业有专门的法务人员，解读 CLA 条款并不会太难；二是企业介入，可以解决一个常见的问题——个人贡献者与雇主的知识产权协议冲突，无法自行签署 CLA。这也避免了 Ben Balter 所说的约定双方能力不对等的情况出现。 

对于 CCLA ，也有不同的声音，《大教堂与集市》的作者 ESR 就认为它发挥不了太大的作用。“没有任何 CCLA 的起草方式使其不可撤销，因为公司法律顾问会避免对任何关系做出极端的承诺，这是他们的工作。因此，想要叛逃的公司可以找到取消 CCLA 的方法。” 

如何获得贡献者信任？

在 Elasticsearch 更换许可证之后，自由和开源软件（FLOSS）维护者 Drew DeVault 表态不会为要求签署 CLA 的项目做出贡献。“原则上，CLA 旨在解决所有权和版权的合法问题，但在实践中，它表达的是，有一天代码库的管理员将接受您的工作，并在非自由许可下重新许可。最终，这正是 Elastic 所做的，也正是大多数其他要求您签署 CLA 的项目计划做的。” 

软件自由协会（SFC）创始人之一 Bradley Kuhn 一针见血地指出：“通常，CLA 将企业实体——非营利慈善机构、贸易协会（如 OpenStack Foundation）或营利性公司，指定为其最终受益人。在极少数情况下，CLA 的受益人是单个开发人员。” 

作为 Audacity 早期的贡献者之一，Shane Mueller 签署了CLA，把版权分配给了 Muse Group。即使他知道，这将使企业可以根据需要制作专有版本。 

他认为，Audacity 的志愿者团队很小，如果几个主要贡献者退出项目或退休，Audacity 会真正结束。它现在需要一个可持续的组织来管理发展，基金会是最好的方式，但 Audacity 没有足够的资金。而 Muse Group 提出了合理的可持续模型，即使未来企业管理不善，社区也可以进行分叉。 

 Shane Mueller 讲述签署 CLA 的原因

贡献者与维护者的关系并不总是剑拔弩张，在不得不集中版权的情况下，企业或组织会采取温和或者折中的方式，尽可能地实现无障碍贡献，获得开发者信任。 

今年 9 月，Aqua 通过简化 CLA、引入企业 CLA 来解决一些问题。比如在某些情况下，CLA 的特定条款使得贡献变得更加困难；前 CLA 对公司不友好，尤其是一些保护员工知识产权的公司，它们的开发人员很难做出贡献。 

FSF 鼓励贡献者转让版权的同时，做出了承诺，永远不会让他们的软件成为专有软件，始终在自由软件许可下发布其软件版本。这被认为是获取开发者信任的有效方式。近期，SixtyFPS 有意要效仿 FSF 的做法，计划在 CLA 中加入“义务”的相关条款，承诺在经 OSI 批准的开源许可下，继续开发该软件。