Contributor License Agreement 浅析

什么是CLA,CLA的主要作用

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

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

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

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

<1> 代码相关部分

◆ 签署 CLA 是要求贡献者声明对贡献内容(不仅限于代码,文档等其它内容一样有效)拥有所有权,或者是贡献者得到了相关的授权可以贡献这些内容。

◆ 贡献者卷提交的内容是在该开源项目选定的开源协议下进行,贡献的内容也遵循该项目的开源协议。

<2> 专利相关部分

◆ 签署 CLA 是要求贡献者声明如果贡献中包含了专利,该贡献者拥有该专利的所有权,或者得到相应的授权可以贡献该专利。

◆ 签署 CLA 等于贡献者授权开源项目以及开源项目的用户能够使用这个专利

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

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

所以,针对对 CLA 进行一个简要的总结:

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

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

  • CLA 签署一般是在贡献前签署,签署一次后后续贡献就不用再签署;DCO 是需要在每次提交代码时签署。如果使用 git 作为版本管理工具,在签署时添加 -s 参数可自动完成签署,签署后会在 Git Message 的尾部添加 Signed-off-by: Random J Developer <random@developer.example.org> 的内容,姓名和密码来自于 Git 的 Config 文件。
  • 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 也存在一些负面的看法:

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

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

附录

• DCO 的文本内容:

◆ Developer Certificate of Origin Version 1.1

◆ Copyright (C) 2004, 2006 The Linux Foundation and its contributors.

◆ Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

◆ Developer’s Certificate of Origin 1.1

◆ By making a contribution to this project, I certify that:

◆ (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

◆ (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

◆ (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

◆ (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

开源社区运营指标的设计探索

前言
开源社区的运营过程,是扩大开源项目用户群体和开发者群体的过程。如何确定开发者群体的变化、如何确定贡献者转化比率是我们一直希望从数字化运营中获取的关键的信息。本文根据 openEuler 运营的实战经验,设计了对于开源社区贡献者的分层定义,希望通过数据维度为社区的健康状况提供一个新的维度可供观测。
介绍 – 漏斗模型

运营视角通常依据对开源项目的贡献程度,对代码托管平台 ( github.com 或 gitee.com )在项目上留下数字足迹的开发者进行划分,对不同的开发者实施不同的运营策略。由于操作系统开源社区的特殊性,在 openEuler 项目的实践过程中,发现从 openEuler 官网的开发者、操作系统下载安装的开发者、日常进行软件包更新的开发者在以上操作过程中不需要账号,无法进行身份的确认造成无法进行追踪,在运营过程中针对这部分开发者都只进行数据统计。所以 openEuler 社区的开发者目前限定指在代码托管平台和 openEuler 代码仓库进行过交互的开发者,即已经进入代码仓库触达的开发者。

实际运营过程中,openEuler 社区将开发者分为三个层级:

  1. 代码贡献者(D2):狭义贡献者,合入了 PR(Pull Request) 的开发者
  2. 贡献者 (D1):  广义贡献者,合入 PR(Pull Request)、提交 Issue 或者评论 issue 或者PR 的开发者
  3. 开发者 (D0):  触达贡献者,合入 PR(Pull Request)、提交 Issue 或者评论 issue 或者PR ,以及针对代码仓库进行过 Star、Watch、或 Fork 的开发者

根据以上分类,三个层级的开发者从 D0 到 D2 之间形成了包含关系,因此形成了漏斗模型

展现 – 直观

在运营后台为了更好的展现不同层级开发者的转换以及活跃情况等,可以参考如下展示方式:

  • 标准漏斗图实现,展示每层开发者之间的转化率
  • 按照时间分布展示时间序列上每个层级的开发者活跃人数
  • 按照组织分布展示每个组织投入的人数

 image

组织

应用 – 面向开发者运营

在社区中每个参与的开发者都是活生生的个体而不是平台或者 KPI 中的一个冰冷的数字,有一些开源社区运营的同学痴迷数字化的运营,忽略了开发者的个性。每个开发者都是运营人员的客户,需要用服务的心态去对待每个开发者的诉求,面向开发者运营而不是 KPI 运营。

根据漏斗模型建议采取差别的运营策略:

  1. 代码贡献者(D2):关注开发者的社区成长路径和职业路径,培养成为项目的 Maintainer 或 Evangelist – 培养开发者对社区的忠诚度
  2. 贡献者 (D1):  关注开发者对项目功能的诉求,协助开发者将项目运用在实际生产中;解决开发者在项目技术路线和使用过程中和社区的沟通 – 提升开发者对社区的信任度
  3. 开发者 (D0):  属于项目的关注者,运营重点在于将项目的技术特点、落地案例等关键信息对 D0 开发者进行传播,吸引其对项目进行深度试用 – 抓住开发者对社区的关注度

同时也可以根据漏斗模型的数据结合其它运营数据观察到社区的变化

  1. 开发者在开源项目中参与周期的变化,开源项目的开发者并不是稳定的,更像是“铁打的营盘流水的兵”- 新贡献者从何而来、核心贡献者流失何方,更是运营者对社区状况的变化
  2. 观察社区深层次的文化和利益冲突是否会导致开源社区内的角色发生变化,何种特质的开发者更容易成长为社区的中坚力量 – 关键开发者的识别,是运营者提升运营效率的关键
总结

开源社区的运营需要完整的数据支持,如何在大量数据面前梳理出开发者这个关键模型,提升运营效率是 openEuler 一直在深入探索的。然而任何模型都是要符合开源项目本身的技术特点和生命周期,希望此模型对其它开源项目的运营有一定的参考意义。

注:
  1. D0D1D2 为简写,全称应为:Developer Level ZeroDevelop Level OneDeveloper Level Two