当我开始我的开源律师职业生涯时，一个重要的担忧是新型开源许可证的扩散，每种许可证都需要耗时的分析。正如我的同事 Scott Peterson 在他的文章“开源许可证是共享资源”中指出的那样：
“专注于少数许可证具有优势。与许可证相关的行动和辩论分散在数百或数千个不同的许可证中相比，经验和讨论可以更容易地通过更广泛的对少数许可证的共同理解来减少不确定性。”
在过去的许多年中，社区对许可证扩散的反应是积极的，我很高兴看到大多数开源项目选择从一组特定的选项（例如，GPL、LGPL、AGPL、BSD、MIT、Apache 2）中进行选择，这些选项都为工程师和律师所熟知。因此，不会浪费时间解释它们的条款，并且可以完全启用低摩擦的生态系统。
一旦项目采用开源许可证，它通常会采用标准的“入站=出站”模型；这是 Richard Fontana 创造的一个短语。Fontana 描述入站=出站模型为贡献被理解为在适用的出站项目许可证下许可，这使得贡献者可以轻松地参与项目，而不会受到恐吓和繁文缛节。这是一个非常简单的模型，与上面详述的明智的许可证选择非常吻合。
不幸的是，许多开源项目选择不采用入站=出站，而是需要某种形式的贡献者许可协议 (CLA)。CLA 的范围和目的各不相同。Ben Cotton 的文章“CLA 与 DCO：有什么区别？”中可以找到对 CLA 和开发者原创证书 (DCO；如下所述) 的良好描述。
在使用 CLA 的项目接受贡献之前，他们将要求贡献者以个人身份或其雇用的公司提交 CLA。除非 CLA 是标准 CLA（例如，Apache 软件基金会 [ASF] CLA，具有非实质性的自定义；请参阅下一段），工程师和可能代表他们的律师都很好地理解其条款，否则贡献通常会陷入停顿，因为必须仔细阅读 CLA 条款以确保完全理解这些条款。根据工作量以及是否需要与许可证起草者进行谈判，此过程可能需要数天或数周才能完成。根据我的经验，最终结果是回到标准 CLA 条款！整个痛苦的过程导致大量时间和精力的浪费。此外，CLA 将需要某种形式的签名，这会增加更多的延迟和复杂性，这在大型官僚机构中可能非常重要。这不是一个愉快的途径，并且对开源/协作开发模型具有高度的侵蚀性。
请注意，当我提到“标准 CLA”时，我指的是基于众所周知的 CLA（例如 ASF 个人或企业 CLA）的 CLA。虽然 ASF CLA 以其原始形式被 ASF 本身使用，但它们通常以非实质性的方式进行修改，以供其他组织使用。例如，大多数组织都注意删除开头关于许可证的慈善使命的部分，并且他们还自定义许可证名称。ASF CLA 的这些非实质性变体与本文中描述的莫洛博士变体不同。
我担心最近 CLA 的扩散。我们似乎正在经历十多年前开源许可证扩散时经历的相同现象。事实上，在过去一年中，我在 Red Hat 至少看到了 20 种不同的 CLA 摆在我的办公桌上，这些 CLA 包含与非常常见的 ASF 个人或企业 CLA 略有但实质性的偏差。这些更改通常很小，旨在澄清语言或权利，但其他一些更改更大，是混合的怪异事物，让我想起了莫洛博士通过活体解剖过程创造的新动物（请参阅 维基百科上的《莫洛博士岛》）。无论更改是小还是大，它们的影响都可能是重大的，并且常常导致混乱、大量的审查时间和谈判。
例如，律师之间普遍接受的做法是在许可证或合同中定义的术语上使用首字母大写。无意中使用同一术语的小写形式会导致歧义，即应使用标准/字典定义，还是应使用协议中定义的更窄或更广的术语。尽管对于不经意的观察者来说，这似乎是一个微不足道的改变，但这通常会导致许可证授予/接收的权限显着减少或扩大，或导致不可接受的歧义。其他更改草率到不得不直接拒绝，因为它们的含义太不清楚了。
在最近的一个例子中，CLA 的专利许可语言偏离了 Apache CLA 版本，以一种令人费解的方式包含了术语“衍生作品”。这太模糊了，以至于我不得不拒绝使用它，因为授予的专利许可范围似乎过于宽泛且可能无限。我不确定这是否是此特定 CLA 的起草者预期的结果，但大量的时间和成本投入到了这次审查中，最终限制了我们的工程师为该项目做出贡献。这是一个可悲的结果，对任何人都没有好处。
作为一个社区，让我们从我们之前关于开源许可证扩散的错误中吸取教训。使用入站=出站模型——最好使用 DCO——而不是 CLA。如果您选择使用 CLA，那么强烈考虑使用像 ASF 个人或企业 CLA 这样的标准之一，而不是创建类似于 H.G. 威尔斯经典作品《莫洛博士岛》中莫洛博士岛上怪物的新的、奇异的或荒谬的许可证。
评论已关闭。