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