为什么试图用法律巫术来保护您的项目很可能适得其反。

我有一份小清单（它们永远不会被怀念），列出了开源项目应该停止做的愚蠢事情。这份清单上名列前茅的是 CLA（贡献者许可协议）及其表亲强制性 CA（版权转让）。

在本文中，我解释了为什么 CLA 和 CA 是糟糕的主意，以及我们应该做些什么来代替。按照惯例，在这一点上我发出例行的免责声明“我不是律师”，但一个人不需要成为律师就可以理解法律并推断出 CLA 和 CA 未能实现其预期目的的方式。而且，我已经与律师和高管一起研究了这些失败模式，他们手中掌握着数十亿美元的知识产权侵权风险。

我已经区分了 CA 和 CLA；我们可以进一步区分 ICLA（个人贡献者许可协议）和 CCLA（公司贡献者许可协议）。虽然所有这些都同样无用，但它们的失败模式略有不同。

首先，让我们考虑一下 ICLA。一些项目要求您在被允许提交更改到其存储库之前签署一份 ICLA。通常，它要求您声明 (a) 您明确选择将您的贡献许可给该项目，并且 (b) 您有权这样做。

问题在于。如果您受雇，您几乎肯定无法声明 (b)，并且如果您表现得好像您可以这样做，那么您可能试图帮助的项目只会给自己惹麻烦。问题在于，大多数雇佣合同将您在工作时间内甚至工作时间外编写的与您的工作相关的任何软件定义为“雇佣作品”，而您不拥有雇佣作品的权利——您的雇主拥有。

CA，例如自由软件基金会要求的 CA，也存在完全相同的问题。您也不拥有雇佣作品的版权。因此，您无法转让它。稍后我会谈到不属于雇佣作品情况的个人开发者的情况。

CCLA 的存在是为了解决 ICLA 的问题。这不是您签署的协议，而是您的雇主必须与您想要贡献的项目预先协商的协议。然后，您必须向项目提供一个可以与该 CCLA 关联的身份，以便它知道您的贡献已涵盖在内。

这至少听起来可能有用。为什么不是这样呢？要理解这一点，我们需要做更多的威胁建模。开源项目希望使用 CCLA 阻止什么？

让我们从人们倾向于首先想到的一个开始：撤销。假设代码所有者试图撤回贡献，无论是声称贡献从未做出，还是撤销对贡献的许可。很明显，CCLA 无法阻止关于贡献从未做出的声明；只有跟踪和归属入站贡献——版本控制系统会为您做到这一点——才能做到这一点。

但是 CCLA 也真的无法帮助处理第二种情况。没有 CCLA 是以使其不可撤销的方式起草的，因为公司律师理所当然地认为他们的工作是避免对任何关系做出如此极端的承诺；因此，想要背叛的公司可以找到取消 CCLA 的方法。

任何认为在 CCLA 有效期间以诚意做出的贡献在背叛后不会受到威胁的人，都从未见识过大型知识产权诉讼是什么样子。我曾经身处其中，我可以告诉你，如果背叛的 EvilCorp 想要找到一种理论，将与其员工——或无辜的第三方——在 CCLA 下交付给 GoodProject 的每一行代码都牵连进来，那么这种理论是会被制造出来的。然后 GoodProject 就会陷入诉讼，而诉讼过程本身就是一种惩罚。

（我们现在应该停下来，朝着 SCO 的方向吐口水。）

人们有时认为 CCLA 阻止的另一件事是投毒——也就是说，来自 EvilCorp 的恶意贡献者将获得专利的代码推送到 GoodProject 中，然后 EvilCorp 起诉以关闭该项目或拥有它。同样，GoodProject 和 EvilCorp 之间存在 CCLA 并不能改变任何事情；接下来显而易见的举动是 EvilCorp 解雇做出贡献的雇员，然后大声宣布，虽然他/她被授权贡献代码，但执行副总裁以下的任何人都没有被授权放弃专利权——这种说法通常是正确的。

这里的根本现实是，CCLA 无法保护 GoodProject 免受 EvilCorp 的背叛，因为没有什么可以防止 EvilCorp 的背叛。事实就是如此，而执行像要求贡献者在 CCLA 下加入这样的仪式性姿态，就像在你的房子上指着六角星来抵御火灾和洪水一样有用。

一位为 FANG 之一管理知识产权风险的朋友从内部说，

如果任何参与者试图认真对待 CCLA，它们会导致 N 平方乘以 M 的组合爆炸，其中 N 是世界上公司的数量，M 是世界上开源项目的数量。实际上没有人跟踪这一点；这只是一场歌舞伎表演，每个人都希望有一天不会在每个人的脸上爆炸。

当没有雇佣作品条款时，情况会更好吗？不，并非如此。在这种情况下，您的贡献者确实有权许可或转让某些东西……但您没有实际的方法来审核他们声称他们确实拥有他们提交的内容，并且在某些情况下（例如获得专利的算法），他们自己可能也不知道。

如果有人拥有律师和金钱，想要使用名义上受 ICLA 保护的代码来损害 GoodProject 或（例如）从其赞助商之一那里勒索钱财，那么 ICLA 也不会阻止这种情况发生。一个善意的贡献者也无法阻止它。

ICLA 可以帮助您的唯一情况是，当个人贡献者想要在没有 EvilCorp 支持的情况下撤销授权，认为它足够有价值以至于可以为此提起诉讼，并且仍然可以通过协议阻止其提起诉讼。

如果您认为这是一个哪怕是稍微合理的场景，我可以向您推荐尼日利亚王子保证的银行转账吗？因为对于个人而言，与 EvilCorp 一样，如果他们有能力起诉并且认为有足够的收益可以起诉，那么 ICLA 也不会让您免于诉讼。而且，再一次，即使 GoodProject 最终真的胜诉，诉讼过程本身也是一种惩罚。

现在让我们暂时远离所有这些假设，考虑一下现实。在我 2019 年 4 月写这篇文章时，既没有法规也没有判例法确立 CLA 可以保护您免受任何类型的法律风险。一个先例案件可能会在瞬间扫除所有这些仪式性的姿态。

也就是说，CLA 可能有用的假设集合并非完全为空。您可能会遇到这样的狭窄窗口，即坏人的预期收益略高于诉讼成本，以至于 CLA 成为有效的威慑，而无需在法庭上测试您的 CLA。那么现在让我们考虑一下您为涵盖这种不太可能发生的情况付出了多少代价。CLA 会给您的项目带来什么成本？

首先，CLA 会给您的项目带来贡献损失。一些潜在的贡献者将被他们的雇主禁止签署 CLA。更大部分的人（包括我）对文书工作和流程摩擦高度过敏，并且必须非常投入使用带有 CLA 的项目，然后他们才会签署 CLA。

实际上，无论您认为您从 CLA 中获得了什么，您都在为丢失的补丁付出代价。尤其是临时的补丁。许多可能成为临时贡献者的人将不会成为。您的“集思广益”的好处将在一定程度上丧失，甚至难以估计。

不幸的是，还有更恶劣的代价。CLA 可能会造成它们旨在预防的弊病。

每次一个项目说“我们需要您在接受您的代码之前签署一份发布协议”时，它都有助于创建一个假设，即此类发布协议是必要的——而不是相反的理论，即向开源项目捐赠代码的行为本身就构成了自愿放弃项目根据项目开源许可证暗示的条款使用它的权利。

显然，其中一种理论对开源更有利——猜猜是哪一种并不难。

如果真的到了法庭诉讼，法官首先要考虑的事情之一是围绕我们的许可证的社区期望和实践。法学家应该在合同和许可案件中这样做；关于纽约市哈西德犹太钻石商人之间握手合同的解释有一些著名的判例法，这使得这一点非常清楚和明确。如果对解释有疑问，并且没有压倒一切的公平问题，则应以达成许可/合同的社区规范为准。

因此，如果法官认为 CLA 是最佳实践，因为我们期望贡献许可失败关闭，除非明确授予，那么他/她更有可能使其发生。另一方面，如果他/她认为社区规范将贡献视为隐含地放弃某些权利，以换取参与项目的好处，那么这更有可能成为裁决的结果。

CLA 又是另一个“小心你假设的现实。你可能会创造它”的例子。

转向我们的倒数第二个话题，如果 CLA 是如此糟糕的主意，为什么还有任何项目要求它们呢？当然，所有那些高薪的公司律师不可能那么错吧，不是吗？

这取决于您认为他们正在最大化什么效用函数。有一种常见的律师，他们以降低风险的名义，建议他们的客户执行本质上是巫毒仪式的法律姿态——不是对现实的回应，而是对未来法律风险的奇怪的、过度膨胀的理论的回应，所有这些理论都有一个共同因素。它们使律师变得重要。哎呀，真令人惊讶！

如果您的项目听从了其中一位律师的建议，它很可能会养成需要 CLA/CA 的制度习惯，这种习惯很难动摇，因为这样做就意味着承认所有沉没到这个糟糕决定中的成本都被浪费了。巫毒仪式也可能因为一种默认的假设而被锁定，即拥有流程意味着您是认真的——官僚行为作为一种寻求地位的方式。

好吧，那么应该怎么做呢？

我有两个建议。它们也都是巫毒仪式——在当前法律的未成形状态下，它们不可能真的是其他任何东西。但至少，它们是低成本的巫毒仪式，不会倾向于赶走贡献者并产生可能将法官引向错误方向的假设。

第一个是简单的附合合同。NTPsec 项目在其贡献者指南的顶部有以下语言

通过向本项目提交补丁，您同意允许根据开源社区的正常形式和惯例，按照本项目的许可证重新分发这些补丁。

如果您知道什么是点击包装协议，您可能不会对它们的可执行性和普遍性感到高兴；我自己也不高兴。但只要它们存在，好人不妨也从中获得一些好处。这种语言取决于贡献在您的存储库中留下签名记录这一事实，并使用与点击包装相同的机制将贡献转化为肯定行为，这种肯定行为实际上比 CLA 更有可能保护您的项目。

（我怎么敢在不是律师的情况下做出最后的声明？请记住，这一切都是巫毒仪式；鉴于缺乏管辖法律，实际上没有人知道任何事情。不要相信任何试图告诉您不同的律师；如果他们不是在试图欺骗您，那是因为他们已经欺骗了自己。）

最后一点，“根据开源社区的正常形式和惯例”，是重要的战场准备。还记得那些哈西德犹太钻石商人吗？如果这种语言在诉讼中出现，我们可能拥有的最好辩护是让法官预先知道存在正常形式和惯例。

如果 NTPsec 的点击包装小部件（完全披露：我编写的）对您来说不够重量级，您可以像 Linux 内核那样使用开发者原创证书和“Signed-off-by”行。同样，使用项目存储库记录肯定同意的附合合同。

同样，这些都不是灵丹妙药，因为没有什么东西是灵丹妙药。但它们有一个 CLA 和 CA 没有的优点：它们不会造成伤害。