开源项目的贡献者协议如何设计

本文目录导读：

1. 核心理念：保持简单和友好
2. 选择协议类型：DCO vs. CLA
3. 核心条款设计（以 CLA 为例）
4. 操作流程设计
5. 最佳实践与避坑指南
6. 一个简单的 CLA 模板（基于 Apache 2.0 许可）
7. 快速决策表

设计开源项目的贡献者协议（Contributor Agreement）需要平衡项目法律合规性与贡献者体验，一个设计不当的协议（如过于复杂的 CLA 或过于严苛的版权转让）可能会劝退潜在的贡献者。

以下是一份设计开源项目贡献者协议（通常包括 CLA 或 DCO）的完整指南，分为核心理念、协议类型、核心条款设计、操作流程和最佳实践五个部分。

核心理念：保持简单和友好

1. 降低门槛：协议应尽可能短、易懂，鼓励使用开发者原创证书（DCO，Developer Certificate of Origin） 而非复杂的 CLA。
2. 明确授权：清晰说明贡献者授予项目哪些权利，以及项目（尤其是维护者）可以用这些代码做什么。
3. 保护贡献者：贡献者不应因此承担额外责任（如专利诉讼风险）。
4. 合规性：确保项目可以重新许可（从 GPL 迁移到 MIT，或进行商业化）。

选择协议类型：DCO vs. CLA

这是最关键的选择。

DCO（Developer Certificate of Origin，推荐首选）

• 原理：贡献者只需在提交信息中添加 Signed-off-by: Your Name <email>，这表示贡献者同意 DCO 声明（即保证自己有权提交此代码，且同意项目按现有许可证使用）。
• 优点：
  • 极其简单,几乎零摩擦。
  • 被 Linux 内核、Git 等大型项目广泛采用。
  • 不涉及法律文件签署。
• 适用场景：几乎所有纯开源项目，尤其是不希望吓跑贡献者的项目。

CLA（Contributor License Agreement，需要签署）

• 原理：贡献者需要签署一份正式的法律文件（通常通过在线系统，如 CLA Assistant 或 EasyCLA）。
• 类型：
  • 版权转让（Copyright Assignment）：贡献者将代码版权 完全转让 给项目或公司（如 Fiduciary License Agreement）。不推荐,对贡献者不友好。
  • 版权许可（Copyright License）：贡献者保留版权，但授予项目/公司 广泛的、永久的、不可撤销的许可（包括商业使用、再许可）。更常见。
• 优点：
  • 保护项目免受专利诉讼、代码来源不明等法律风险。
  • 允许项目（尤其是公司主导的项目）在未来更改许可证（如从 GPL 改为商业许可证）。
  • 明确知识产权的归属和授权范围。
• 适用场景：
  • 公司主导的大型项目（如 Google、Meta 的项目）。
  • 项目计划采用双许可证模式（开源 + 商业授权）。
  • 高风险领域（如涉及加密、医疗、金融的代码）。

核心条款设计（以 CLA 为例）

如果你决定使用 CLA,以下条款是必须认真设计的：

定义条款

• “贡献”：明确包含所有提交的代码、文档、补丁、提议等。
• “项目”：指代的开源项目本身。

许可授予（核心）

这是 CLA 的心脏。

• 版权许可：

  • 授予项目（及维护者）一个 永久的、全球性的、免版税的、非排他的、不可撤销的 许可。
  • 允许项目使用、复制、修改、展示、分发和制作衍生作品。
  • 允许再许可（Sublicense）：这一点很关键，允许项目以不同的许可证条款（如商业许可证）使用你的贡献。
  • 明确不限制贡献者：声明此许可不影响贡献者自己继续使用或单独授权其贡献的权利。

• 专利许可（Patent Grant）：

  • 如果贡献者持有相关专利，应授予项目一个 对因使用贡献而可能被侵犯的专利的许可。
  • 保护伞条款：如果贡献者向项目（或项目用户）提起专利诉讼，则自动撤销此专利许可，这是防止“专利流氓”或“潜水艇专利”的标准做法。

代表与保证

• 所有权保证：贡献者保证其贡献是原创的,或者有权代表其雇主提交。
• 第三方权利：贡献者保证其贡献不侵犯任何第三方的版权、专利或商业秘密（即不抄袭）。
• 安全性：贡献者承诺其代码不包含恶意软件或后门。
• 免责：贡献者明确声明 “按现状”提交，不提供任何形式的明示或默示保证（如适销性或适用性）。

责任限制

• 贡献者不对因使用或分发其贡献而产生的任何损害承担责任。

签署方式

• 个人签署：需明确是个人身份提交。
• 雇主签署（Corporate CLA）：如果贡献者在工作时间内为公司提交代码，通常需要公司实体签署一份 Corporate CLA，然后个人贡献者通过个人 CLA 声明自己有权限提交,这避免了公司内部律师的繁琐流程。

操作流程设计

1. 包含 DCO（最简单）：

   • 在 CONTRIBUTING.md 中说明：“所有提交必须通过 -s 或 --signoff 选项进行签名。”
   • 使用 Git钩子或 CI（持续集成）工具（如 DCO Bot）自动检查提交信息是否包含 Signed-off-by。

2. 实施 CLA（推荐工具）：

   • CLA Assistant：一个 GitHub/GitLab App，能自动检查 PR（Pull Request）贡献者是否已签署 CLA，未签署则阻止合并,提供可定制的模板。
   • EasyCLA (Linux Foundation)：适合大型企业级项目。
   • 流程：
     1. 贡献者提交 PR。
     2. CI（持续集成）/ Bot 提示“需要签署CLA”。
     3. 点击链接，跳转到 CLA 签署页面（支持个人和公司签署）。
     4. 签署后，Bot 更新 PR 状态为“CLA 已签署”。
     5. 项目维护者可以合并。

最佳实践与避坑指南

1. 开源社区 vs. 法律保护的平衡：

   • 不友好：要求全球客服贡献者手动填写 PDF 并发送邮件。友好：使用 DCO 或在线点击式 CLA 工具。
   • 过分：要求版权完全转让（即贡献者以后不再拥有自己的代码）。合理：仅要求非排他性免版税许可。

2. 模板建议：

   • DCO：直接使用 Linux Foundation 的 DCO 文本。
   • CLA：建议参考 Apache ICLA（个人贡献者许可协议，Individual Contributor License Agreement） 或 Google CLA（它们经过了大量实践检验）。
     • 开源： Apache CLA 是黄金标准,适合绝大多数开源项目。
     • 商业友好： 如果需要双许可证，可以考虑修改 Hart 的模板。

3. 公司背景项目：

   • 必须设计 Corporate CLA，让公司而不是每个员工签署，否则员工离职后,原公司可能声称拥有代码版权。

4. 避免“继承性”问题：

   • CLA 中关于“派生作品”的授权要清晰，好的 CLA 允许项目将贡献的代码许可给其他人，无论他们是否也签署了 CLA（即：项目的最终用户无需签署 CLA 就能使用开源版本）。

5. 常见错误：

   • CLA 与项目实际许可证冲突（如CLA说代码可商用，但项目是AGPL（Affero GPL，更强的 Copyleft 协议，要求网络服务也开源））。
   • CLA 语言过于晦涩（法律术语过多）。
   • 没有处理贡献者的专利反诉问题（前文提到的“如果起诉则撤销授权”）。

一个简单的 CLA 模板（基于 Apache 2.0 许可）

你可以基于这个结构起草：

贡献者许可协议（CLA）
前言：
本协议（“协议”）由________________（“贡献者”）与________________（“项目”）签订。
1. 定义
   “贡献”指由贡献者有意提交给项目以包含在项目中的所有代码、文档或其他原创作品。
2. 版权许可授予
   贡献者授予项目一个永久的、全球性的、非排他性的、免版税的、不可撤销的版权许可，以复制、准备衍生作品、公开展示、公开表演、再许可和分发贡献及此类衍生作品。
3. 专利许可授予
   贡献者授予项目一个永久的、全球性的、非排他性的、免版税的、不可撤销的专利许可，基于其贡献，如果贡献者对项目或其用户提起专利侵权诉讼，则此许可自动终止。
4. 代表与保证
   贡献者保证：(a) 其是贡献的原创作者，或有权提交； (b) 贡献不侵犯第三方权利； (c) 其拥有授予本协议中权利所需的全部许可。
5. 免责声明
   贡献按“现状”提供，不附带任何明示或默示的保证。
6. 签署
   本协议通过电子方式确认。

快速决策表

最后建议：在最终确定前，请咨询熟悉开源法律的律师,本文档不构成法律建议。