开源社区中很少有法律话题像《贡献者许可协议》一样具有争议性。
开源社区中很少有法律话题像《贡献者许可协议》（CLA）一样具有争议性。除非你算上《Fedora 项目贡献者协议》（我一直被视为非 CLA）的特殊历史案例，或者像 Karl Fogel 一样，将《开发者原创证书》（DCO）归类为一种 CLA。目前红帽公司在其维护的项目中没有使用 CLA。
过去情况并非如此。红帽公司最早的项目遵循我称之为 “入站=出站” （ inbound=outbound ） 的传统做法，其中对项目的贡献仅根据项目的开源许可协议提供，不需要执行外部非自由和开源许可协议。但在 21 世纪初，红帽公司开始尝试使用贡献者协议。Fedora 开始要求贡献者签署基于广泛采用的 Apache ICLA 制定的 CLA，而自由软件基金会衍生的版权转让协议和一对定制的 CLA 分别继承自 Cygnus 和 JBoss 的收购。我们甚至采取了一些措施，在快速增长的红帽公司主导项目中采用 Apache 风格的 CLA。
这种情况已经结束，很大程度上是因为我们红帽公司法律团队成员听到并理解了红帽工程师和更广泛的技术社区提出的担忧和异议。我们继续成为一些人称之为反 CLA 运动的事实上的领导者，特别是我们反对 Project Harmony 以及我们努力让 OpenStack 用 DCO 取代其 CLA。（我们不情愿地签署可容忍的不符合实际需要的上游项目 CLA）
为什么 CLA 存在问题
我们不使用 CLA 的选择反映了我们作为一个真正的开源公司的价值观，它在自由软件运动中有着深厚的根源。多年来，许多开源社区已经解释了为什么 CLA 以及类似的版权分配机制对于开源来说是一个糟糕的政策。
其中一个原因是繁文缛节问题。通常情况下，开源开发的特点是 无障碍 （ frictionless ） 贡献，这可以通过“入站=出站”来实现，而不需要进行进一步的法律仪式或流程。这使得新贡献者相对容易参与项目，允许贡献者社区更有效的增长并推动上游的技术创新。无障碍贡献是开源开发针对专有替代品享有优势的关键部分。但是，CLA 否定了无障碍的贡献。在贡献被接受之前签署不寻常的法律协议会造成官僚主义障碍，从而减缓发展并阻碍参与。尽管采用 CLA 的项目越来越多地使用自动化手段，但这种成本仍然存在。
CLA 还会导致项目参与者之间的法律权力不对称，这也阻碍了项目周边主要贡献者和用户社区的增长。使用 Apache 风格的 CLA，领导项目的公司或组织获得其他贡献者无法获得的特殊权利，而其他贡献者必须承担项目负责人免除的某些法律义务（除了繁文缛节负担）。在 左版 （ copyleft ） 项目中，不对称问题最为严重，即使出站许可协议是宽松的，它也存在。
在评估支持和反对 CLA 的论据时，请记住，今天与过去一样，任何产品中的绝大多数开源代码都源于遵循“入站=出站”实践的项目。相对较少数量的项目使用 CLA 会对所有其他项目造成附带损害，因为它表明，由于某些原因，开源许可协议不足以处理流入项目的贡献。
CLA 的案例
由于 CLA 仍然是少数人的做法，并且源自外部开源社区文化，我认为 CLA 的支持者应该解释清楚为什么它们相对于其成本是必要或有益的。我怀疑大多数使用 CLA 的公司只是在没有经过严格审查的情况下模仿同行公司的行为。肤浅的来说，对于那些倾向于采用更复杂的手续、纸张和流程而不管业务成本如何的风险规避律师而言，CLA 是正常的。尽管如此，一些支持 CLA 的论据往往是先进的，值得考虑。
易于 再许可 （ relicensing ） ：如果管理得当，Apache 风格的 CLA 可以根据管理员的选择，为其提供有效的无限权力来进行分许可。这种做法有时被认为是可取的，因为可能需要依据一些其他开源许可协议再许可该项目。但是，回顾一些涉及大量贡献者的项目（所有这些项目都是在没有使用 CLA 的情况下取得成功）的重要再许可活动的历史案例，易于再许可的价值被夸大了。再许可变得困难很有好处，因为它会让项目产生稳定的法律期望，并鼓励项目在进行重大法律政策变更之前咨询其贡献者社区。在任何情况下，大多数“入站=出站”开源项目在其生命周期中从不尝试再许可，而对于少数这样做的项目来说，再许可将相对轻松，因为通常需要去联系的过去的贡献者的数量不会很大。
原创追踪：有的人声称 CLA 使项目能够严格跟踪具有一定法律效益的贡献的来源。目前尚不清楚在这方面使用 CLA 所取得的成就是因为通过保留 Git 提交历史这样的非 CLA 手段无法更好地处理。DCO 似乎更适合跟踪贡献，因为它通常在每个提交的基础上使用，而 CLA 是每个贡献者签署一次，并且在行政上与代码贡献分开。此外，原创跟踪通常被描述为对公众有益，但我知道项目无法对 CLA 接受记录提供透明的随时可行的公开访问。
许可撤销：一些 CLA 支持者警告说可能有一天，贡献者可能会试图撤销过去授予的许可。如果关注的范围是大量没有供职公司的具有判断力的个人贡献者，则不清楚为什么 Apache 风格的 CLA 与使用开源许可协议相比提供了更有意义的保护。而且，正如在讨论开源法律政策时提出的许多法律风险一样，这似乎是一种幻想的风险。多年来，我只听说过少数声称的许可撤销尝试活动，所有这些都在贡献者面临社区压力而退步时得到迅速解决。
未经授权的员工贡献：这是许可撤销问题的一个特例，最近已成为 CLA 倡导者共同提出的观点。当员工为上游项目提供贡献时，通常雇主拥有项目给予许可的版权和专利，并且只有某些管理人员有权授予此类许可。假设一名员工在未经雇主批准的情况下向项目提供了专有代码，雇主后来发现这一点并要求删除该项贡献或起诉该项目的用户。通过使用类似 Apache CCLA 及其陈述和签名要求的材料，加上一些适当的审查程序以确定 CCLA 签名者可能被授权签署（我怀疑大多数使用 CLA 的公司没有采取任何有意义的措施），可以将这种未经授权的贡献风险最小化。
基于常识和共同经验，我认为，在今天的几乎所有案例中，员工的贡献都是在雇主的实际或建设性知识基础上和同意下完成的。如果围绕开源软件存在高度诉讼风险，也许应该更加重视这种风险，但开源项目引发的诉讼仍然非常罕见。
更重要的是，我不知道任何针对“入站=出站”项目的非源自涉嫌开源许可协议违规的版权或专利侵权指控因使用CLA而被阻止的案例。特别是，当指出未经授权的贡献风险时，CLA 支持者经常引用专利风险，但 Apache 风格的 CLA 中的专利许可授权的设计范围非常狭窄。此外，企业对开源项目的贡献通常很少，规模较小（因此很容易更换），并且随着时间的推移可能会被丢弃。
备选方案
如果您的公司没有对反 CLA 案例买账并且对简单使用“入站=出站”感到不舒服，那么还有其他方法可以替代非对称且管理上繁琐的 Apache 风格的 CLA 要求。使用 DCO 作为“入站=出站”的补充至少消除了厌恶风险的 CLA 倡导者的一些担忧。如果必须使用真正的 CLA，则无需使 用Apach e模式（更不用说它的怪异衍生物）。考虑“Eclipse 贡献者协议”的非规范核心（基本上是包含在 CLA 内的 DCO），或者 软件自由保护协会 （ Software Freedom Conservancy ） 的 Selenium CLA，它仅仅是对“入站=出站”贡献策略进行仪式化。
作者简介：Richard Fontana 是红帽公司法律部门产品和技术团队的高级商业顾问。 他的大部分工作都集中在开源相关的法律问题上。
译者简介：薛亮，集慧智佳知识产权咨询公司总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。
