开源贡献协议

本文目录导读：

1. 为什么需要开源贡献协议？
2. 常见的几种开源贡献协议形式
3. 如何区分，如何参与？

开源贡献协议”，这是一个在参与开源项目时非常核心且容易引发困惑的概念，它通常指的并不是某个单一的法律文件，而是你作为贡献者，将你的代码、文档或其他贡献提交给开源项目时所依据的许可条款。

当你向一个开源项目提交 Pull Request (PR) 时，你需要同意项目的某个条款，授权项目维护者使用你的贡献，这个条款就是“开源贡献协议”。

下面我为你详细拆解一下常见的几种形式：

为什么需要开源贡献协议？

1. 明确版权与许可：你写的代码默认版权属于你，如果项目接收了你的代码但没有明确的许可，项目在后续使用、修改、再发布你的代码时可能面临法律风险（比如你突然声称“这是我的代码，你不能用它”）。
2. 确保项目许可的纯洁性：开源项目有自己的许可证（如 GPL, MIT, Apache 2.0），贡献协议能确保你同意你的贡献也遵循这个相同的许可证，从而保证整个项目的许可是一致的、可维护的。
3. 保护项目维护者：如果有人声称“这个贡献者提交的代码侵犯了我的版权”，维护者可以依据贡献协议证明该贡献者已授权并保证代码的原创性。

常见的几种开源贡献协议形式

隐式接受：贡献即同意（Inbound = Outbound）

这是最常见、最轻量级的方式，尤其适用于使用宽松许可证（如 MIT, Apache 2.0）的项目。

• 做法：项目在 README.md、CONTRIBUTING.md 或 LICENSE 文件中声明：“我们欢迎贡献，任何提交给本项目的代码、文档等贡献，都默认遵循本项目的开源许可证（如 MIT），通过提交贡献，你同意此条款。”
• 法律效果：你提交 PR 的行为，即被视为你已经同意将你的贡献按照项目的许可证（如 MIT）进行授权。
• 优缺点：
  • 优点：流程简单，无需签署额外文件，对贡献者友好。
  • 缺点：法律上的明确性稍弱，对于大型企业或需要非常严格法律合规的项目可能不够。

开发者原创证书

这是一种受 Debian 社区（GNU/Linux 发行版）和很多项目广泛采用的、非正式的、基于签名的协议。

• 做法：你在提交信息（Git commit message）中需要包含一个标准声明，

  Signed-off-by: Your Name <your.email@example.com>

  这个签名表示你宣誓你提交的代码是自己原创的,或来自一个兼容的开源许可证，并且你有权将其贡献给项目。

• ：DCO 包含一个简短的、法律上清晰的声明，主要承诺：
  • 贡献全部或部分（基于你）是你的原创作品。
  • 或者,你基于某个开源许可证（如 GPL、MIT）有权提交它。
  • 你授权项目可以按照项目的许可证（或其指定的其他许可证）使用你的贡献。
• 优缺点：
  • 优点：非常轻量级，无需任何账户或文件签署，只需一个 Signed-off-by 签名即可，被 Linux内核、Git 等项目广泛使用。
  • 缺点：需要贡献者理解并手动添加签名，可能有点繁琐。

贡献者许可协议

这是最正式、最强大的方式，由 Apache 软件基金会（ASF）、Google、Microsoft 等大型组织和公司主导的项目普遍采用。

• 做法：贡献者需要先在组织指定的网站（通常是提供法律服务的平台，如 Apache CLA, Harmony CLA 系统）上签署一份独立的法律文件。
• ：CLA 是一份详细的合同，定义了贡献者授予项目（通常以项目实体，如基金会或公司）的版权和专利许可，常见条款包括：
  • 版权许可授权：你授予项目及后续使用者一个永久的、不可撤销的、全球范围内的、免费的版权许可。
  • 专利许可授权：你授予项目及后续使用者一个对可能涉及的专利权利的许可（防止你未来用专利攻击项目）。
  • 保证原创性：你保证贡献是你的原创，或你有权提交。
  • 项目实体（如 Apache 软件基金会）的授权：有时贡献者授权给项目实体，然后项目实体再以自己的名义对外许可（如 Apache 2.0）。
• 优缺点：
  • 优点：法律上最完备、最清晰，能为项目和公司提供最强的保护，特别适合大型、有基金会管理、或涉及大量专利风险的项目。
  • 缺点：流程较重，需要贡献者（尤其是个人贡献者）注册、填写个人信息、等待审核，可能阻碍一些随意的贡献者，对企业法务部门来说是负担。

如何区分，如何参与？

当你想要为一个开源项目贡献代码时,建议你按以下步骤操作：

1. 查看项目根目录的文件：找找看是否有 CONTRIBUTING.md、CONTRIBUTING.rst 或 CLA.md 文件。
2. 查看项目网站：如果有官方网站，通常会有“Contributing”或“Governance”页面，里面会详细说明贡献协议要求。
3. 查看现有的 PR：看别人的 PR 里提交信息中有没有 Signed-off-by: 字样，或者有没有指向某个 CLA 签署页面的链接。

常见情况总结：

• 小型/个人项目：通常是“隐式接受”或“DCO”。
• 中型/社区型项目（如 Vue.js, React Native）：通常是 DCO（要求 Signed-off-by），但流程自动化（如通过 bot 检查）。
• 大型/基金会项目（如 Apache 项目，如 Spark、Flink；或 CNCF 项目，如 Kubernetes）：通常要求签署 CLA（可能是个人或公司 CLA）。
• 公司主导的开源项目（如 Google 的 Angular、Microsoft 的 VS Code）：通常要求签署 CLA（通常是个人或公司 CLA，且流程高度自动化，如通过 GitHub App 或网页授权）。

开源贡献协议是你向开源项目贡献代码时必须遵守的“入场券”，它确保了你的贡献能被项目合法地使用、分发，并保护了项目的长期健康发展。

• 对贡献者：了解它，遵守它，避免法律风险。
• 对项目维护者：清晰地在项目文档中说明贡献协议，并尽量选择对贡献者友好（如 DCO）的方式。

希望这个解释对你有帮助！如果你有具体想贡献的项目（如 react、kubernetes 等），可以具体查阅该项目的 CONTRIBUTING.md 文件。