第 4 小节：为自己的开源项目建立贡献准则

什么是贡献者协议

启动自己的开源项目后，除了为项目选择一个合适的开源许可证（License），一份规范的贡献者协议通常也是不可或缺的。事实上，几乎所有大型的开源项目，诸如 Apache、Kubernetes 等，都要求在提交 PR 前签署贡献者协议。

你可能会问，License 不够用吗？为什么还要加一个贡献者协议呢？这就得从著作权说起了。

从原理上说，软件开源开放的是软件的使用权，而非著作权（版权）。开源许可证指明了用户在某些限制下使用软件及其源代码，如果用户违反了开源许可证，最终依然要回归到著作权的法律框架下解决争端。

那么著作权是怎么来的呢？根据《著作权法》的规定，著作权是作品完成时自然产生的，归作品的作者所有。对于大多数开源项目来说，著作权并不属于单一的人或实体，而是所有贡献者都有一份。可以想象，如果发生开源软件侵权，著作权的分散将给维权带来很多麻烦。另外，假如项目所有者想要更换或调整开源许可证，会因为并不持有全部的著作权受到阻碍，还可能由于著作权的原因与贡献者产生潜在的争议。

贡献者协议就是为了解决这些问题而生的：

  1. 将代码的版权统一授予项目所有者，方便项目的管理和维权。

  2. 提供保证和免责声明，避免潜在的法律风险。

    设想这样一种场景，Alice 为项目贡献了实际为 Bob 所有的代码，并且未获得 Bob 的授权，但 Alice 在提交代码前签署了贡献者协议，保证代码来自于个人原创，此时法律责任完全由 Alice 承担。

具体到形式上，贡献者协议又可以分为 CLA 和 DCO，两者在不同场景下各有优劣。

CLA vs DCO

CLA

CLA，全称 Contributor License Agreement（贡献者许可协议），简单来说就是项目接收贡献者提交的 PR 之前，需要贡献者签署的一份协议，协议只需签署一次，对该贡献者的所有提交都生效。

CLA 由项目所有方自行定义，在细节上有大大小小的差异，没有统一的标准，但大致包括以下内容：

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

有些项目的 CLA 会相对宽松，例如 Apache 基金会的 CLA 允许贡献者持有著作权，只要求授予项目方分发展示复制等权利。

DCO

DCO，全称 Developer Certificate of Origin（开发者原创证书），最初是在 Linux Kernel 项目中引入的，由 Linux 基金会于 2004 年制定。

相比于 CLA，DCO 是一种更轻量化的机制，它最大的优点是标准化，不要求开发者阅读冗长的法律条文，只需在提交的时候签署邮件地址即可。DCO 被很好地集成在了 Kernel 的版本控制软件 Git 里，因此只要在 git commit 的时候添加 -s 选项，Signed-off-by 就能很简单地添加到 commit log 中。

DCO 目前最新版本是 1.1，内容如下：

  1. 该贡献全部或部分由我创建，我有权根据文件中指明的开源许可提交；或者：
  2. 该贡献是基于以前的工作，这些工作基于适当的开源许可，无论这些工作全部还是部分由我完成，我有权根据相同的开源许可证（除非我被允许根据不同的许可证提交）提交修改后的工作；或者：
  3. 该贡献由 1、2 或 3 认证的其他人直接提供给我，而我没有对其进行修改。
  4. 我理解并同意该项目和贡献是公开的，并且该贡献的记录（包括我随之提交的所有个人信息，包括我的签字）将无限期保留，并且可以与本项目或涉及的开源许可保持一致或者重新分配。

协议的核心在于「原创性确认」，也就是让补丁的提交者确认提交内容是自己创作或者经过别人授权的，并且充分了解项目方会如何使用自己的代码。

正是由于 DCO 保留了 CLA 中的核心免责信息，并且具有轻量化特点，越来越多的开源项目，比如 Chef 和 GitLab 选择从 CLA 切换到了 DCO。

对比

两种协议的对比如下：

属性 CLA DCO
签署方式 一次性签署 每次提交时追加 Signed-off-by 信息
法律责任 明确法律义务 无声明，用来限制提交者遵守开源 LICENSE
自定义 公司或组织可自行定义 不可自定义，内容固定
社区属性 弱 强
公司属性 强，可签署公司级别的 CLA 弱
使用案例 Google、CNCF、Alibaba、openEuler、Apache SkyWalking GitLab、Chef

说了这么多，究竟应该选择 CLA 还是 DCO 呢？这取决于项目本身和社区的需求，通常来说：

  • 如果你想尽量减少对开发者贡献代码的阻碍，看重社区内的自由合作，那么 DCO 更合适。
  • 如果你的开源项目可能有公司间的合作或者要贡献给基金会，注重防范法律风险，那么使用 CLA 更加合适。

编写自己的 CLA

下面以 RT-Thread 社区 CLA 为例，介绍如何编写一份规范的 CLA，如果没有特殊的需求，读者也可以直接照搬。

开头首先明确 CLA 的生效条件和作用范围：

通过签署贡献协议（「本协议」），签署的「贡献者」同意接受「本协议」并受「本协议」约束。「本协议」适用于「贡献者」提交给 xxx 社区（「社区」）的全部项目（后称「项目」）的「贡献」，无论「贡献」是在签署日期之前，签署时还是之后提供。

接下来对协议中用到的名词进行准确定义：

「贡献」 是指受版权法保护的，由「贡献者」有意「提交」以包含在「项目」所分发软件中任何作品。「提交」是指以电子，口头或书面交流的任何形式送给「社区」管理方或其代表，包括但不限于「社区」管理方为管理的为讨论和改进项目所提供的电子邮件列表上的交流，源代码控制系统以及由「社区」管理方或其代表管理的问题跟踪系统，但不包括由「我」明确标记或以书面形式指定为「非贡献」的交流。

「贡献者」或「我」 是指下面签名栏中标明的个人或法人实体。对于法人实体，做出「贡献」的实体以及由该实体控制、受其控制或受其共同控制的所有其他实体均被视为「贡献者」。就本定义而言，「控制」是指有受控方或共同受控方至少 50% 直接或间接的投票权，资金或其他有价证券。

核心部分是贡献者对社区授予版权和专利许可：

「贡献者」授予「社区」管理方和由「项目」所分发的软件的每个接收者一个永久性的、全球性的、免费的、非独占的、不可撤销的、有分许可权的版权许可，供其复制、使用、修改、分发其「贡献」，不论修改与否。

「贡献者」授予「社区」管理方和由「项目」所分发的软件的每个接收者一个永久性的、全球性的、免费的、非独占的、不可撤销的、有分许可权的专利许可，供其制造、委托制造、使用、许诺销售、销售、进口其「贡献」或以其他方式转移其「贡献」。前述专利许可仅限于「贡献者」现在或将来拥有或控制的其「贡献」本身或其「贡献」与「提交」「贡献」时所针对的「项目」软件的结合而将必然会侵犯的专利权利要求，不包括仅因「贡献者」之外的人修改「贡献」或其他结合而将必然会侵犯到的专利权利要求。如由「项目」所分发的软件实际采用的许可证对软件接收者的专利授权有进一步限制规定的，如限制接收者对「贡献」或前述软件发起专利诉讼或其他维权等，则对前述软件接收者的专利授权以具体项目许可证的对应规定为准。

最后是贡献者的保证和免责声明：

「贡献者」保证「我」是「贡献」的版权所有者，或者「我」经版权所有者授权进行「贡献」，并且「我」在法律上授予「本协议」规定的权利。

「贡献者」保证「我」不知晓「我」的任何「贡献」已经侵犯或将侵犯任何第三方的版权，商标，专利或其他知识产权。

除「本协议」明确约定外，「贡献者」的「贡献」在提供时不带任何明示或默示的担保，「贡献者」或版权所有者不对任何人因使用「项目」所分发的软件或其中的「贡献」而引发的任何直接或间接损失承担责任，不论因何种原因导致或者基于何种法律理论，即使其曾被建议有此种损失的可能性。

到此为止，一份完整的 CLA 就大功告成啦，通常协议下方还会有表单用于收集贡献者的姓名和邮箱，以便在提交 PR 时检查贡献者是否签署了 CLA。

很多 FOSS 项目（Free and Open-Source Software）在开始时并没有要求贡献者签署 CLA，但伴随着项目参与者越来越多，会有签署 CLA 以及更改 License 的需求，此时可能面临一些困难，例如无法找到过去的贡献者重新签署 CLA。为了避免被起诉的风险，通常会采用两种策略：

  1. 重写受影响的部分代码，适用于受影响代码较少的情形。
  2. 保持现有的状态直到所有贡献者签署 CLA，适用于受影响代码较多的情形。

所以如果你已经决定要开源自己的代码，并且想要把它做成一个参与者众的大型项目，建议提前考虑好是否要添加贡献者协议，因为越晚考虑的成本可能会越高。

题外话：CLA 面面观

虽然 CLA 在开源软件中得到了广泛运用，但关于它的争议一直没有停歇过。

反对者认为 CLA 与开源运动的初衷相违背，多数情况下签署 CLA 即意味着放弃自己劳动成果的版权（或者说著作权），一旦版权转移给了项目方，项目方就有权在未来更换其他更严格的许可证，甚至直接将项目闭源，这显然是贡献者不愿意看到的。

除此以外，CLA 的非标准性可能导致贡献者和项目方处于地位不对等的状态，贡献者需要在参与每个项目时都仔细检查一遍条款，以避免自己的劳动成果被恶意利用，事实上在繁琐的协议条文面前，拥有成熟法务团队的大公司总是处于主导地位，这与尽可能降低门槛、崇尚自由合作的开源精神不符。

当然也不乏支持 CLA 的声音，理由之一是，CLA 的存在是一种应对法务风险的防御机制，很多大型企业基于开源软件构建产品并对客户提供服务，如果有开源社区的贡献者起诉他们侵犯专利或版权，败诉不仅意味着巨额的赔偿，还可能导致业务中断损失客户。

CLA 让更多大型企业和组织愿意参与开源社区并成为其中的中坚力量，企业在构建产品的过程中反哺开源社区，提高开源软件的代码质量，可以说没有大型企业和组织，也就没有丰富和高质量的开源软件生态，从这点上来说，CLA 也是一种「存在即合理」。

对此，你怎么看呢？

参考链接

https://en.wikipedia.org/wiki/Contributor_License_Agreement

https://jimmysong.io/blog/open-source-cla/

https://github.com/kubernetes/community/issues/2649

https://opensource.com/article/18/3/cla-vs-dco-whats-difference

http://opensource.guide/zh-hans/

https://www.finnegan.com/en/insights/articles/what-you-should-know-about-contributor-license-agreements-in-open-source-projects.html

https://opensource.stackexchange.com/questions/666/what-can-you-do-if-you-cant-track-down-all-old-contributors-to-sign-a-cla?rq=1

https://opensource.com/article/19/2/cla-problems

https://www.rt-thread.org/cla/

http://disksing.com/cla-and-dco/

本部分内容贡献者

nettingsisyphus、雪山凌狐、ORH、taotieren