在开源领域，很少有法律话题像贡献者许可协议 (CLA) 那样具有争议性。除非您将 Fedora 项目贡献者协议（我一直认为它*不是* CLA）视为特殊的历史案例，或者像 Karl Fogel 一样，将 DCO 归类为 CLA 的一种类型，否则今天红帽公司在其维护的项目中不使用 CLA。
并非一直如此。红帽公司最早的项目遵循我称之为“inbound=outbound”（入站=出站）的传统做法，即对项目的贡献只需在项目的开源许可下提供，无需执行外部的、非 FOSS 合同。但在 2000 年代初，红帽公司开始尝试使用贡献者协议。Fedora 开始要求贡献者签署基于广泛采用的 Apache ICLA 的 CLA，而从 Cygnus 和 JBoss 收购继承了自由软件基金会衍生的版权转让协议和一对定制的 CLA。我们甚至采取了一些步骤，以便在快速增长的红帽主导项目中采用 Apache 风格的 CLA。
这种情况结束了，很大程度上是因为我们红帽法律团队的人员听取并理解了红帽工程师和更广泛的技术社区提出的担忧和反对意见。我们继续成为一些人所说的反 CLA 运动的 фактические 领导者，这尤其体现在我们反对 Project Harmony 和我们努力让 OpenStack 用 DCO 替换其 CLA。（出于实际需要，我们不情愿地签署了可容忍的上游项目 CLA。）
为什么 CLA 有问题
我们选择不使用 CLA 反映了我们作为一家扎根于自由软件运动的真正开源公司的价值观。多年来，开源社区的许多人已经解释了为什么 CLA 以及非常相似的版权转让机制对于开源来说是一项糟糕的政策。
原因之一是繁文缛节问题。通常，开源开发的特点是无摩擦的贡献，这由 inbound=outbound 实现，无需进一步的法律仪式或流程。这使得新贡献者相对容易地参与到项目中，从而更有效地促进贡献者社区的增长并推动上游的技术创新。无摩擦的贡献是开源开发相对于专有替代方案的关键优势之一。但是，CLA 抵消了无摩擦的贡献。在接受贡献之前必须签署一份不寻常的法律协议，这会造成官僚障碍，减慢开发速度并阻碍参与。尽管使用 CLA 的项目越来越多地使用自动化，但这种成本仍然存在。
CLA 还会导致项目参与者之间法律权力的不对称，这也阻碍了围绕项目建立强大的贡献者和用户社区。对于 Apache 风格的 CLA，领导项目的公司或组织获得了其他贡献者未获得的特殊权利，而其他贡献者必须承担项目领导者免除的某些法律义务（除了繁文缛节负担）。不对称问题在 copyleft 项目中最严重，但即使出站许可证是宽松的，它仍然存在。
在评估支持和反对 CLA 的论点时，请记住，今天，就像过去一样，任何产品中的绝大多数开源代码都源于遵循 inbound=outbound 实践的项目。少数项目使用 CLA 会对所有其他项目造成附带损害，因为它表明，由于某种原因，开源许可不足以处理流入项目的贡献。
支持 CLA 的理由
由于 CLA 仍然是一种少数派实践，并且起源于开源社区文化之外，我认为 CLA 的支持者应该承担解释为什么它们相对于其成本是必要或有益的责任。我怀疑大多数使用 CLA 的公司只是在模仿同行公司的行为，而没有进行批判性审查。CLA 对规避风险的律师具有可以理解的（如果说是肤浅的）吸引力，他们倾向于偏爱更正式的形式、文件和流程，而不管业务成本如何。尽管如此，一些支持 CLA 的论点经常被提出，值得考虑。
轻松重新许可： 如果管理得当，Apache 风格的 CLA 赋予项目管理者有效且无限的权力，可以根据管理者选择的条款对贡献进行再许可。有时，这被认为是可取的，因为可能需要根据其他开源许可证重新许可项目。但是，轻松重新许可的价值被夸大了，因为只指出了一些历史案例，这些案例涉及由拥有异常大量过去贡献者的项目进行的重大重新许可活动（所有这些活动都在未使用 CLA 的情况下成功完成）。重新许可很难也有好处，因为它会为项目带来稳定的法律预期，并鼓励项目在进行重大的法律政策变更之前咨询其贡献者社区。在任何情况下，大多数 inbound=outbound 开源项目在其生命周期内从未尝试重新许可，而对于少数确实尝试重新许可的项目来说，重新许可将相对轻松，因为通常需要联系的过去贡献者的数量不会很大。
出处跟踪： 有时声称 CLA 使项目能够严格跟踪贡献的出处，据称这具有一定的法律益处。尚不清楚在这种情况下，使用 CLA 实现的好处是否优于通过非 CLA 手段（例如保留 Git 提交历史记录）更好地处理的好处。DCO 似乎更适合跟踪贡献，因为它通常在每次提交的基础上使用，而 CLA 则在每个贡献者签署一次，并且在管理上与代码贡献是分开的。此外，出处跟踪经常被描述为对公众有利，但我不知道有哪个项目提供透明的、随时可供公众访问的 CLA 接受记录。
许可撤销： 一些 CLA 倡导者警告说，贡献者将来可能会试图撤销过去的许可授予。如果关注点主要是关于没有公司关系的、基本上不受判决约束的个人贡献者，那么与使用开源许可证相比，Apache 风格的 CLA 是否能更有效地防止这种情况发生尚不清楚。而且，与许多在开源法律政策讨论中提出的法律风险一样，这似乎是一种虚幻的风险。多年来，我只听说过少数所谓的许可撤销尝试，所有这些尝试都在贡献者在社区压力下退缩后迅速得到解决。
未经授权的员工贡献： 这是许可撤销问题的一个特例，并且最近已成为 CLA 倡导者普遍提出的一个问题。当员工向上游项目做出贡献时，通常雇主拥有该项目需要的版权和专利，并且只有某些高管被授权授予此类许可。假设一名员工在未经雇主批准的情况下向项目贡献了专有代码，并且雇主后来发现了这一点，并要求删除贡献或起诉项目的用户。通过使用类似 Apache CCLA 及其声明和签名要求，再加上一些充分的审查流程来确定 CCLA 签署者可能被授权签署（我怀疑大多数使用 CLA 的公司都没有认真进行这一步），可以最大限度地降低这种未经授权的贡献的风险。
基于常识和普遍经验，我认为在当今几乎所有情况下，员工的贡献都是在雇主的实际或推定知情和同意的情况下完成的。如果围绕开源软件存在高诉讼风险的氛围，也许应该更认真地对待这种风险，但因开源项目引起的诉讼仍然非常罕见。
更重要的是，我不知道有哪个案例表明，针对 inbound=outbound 项目的版权或专利侵权指控（并非源于所谓的开源许可侵权）可以通过使用 CLA 来预防。专利风险尤其经常被 CLA 倡导者在指出未经授权的贡献的风险时引用，但 Apache 风格的 CLA 中的专利许可授予在设计上范围非常狭窄。此外，公司对开源项目的贡献通常数量较少、规模较小（因此很容易替换），并且很可能会随着时间的推移而被丢弃。
替代方案
如果您的公司不认同反 CLA 的观点，并且无法接受简单地使用 inbound=outbound，那么还有其他替代方案，而不是求助于不对称且管理负担沉重的 Apache 风格的 CLA 要求。使用 DCO 作为 inbound=outbound 的补充至少解决了一些规避风险的 CLA 倡导者的担忧。如果您必须使用真正的 CLA，则无需使用 Apache 模型（更不用说其可怕的衍生品）。考虑 Eclipse 贡献者协议 的非规范核心——本质上是 CLA 内部包装的 DCO——或者 Software Freedom Conservancy 的 Selenium CLA，它仅仅是将 inbound=outbound 贡献策略仪式化。
2 条评论