Contributor License Agreement 浅析

什么是 CLA，CLA 的主要作用

在开源项目中通常存在三个角色围绕在整个项目的生命周期，在他们之间使用不同的协议约束之间的关系。

  1. 所有者 开源项目所有者的角色比较复杂，有可能是一个独立开发者个体，也可能是多个开发者组成的小团体或是一家商业公司。他们共同的特点是对这个开源项目具有控制权，拥有代码写入的权限和修改许可证的权利。
  2. 贡献者 是指所有者之外的向开源项目贡献代码的开发者。有些开发者向开源项目贡献代码是出于个人意愿或者兴趣，我们可以称呼他们为独立贡献者，这些具有贡献精神的独立开发者是值得大家敬佩的，也是各种开源项目去努力吸引的；也有很多开发者是受雇于公司为开源项目贡献代码，大多数情况是因为工作中使用了某些开源项目，出于工作的需要贡献代码进行 Bug 的修复和新增功能，也有一些公司是有全职的开源开发者，专职在项目中贡献代码，这是一份让人非常羡慕的工作。
  3. 用户 开源项目的用户是非常复杂的角色。用户可能是指使用在其它开源项目中使用这个开源项目的开发者，或是在商业项目开发中使用这个开源项目的开发者，也有可能是指使用这个开源项目开发的软件的用户，角色的切换随着场景在变化。

Open Source License，在中文中我们通常讲为开源许可证，是约束开源项目和用户之间的行为。开发者、用户或者是下游开源或商业项目是都有可能受开源项目的许可证约束，而且许可证的种类繁多，内容纷繁复杂，如果稍有不慎就会陷入法律纠纷的麻烦中。所以在目前开源合规方面的很多都是针对许可证合规的研究。

CLA 是 Contributor License Agreement 的缩写，一般翻译为贡献者许可协议，开发者向开源项目贡献的时候通常被要求需要签署 CLA 协议(或类似协议)。CLA 是约束开源项目和贡献者之间的关系，通常是要求贡献者在代码和专利做出声明或者承诺。CLA 的协议内容一般都不长，通常包含两个部分：

代码相关部分

  • 签署 CLA 是要求贡献者声明对贡献内容(不仅限于代码，文档等其它内容一样有效)拥有所有权，或者是贡献者得到了相关的授权可以贡献这些内容。
  • 贡献者卷提交的内容是在该开源项目选定的开源协议下进行，贡献的内容也遵循该项目的开源协议。

专利相关部分

  • 签署 CLA 是要求贡献者声明如果贡献中包含了专利，该贡献者拥有该专利的所有权，或者得到相应的授权可以贡献该专利。
  • 签署 CLA 等于贡献者授权开源项目以及开源项目的用户能够使用这个专利

CLA 对于开源项目的贡献者和用户也是一种保护，能够帮助开源项目避免不必要的诉讼和骚扰。

  • 贡献者签署 CLA 后是对贡献者的一种保护，签署 CLA 并不能改变捐献的代码和专利的所有权，只是授权的一种行为。
  • 因为开源项目使用了 CLA ，每一个贡献都在 CLA 的保护下，在出现侵权的诉讼时，用户或开源项目可以引用 CLA 作为自己免责的证据。

所以，针对对 CLA 进行一个简要的总结：

Contributor License Agreement 是一个轻量级的许可协议，签署人是代码(包含文档等其它内容)和专利的拥有者(或是被授权贡献)，授权这些贡献在项目的开源许可证下进行再分发。

CLA 和 DCO 之间的区别

DCO 的全称是 Developer Certificate of Origin ，是贡献者声明贡献内容所有权的轻量级协议，这里可以把 DCO 看做是更轻量级的 CLA 。CLA 和 DCO 的区别：

  1. CLA 签署一般是在贡献前签署，签署一次后后续贡献就不用再签署；DCO 是需要在每次提交代码时签署。如果使用 git 作为版本管理工具，在签署时添加 -s 参数可自动完成签署，签署后会在 Git Message 的尾部添加 Signed-off-by: Random J Developer random@developer.example.org 的内容，姓名和密码来自于 Git 的 Config 文件。
  2. CLA 通常包括一个管理系统，主要是为签署 CLA 的企业管理向开源项目贡献的员工。在管理系统中通常是通过贡献人的邮件地址或者 ID (版本管理服务的 ID，类似 Github.com ) 识别是否企业员工，通过集成到 PR (Pull Request) 来控制代码合入；企业员工更换工作内容或者离职后，企业可以通过管理系统取消其代表企业的贡献权限。openEuler 操作系统开源社区采用的 CLA 系统就是社区根据实际情况自研的，可以在 https://github.com/opensourceways/app-cla-server 获取到代码。

CLA 的签署过程可以看做是显示签署，CLA 的内容可以进行修改，通常大型企业主导的开源项目会使用 CLA 的模式，这样更容易地控制法律文本内容，降低诉讼产生的风险；目前 DCO 的内容主要是来自 https://developercertificate.org 中，在 Github 中使用 DCO 的应用检查是否含有 Signed-off-by 时默认认可 DCO 的内容，是隐式签署，企业也无法控制 DCO 的文本内容。

开源社区的一些正面和负面的看法

目前 Google 、Microsoft 、华为等大型企业的开源项目都使用了 CLA ，减少了针对开源项目的诉讼风险，利于开源项目的发展。但是社区对 CLA 也存在一些负面的看法：

  1. 签署 CLA 等于放弃了一些法律权利，但是羞涩的法律文本对于开发者来说都是不友好的，即使认真地阅读了 CLA 内容，也很难确定到底是要放弃什么样的权利。很多开发者在第一次贡献前，就可能因为要签署 CLA 而放弃了。
  2. 还有一些开发者认为 CLA 更多是为企业贡献者服务，对于个人开发者并不友好，并没有考虑到他们的感受和贡献的意愿；甚至有一些开发者认为这些签署 CLA 的项目并不是把开发者放到第一位考虑，而是先努力降低自己的风险。
  3. 最近几年几个著名的开源项目更改 License 协议，也带来了开发者对签署 CLA 的抱怨。有很多开发者认为开源项目没有权利更改 License 协议，或者是滥用了签署 CLA 赋予的权利。

总之，对于开源项目的所有者或背后实际控制的公司，都倾向于使用 CLA 的方式代替 DCO 来获取贡献者的授权，相信未来越来越多的开发者在参与开源社区贡献时，需要签署 CLA。