开源社区中很少有法律话题像《贡献者许可协议》一样具有争议性。

开源社区中很少有法律话题像《贡献者许可协议》（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 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

在 GPL v3 许可证颁发 11 周年之际，让我们了解一下它对自由和开源软件的持久贡献。

2017 年，我错过了为 GPL v3（GNU 通用公共许可协议的第三版）发布 10 周年撰写文章的机会。GPL v3 由 自由软件基金会 （ Free Software Foundation ） （FSF）于 2007 年 6 月 29 日正式发布，这一天在技术史上更为人熟知的事件是苹果公司推出了 iPhone 手机。一年之后的现在，我觉得应该对 GPL v3 做一些回顾。对于我来说，许多有关 GPL v3 的有趣内容可以追溯到 11 年之前，我作为积极参与者经历了当时的公共起草过程。

2005 年，经过近十年热衷于自由软件的自我沉浸，但却几乎没有任何开源法律经验可言的我被 Eben Moglen 聘用，加入 软件自由法律中心 （ Software Freedom Law Center ） （SFLC）担任法律顾问。SFLC 当时是 FSF 的外部法律顾问，我的角色被设定为关注 GPL v3 起草过程的初期公共阶段。这个机会把我从以前的并不令我满意的一次职业转变中解救出来。 自由和开源软件 （ Free and Open Source Software ） （FOSS）的法律问题成为我的新专长，我发现这一点很有吸引力，令人满意，并且在智力上有所回报。我在 SFLC 的工作，特别是我在 GPL v3 方面勇闯火线的工作，成为了我的在职培训。

GPL v3 必须被理解为早期 FOSS 时代的产物，其轮廓可能让今天的人难以想象。在 2006 年公共起草过程开始时，Linux 和开源已经不再是早年一些漫不经心的观察者所看到的几乎是同义词的情形了，但两者之间的联系仍然比现在更密切。

Linux 已经对技术行业产生深远影响的反映是，每个人都认为 GPL v2 是主要的开源许可模式。我们看到了开源（和伪开源）商业模式如寒武纪式爆发的最终震荡。一个泡沫化商业炒作包围的开源（对我来说最令人难忘的典型代表是 开源商业会议 （ Open Source Business Conference ）与软件工程专业人士目前对开源开发的接受程度几乎没有相似之处。微软凭借其不断扩大的专利组合以及对 Linux 的竞争性对抗，在 FOSS 社区中普遍被视为一种现实存在的威胁，而 SCO 诉讼已经在 Linux 和 GPL 之间笼罩上了法律风险的阴云，并且没有完全消散。

这种环境必然使得 GPL v3 的起草成为自由软件历史上前所未有的高风险事件。主要的技术公司和顶级律师事务所的律师争先恐后地对该许可协议施加影响，并确信 GPL v3 必将接管并彻底重塑开源业态及所有大量相关的商业投资。

技术社区内存在类似的心态；这在 Linux 内核开发人员于 2006 年 9 月对 GPL v3 的强烈指责中所表达的恐惧里略见一斑。我们这些接近 FSF 的人知道的多一点，但我认为我们假定新的许可协议要么是压倒性的成功，要么是彻底的失败——“成功”意味着将现有的 GPL v2 项目生态系统升级为 GPL v3，尽管也许 Linux 内核会缺席（LCTT 译注：十年过去了，Linux 内核仍旧采用 GPL v2 许可证）。实际的结果是介于两者之间的东西。

我对测量开源许可协议采用程度的尝试没有信心，近年来这种做法通常用于证明 左版 （ Copyleft ） 许可协议失去竞争优势。根据我自己的接近 Linux 和工作于 红帽 （ Red Hat ） 公司的明显有倾向性的经验，表明 GPL v3 作为自 2007 年以来推出项目的可选许可协议，享有适度的受欢迎程度。尽管 2007 年之前存在的大多数 GPL v2 项目以及它们在 2007 年以后的分支，仍然遵循旧许可协议。（GPL v3 的兄弟许可协议 LGPL v3 和 AGPL v3 从未获得过相当程度的普及）大多数现有的 GPL v2 项目（有一些明显的例外，如 Linux 内核和 Busybox）被许可为“GPL v2 或任何更高的版本”。技术界早就决定“GPL v2 或更高版本”是一个政治中立的许可协议选项，它包含了 GPL v2 和 GPL v3。这可以解释为什么 GPL v3 的采用推进得缓慢和有限，特别是在 Linux 社区中。

在 GPL v3 起草过程中，一些人表达了对 Linux 生态系统“ 巴尔干化 （ balkanized ） ”的担忧，无论是因为用户必须了解两个不同的强大左版许可协议的开销，还是因为 GPL v2 / GPL v3 的不兼容。事实证明，这些担忧完全没有根据。在主流服务器和工作站 Linux 堆栈中，这两个许可协议已经和平共存了十年。这其中部分是因为这样的堆栈由强大的左版范畴的单独单元组成（参见我对容器设置中相关问题的讨论）。至于强左版范畴单元内部的不兼容性，在这里，“GPL v2 或更高版本”的普遍性被技术界视为干净利索地解决了理论问题。尽管名义上的“GPL v2 或更高版本”升级为 GPL v3 的情况几乎没有发生过。

我已经说过，我们中间的一些 FOSS 许可协议极客已经提到了假定的左版衰退的问题。早在公共起草过程的开始阶段，GPL v3 已经在批评者那里形成了滥用，并且可以推断，有些人已经在特殊情况下的 GPL v3 不受欢迎与一般意义上的 GPL 或左版失宠之间建立了联系。

我对它的看法有所不同：很大程度上是因为它的复杂性和 巴洛克 （ baroque ） 风格，GPL v3 失去了创建强大的可以广泛地吸引现代个人软件作者和企业许可人的左版许可协议的机会。我相信今天的个人开发者往往更喜欢简短、易懂、简约的许可证，最明显的例子就是 MIT 许可证。

面临开源许可协议选项的一些公司决策者可能很自然地分享这种观点，而其他公司决策者可能认为 GPL v3 的某些部分风险太大（例如专利条款或反锁定要求）或与其商业模式不相容。具有讽刺意味的是，未能吸引这些群体的 GPL v3 的一部分特性是因为有意识地试图使许可协议吸引这些具备相同类型利益的群体。

GPL v3 是如何变得如此巴洛克式的？正如我所说，GPL v3 是较早时期的产物，彼时 FOSS 许可协议被视为项目治理的主要工具。（现在我们倾向于将治理与其他类型的法律或准法律工具联系起来，例如组织非营利组织，围绕项目决策制定规则，行为准则和贡献者协议。）

在其起草过程中，GPL v3 是对 FOSS 许可协议可以作为雄心勃勃的私人监管手段持乐观态度的最高点。对于 GPL v2 来说已经是这样了，但是 GPL v3 通过详细解决一些新的政策问题——软件专利、反规避法律、设备锁定等方式来解决问题。这必然会使 GPL v3 许可协议比 GPL v2 更长、更复杂，因为 FSF 和 SFLC 在第一份 GPL v3 基本原理文件中满怀抱歉地提到了这一点。

但是，起草 GPL v3 过程中的其他一些因素无意中导致许可协议的复杂性增长。代表供应商和商业用户利益的律师从法律和商业角度提供了有用的改进建议，但这些通常采取让措辞简单的条款变成更冗长的形式，在明晰性方面可以说没有明确的改善。对技术社区反馈（通常是识别许可条款的漏洞）的回应也有类似的效果。

GPL v3 起草人也因短期政治危机（2006 年有争议的微软/ Novell 交易）纠缠在一起，导致许可协议的专利部分永久性地增加了新的和不寻常的条件，这在 2007 年之后是毫无用处的, 除了使有良心的专利持有商更难遵守许可证。当然，GPL v3 中的一些复杂性仅仅是为了使合规更容易（特别是对于社区项目开发人员）或者编写 FSF 的解释实践。最后，人们可以对 GPL v3 中使用的语言风格提出质疑，其中大部分语言都具有传统软件许可法律的顽皮模仿或嘲弄；在许多情况下，一种更简单、直接的措辞形式是一种改进。

GPL v3 的复杂性以及在许可协议起草中倾向于简练和简洁的趋势以及明智的许可政策目标，意味着 GPL v3 的实质性文本对后来的 FOSS 法律起草几乎没有直接影响。但是，正如我在 2012 年所惊奇和高兴地看到的那样，MPL 2.0 改编了 GPL v3 的两个部分：GPL v3 终止条款中的 30 天补救和 60 天休眠文本，并保证升级到更高版本许可协议的下游对上游许可人没有新的义务。

GPL v3 补救文本已经产生了重大影响，特别是在过去一年中。随着 FSF 的支持， 软件自由保护组织 （ Software Freedom Conservancy ） 颁布了《 面向社区的 GPL 执行原则 （ Principles of Community-Oriented GPL Enforcement ） 》，该原则要求将 GPL v3 补救机会扩展到 GPL v2 违规行为，Linux 基金会技术顾问委员会发布了一份声明，得到了一百多个 Linux 内核开发人员支持，其中包含了 GPL v3 的补救文本。接下来是以红帽公司为首的一系列企业承诺，将 GPL v3 补救条款扩展到 GPL v2 和 LGPL v2.x 违规，这是一项建议个人开源开发者做出同样承诺的活动。红帽公司的一项声明宣布，从此以后其主导的 GPL v2 和 LGPL v2.x 项目将在项目存储库中直接使用承诺文本。我在最近的博客文章中讨论了这些发展。

关注 GPL v3 的一个持久贡献是改变了对广泛使用的 FOSS 许可协议修订方式的期待。在没有社区评论的参与，也没有努力与主要利益相关者进行磋商的情况下，这些许可协议不能完全进行私下修改。MPL 2.0 以及最近的 EPL 2.0 的起草过程反映了这一新规范。

作者简介：Richard Fontana 是红帽公司法律部门产品和技术团队的高级商业顾问。 他的大部分工作都集中在开源相关的法律问题上。

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

提要：想要知道开源许可证对 Linux 容器有什么影响吗？以下问题您需要了解。

尽管目前开源软件已经成为主流，但是不断涌现的软件新技术以及重新流行的旧技术有时也会引发对开源许可证的强烈担忧。大多数情况下，大家关注的焦点是 GPL 许可证，特别是经常（有时是误导性的）被描述为 GPL 衍生作品问题的 左版 （ copyleft ） 范围问题。

将该问题结构化的一个不完美方式是：遵循 GPL 许可证的代码在某种意义上与专有代码相结合，形成一个单独的修改后作品，是否可以解释为该专有代码受到 GPL 许可证的约束？虽然我们还没有看到很多针对 Linux 容器的问题，但随着容器的采用持续增长，我们预计会有更多的问题提出来。不过，有相当简单的方式可以表明，容器不会引发新的或有关 GPL 范围的问题。

法规和判例在解释类似 GPL 这样的许可证方面几乎没有什么帮助。另一方面，即使是在自由软件基金会（FSF）不是相关软件版权持有者的典型情况下，我们中的许多人也重视 FSF 作为 GPL 起草者和管理者的解释性观点。除了作为许可证文本的作者之外，FSF 多年来一直致力于向社区提供有关许可证的评论和指导。基于自由软件政策的公共利益使命和领导力，FSF 的观点具有特殊的可信度和影响力。

FSF 关于 GPL 解释的现有指导，有助于理解在容器中将 GPL 代码和非 GPL 代码包含在内所产生的效果。FSF 在界定左版范围时重点考虑了进程的边界，以及多个软件组件之间的通信机制和语义，以确定它们的紧密集成程度是否足以被视为 GPL 意义下的单个程序。例如，GNU 许可证常见问题解答认为，在没有足够 “密切” （ intimate ） 通信的情况下，管道、套接字和命令行参数通常可以被隐含认为是具备独立性的机制。

考虑容器中有 GPL 代码和专有代码可能共存并执行的情况，实际上，容器是一个孤立的用户空间栈。在 OCI 容器映像格式中，代码被打包为一组文件系统的变更层，基本层通常是一个没有内核的精简传统 Linux 发行版。与非容器化的 Linux 发行版的用户空间一样，这些基本层包括许多遵循 GPL 许可证（GPL v2 以及 GPL v3）的软件包，以及许多遵循被认为与 GPL 不兼容许可证的软件包，并且通常作为专有以及开源应用的运行环境。GPL v2 中“ 单纯聚合 （ mere aggregation ） ”条款（以及 GPL v3 中有关“聚合”的条款）表明，这种组合通常是可以被接受的，在 GPL 中进行了特别考虑，如果不兼容的被许可组件是分离和独立的，就不会影响两个程序的许可。

当然，在特定情况下，两个组件之间的关系可能不是“单纯聚合”，但是在 Linux 系统上的非容器化用户空间中运行的软件也是如此。容器或容器映像的技术构成中没有任何暗示表明需要应用特殊形式的左版范围分析。

因此，当考察运行在容器中的代码和运行在容器外面的代码之间的关系时，几乎肯定会满足“分离和独立”的标准。代码将作为单独的进程运行，使用容器的整个技术要点是与运行在系统上的其他软件隔离。

现在考虑两个组件的情况，其中一个遵循 GPL 许可证，另一个为专有软件，它们运行在分离但可能交互的容器中，也许作为使用微服务体系结构设计的应用程序的一部分。在没有特别不寻常事实的情况下，我们不应该期望看到左版的范围跨越多个容器。分离的容器涉及分离的进程。通过网络接口在容器之间进行通信类似于管道、套接字等机制，多容器微服务场景似乎排除了 FSF 所定义的“密切”通信。使用多个容器的应用程序的组成可能不是 GPL 范围问题的决定因素，但它使组件之间的技术边界更加明显，并为争论“分离性”提供了强有力的基础。这其中也没有容器的技术特征暗示对左版的范围分析应用不同或更严格的方法。

过度关心分发 GPL 代码潜在影响的企业可能会试图禁止其开发人员将任何此类代码添加到计划分发的容器映像中，目的就是为了避免依据 GPL 许可证分发代码，但这是一个容易受到质疑的策略。如上所述，常规容器映像的基础层将包含多个遵循 GPL 的组件。如果该公司将容器映像推送到注册表中，通常无法保证这其中不包含基础层，即使它被广泛共享。

另一方面，通过隔离 GPL 代码和专有代码，企业可能会决定采用容器化作为减少左版范围影响的一种手段，虽然人们希望基于技术上的益处，而不是莫须有的对 GPL 焦虑所带来的法律担忧来推动该决策。而在非容器化环境中，两个相互作用的软件组件之间的关系往往是单纯聚合，容器化所提供的“分离性”证据可能让那些担心 GPL 范围的人们感到安慰。

共享容器映像时，可能会出现开源许可证合规义务问题。但是，对于容器来说，没有什么技术上的不同或独一无二的东西可以改变这些义务的性质，或者使它们更难满足。关于左版的范围，容器化应该能够缓解过度的担忧。

作者简介：Richard Fontana 是红帽公司法律部门产品和技术团队的高级商业顾问。 他的大部分工作都集中在开源相关的法律问题上。

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