本文目录导读：
这是一个非常经典且重要的开源法律问题。开源项目的代码合并后，版权（著作权）仍然归原作者所有，但项目整体会基于其采用的许可证（License）进行授权。
具体归属和权利界定,取决于以下几个关键因素：
核心原则：版权不因合并而转移
- 作者保留版权：每一位贡献者（提交代码的人）对其贡献的代码片段、文件或修改，自动享有著作权，除非贡献者通过明确的书面协议（如贡献者许可协议，CLA）将其版权转让给项目或某个组织（如Apache基金会、Linux基金会）,否则版权始终属于原贡献者。
- 项目拥有“整体”版权：项目作为一个整体（例如一个软件的发布版本、一个仓库的代码库），其版权通常属于项目维护者或项目所有者（如开源基金会），但这并不意味着他们拥有所有代码的版权，而是指他们拥有对项目整体进行发布、管理和维权的权利。
关键影响因素：开源许可证和贡献协议
开源许可证：项目的“宪法”
许可证决定了代码如何被使用、修改和分发，贡献者提交代码,即默认同意其贡献的代码遵循该项目所采用的许可证。
- 弱/强互惠许可证（如 GPL、AGPL、LGPL）：要求衍生作品（即包含该代码的整个程序）也必须使用相同或兼容的许可证,贡献者的版权受到项目整体许可证的约束。
- 宽松许可证（如 MIT、Apache 2.0、BSD）：允许其他人（包括商业公司）几乎无条件地使用、修改和分发代码，甚至可以在闭源产品中使用，贡献者的版权依然存在,但通过许可证授予了广泛的使用权。
- 版权共享（Copyleft）与允许性（Permissive）：在互惠许可证下，贡献者贡献的代码会促使更多的代码也以同样的方式共享，形成“共享与延续”的生态，而在宽松许可证下，贡献者的代码可能被用于闭源项目,贡献者对此没有控制权。
贡献者许可协议：可选的“权利集中”
许多大型成熟的开源项目（如Kubernetes、TensorFlow、Linux Kernel、React）会要求贡献者签署CLA。
- 版权加许可协议：贡献者明确将贡献代码的版权（或使用权、专利许可等）授予项目维护者（或基金会）。
- 转让版权：某些CLA（特别是基金会的标准协议）会要求贡献者将版权转让给项目实体，Apache软件基金会或Eclipse基金会要求贡献者签署协议，将代码的版权转让给基金会，这样，基金会就拥有项目所有代码的版权，可以统一处理许可证、维权和商业授权问题。
- 保留版权但授予许可：更常见的是，贡献者保留版权，但通过CLA授予项目维护者一个不可撤销的、永久的、全球性的、免版税的版权许可，允许项目维护者以项目许可证的方式再分发、修改甚至重新许可（从GPL切换到MIT）。这种模式是主流，既保护了贡献者的署名权，又保证了项目维护的灵活性。
具体场景分析
| 场景 | 代码版权归属 | 项目整体版权 | 用户/项目维护者的权利 |
|---|---|---|---|
| 无CLA的宽松许可证项目（如使用MIT） | 每位贡献者保留 | 项目维护者拥有整体版权（如商标、项目名称），但代码版权分散。 | 任何用户都可以按照MIT许可证自由使用、修改、分发，维护者不能阻止任何人（包括商业公司）使用代码。 |
| 无CLA的GPL项目 | 每位贡献者保留 | 项目整体受GPL约束。 | 分发衍生作品（例如包含该代码的软件）时，必须开源并遵循GPL。 |
| 有CLA的项目（如Apache 2.0+CLA） | 贡献者保留，但通过CLA授予项目实体永久、不可撤销的许可。 | 项目实体（如Apache基金会）拥有对项目进行统一许可、变更许可证、处理侵权诉讼的完整权利。 | 用户按照项目的Apache许可证使用，项目实体可以决定更新许可证（例如从Apache 2.0切换到一个新的版本）。 |
| 贡献者转让版权的项目（如某些基金会项目早期） | 版权归属项目实体（如Linux基金会、Eclipse基金会）。 | 项目实体是唯一版权所有者。 | 项目实体可以完全控制项目，包括决定是否更变许可证、是否允许商业使用、是否进行法律诉讼。 |
常见陷阱与风险
- 许可证不兼容：如果你合并了一个使用不同许可证（尤其是互惠与宽松之间）的代码，可能会导致项目整体许可证被污染（将MIT代码合并入GPL项目，没有问题；但将GPL代码合并入MIT项目，会导致MIT项目违反GPL，必须整体改为GPL）。
- 专利风险：贡献者贡献代码的同时，也可能会使得其拥有的专利（尤其是标准必要专利）无法再向项目使用者主张,这也是CLA设计的重要目的之一。
- 署名争议：虽然贡献者的作者身份通常通过Git记录保留，但如果项目维护者在发布时没有正确列出所有贡献者，或者项目被重新发布时遗漏了作者信息,可能涉及署名权纠纷。
- 商业公司贡献：公司员工贡献代码时，版权通常属于其雇主（根据职务作品条款），如果公司没有明确的开源贡献政策,项目维护者可能需要与公司签署CLA。
总结与建议
-
对于个人贡献者：
- 你的代码版权永远是你的，你贡献时,默认授权项目使用。
- 如果项目要求你签署CLA，仔细阅读条款，特别是是否要求转让版权（强烈建议不要签，保留只会更好）,还是仅授予许可。
- 使用Git的Commit记录保留你的作者信息。
- 避免将GPL代码贡献给MIT项目。
-
对于项目维护者：
- 强烈建议： 如果你的项目想商业化、想被大公司采用、或者规模很大，制定并强制要求贡献者签署CLA。
- 声明项目使用的许可证（在仓库根目录下的
LICENSE文件中明确）。 - 明确你的版权归属声明（在
CONTRIBUTING.md或仓库README中说明）。 - 如果项目将来希望更改变量许可证（例如从MIT切换到Apache），你必须获得所有贡献者的同意（或通过CLA获得授权），没有CLA的旧项目,变更许可证极其困难。
一句话总结： 代码合并后，版权不转移（除非签署版权转让的CLA），贡献者仍拥有其贡献代码的版权，但项目整体受许可证约束。项目维护者通过许可证和CLA来管理整个项目的权利授予和法律风险。
