《贡献者许可协议》是“人魔”般的怪物？

本文主要是介绍《贡献者许可协议》是“人魔”般的怪物？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

640?wx_fmt=jpeg

640?wx_fmt=png

译者：薛亮 | 编辑：Charon

640?wx_fmt=png

非标准的开源贡献者许可协议正在创造类似电影《冲出人魔岛》中“人魔”般的怪物。 —— Jeffrey Robert Kaufman

当我开启作为开源律师的职业生涯时，面临的一个重要问题是需要耗时费力去分析的新形式开源许可协议的激增，正如我的同事 Scott Peterson 在其文章中所述，“开源许可协议是共享资源”：

过去多年开源社区对许可协议扩散的反应持积极态度，我很高兴看到大多数开源项目都从一组被工程师和律师熟知的许可协议（例如 GPL、LGPL、AGPL、BSD、MIT、Apache 2）中进行选择。因此，不用将时间浪费在解释许可协议条款上，完全开启了一个低摩擦的生态系统。

一旦项目采用开源许可协议，它通常采用标准的“入站=出站inbound=outbound”模式，创造该短语的 Richard Fontana 将其描述为贡献者不言自明地获得出站项目适用的许可协议的许可，使得贡献者可以轻松参与项目，无需担心繁文缛节和受到威胁。这是一个非常简单的模式，能够非常聪明地进行上面提到的许可协议选择。

不幸的是，许多项目不选择采用“入站=出站”模式，而是采用某种形式的《贡献者许可协议Contributor License Agreement》（CLA）。CLA 的范围和目的各不相同。读者们可以在 Ben Cotton 的文章《CLA 与 DCO 有什么不同》中具体了解《贡献者许可协议》与《开发者原创证书Developer Certificates of Origin》（DCO）的区别。

采用 CLA 的项目在接受贡献之前，要求贡献者提交作为个人或所在公司签署的 CLA 存档。除非是其条款能够被工程师和其代理律师很好理解的标准 CLA（例如下文提到的 Apache 软件基金会非实质性定制的 CLA），否则因为需要非常仔细阅读 CLA 以确保能够完全理解其条款，贡献者通常放弃去深究 CLA。理解非标准 CLA 的过程需要数天或上周才能完成，具体取决于工作负荷以及是否需要与许可协议提交人进行协商。根据我的经验，最终结果是回到标准的 CLA 条款！这个曲折的过程导致大量的时间和精力被浪费。此外，CLA 需要某种形式的签名，增添了许多在大型官僚组织可能更严重的延迟性和复杂性。这并不是一条令人开心的路径，对开源/协作开发模式具有高度侵蚀性。

请注意，当我提到“标准 CLA”时，我所指的是基于众所周知 CLA（例如 Apache 软件基金会个人或企业 CLA）的 CLA。虽然 Apache 软件基金会的 CLA 由基金会本身以其原始形式使用，但它们通常被以非实质性方式进行修改以供其他组织使用。例如，大多数组织在开始时都小心翼翼地摆脱了许可协议的慈善使命，还定制了许可协议名称。Apache 软件基金会这类非实质性变体需要与本文中描述的类似“人魔”怪物的变体区分开。

我对最近 CLA 数量的激增表示担忧，我们似乎正在经历十年前在开源许可协议扩散方面遇到的相同现象。事实上，在过去的一年里，在我的办公桌上至少看到 20 种不同的 CLA，它们与常见的 Apache 软件基金会个人或企业 CLA 存在细微但实质性的偏差。这些偏差通常小到无助于澄清条款语言或权利，但其中有些偏差会比较大，这种混合的可憎之物让我想起了 Moreau 博士通过他的活体解剖过程创造的新动物（参见维基百科上的《冲出人魔岛》）。无论偏差是小还是大，它们造成的影响可能很大，经常导致混淆、更多的审查时间以及谈判。

例如，律师普遍接受的做法是对许可协议或合同中的术语使用初始定义。无意中使用同一术语的小写形式会导致是否应该使用该术语在标准/字典中定义或协议中更窄或更宽泛定义的模糊性。尽管这对于不经意的观察者来说似乎是一个微不足道的偏差，但这通常会导致许可协议接收/授予的权限显著减少或扩大，或者导致不可接受的歧义。其他偏差起草得如此之差，以至于它们的意义不明确，因此必须彻底拒绝。

在最近的例子中，有一种 CLA 的专利许可语言以令人困惑的方式将术语“衍生作品”derivative works包括在内，偏离了 Apache 软件基金会 CLA 版本。此 CLA 授予专利许可的范围似乎过于宽泛且可能无限制，它是如此模糊，以至于我被迫拒绝使用它。我不确定这是否是这个特定 CLA 的起草人所预期的结果，但是这次审查花费了大量的时间和成本，最终限制了我们的工程师为该项目做出贡献。这是一个令人伤心的结果，没有人从中受益。

作为一个社区，让我们从之前关于开源许可协议扩散的错误中吸取教训，采用“入站=出站”模式，最好使用 DCO而不是 CLA。如果您选择使用 CLA，那么强烈建议使用 Apache 软件基金会个人或企业 CLA 等标准 CLA，而不是创建新的、幻想的或荒谬的类似“人魔”怪物的许可协议。

作者简介：Jeffrey R. Kaufman 是全球领先的开源软件解决方案供应商 Red Hat 公司的开源知识产权律师，还担任托马斯杰斐逊法学院Thomas Jefferson School of Law的兼职

教授。在任职 Red Hat 之前，Jeffrey 曾担任高通公司Qualcomm Incorporated的专利顾问，为首席科学家办公室Office of the Chief Scientist提供开源事务咨询。

译者简介：薛亮，集慧智佳知识产权咨询公司总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

640?wx_fmt=jpeg