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

wen 开源项目 2026-07-17 1

本文目录导读：

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

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

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

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

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

降低门槛：协议应尽可能短、易懂，鼓励使用开发者原创证书（DCO，Developer Certificate of Origin） 而非复杂的 CLA。
明确授权：清晰说明贡献者授予项目哪些权利，以及项目（尤其是维护者）可以用这些代码做什么。
保护贡献者：贡献者不应因此承担额外责任（如专利诉讼风险）。
合规性：确保项目可以重新许可（从 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 声明自己有权限提交,这避免了公司内部律师的繁琐流程。

操作流程设计

包含 DCO（最简单）：
- 在 CONTRIBUTING.md 中说明：“所有提交必须通过 -s 或 --signoff 选项进行签名。”
- 使用 Git钩子或 CI（持续集成）工具（如 DCO Bot）自动检查提交信息是否包含 Signed-off-by。
实施 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. 项目维护者可以合并。

最佳实践与避坑指南

开源社区 vs. 法律保护的平衡：
- 不友好：要求全球客服贡献者手动填写 PDF 并发送邮件。友好：使用 DCO 或在线点击式 CLA 工具。
- 过分：要求版权完全转让（即贡献者以后不再拥有自己的代码）。合理：仅要求非排他性免版税许可。
模板建议：
- DCO：直接使用 Linux Foundation 的 DCO 文本。
- CLA：建议参考 Apache ICLA（个人贡献者许可协议，Individual Contributor License Agreement） 或 Google CLA（它们经过了大量实践检验）。
  - 开源： Apache CLA 是黄金标准,适合绝大多数开源项目。
  - 商业友好： 如果需要双许可证，可以考虑修改 Hart 的模板。
公司背景项目：
- 必须设计 Corporate CLA，让公司而不是每个员工签署，否则员工离职后,原公司可能声称拥有代码版权。
避免“继承性”问题：
- CLA 中关于“派生作品”的授权要清晰，好的 CLA 允许项目将贡献的代码许可给其他人，无论他们是否也签署了 CLA（即：项目的最终用户无需签署 CLA 就能使用开源版本）。
常见错误：
- CLA 与项目实际许可证冲突（如CLA说代码可商用，但项目是AGPL（Affero GPL，更强的 Copyleft 协议，要求网络服务也开源））。
- CLA 语言过于晦涩（法律术语过多）。
- 没有处理贡献者的专利反诉问题（前文提到的“如果起诉则撤销授权”）。

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

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

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

快速决策表

项目类型	推荐方案	原因
个人/小团队开源项目	DCO	零摩擦，低维护成本
中型社区项目（如 Vue, React 早期）	简单 CLA（非版权转让）	兼顾法律保护与友好度
大型公司主导项目（如 Go, CUDA）	严格的 CLA + 公司协议	确保商业灵活性，保护知识产权
旨在被大公司采用的项目	Corporate CLA	确保公司雇员合规贡献

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