2019 年 11 月初，数字天堂（北京）网络技术有限公司（下称：数字天堂）诉柚子（北京）科技有限公司、柚子（北京）移动技术有限公司（下称：两柚子）侵犯计算机软件著作权纠纷案，由北京高级人民法院二审作出终审判决。笔者曾密切关注该案，终审判决生效前，囿于关联代理关系的利益冲突，不便多谈。现将本案相关若干问题梳理成文，愿与各位探讨之。

本案之所以受关注，是因为本次计算机软件著作权侵权案涉及开源软件和 GPL 许可证，本案的判决对未来开源软件诉讼实践有重要意义。本案一审法院对 GPL 相关条款作了阐述，二审法院回避了 GPL 问题。本文，笔者基于本案事实和法院判决做些思考，分享给大家讨论。本文将仅对涉及开源软件及 GPL 许可证的内容进行论述，其他法律问题不作探讨。

案情简介

为节省篇幅，以下对案情进行摘要和总结，详细案情可见一审链接和二审链接。

经过一审和二审对事实的调查和确认，两柚子认可：

1. 数字天堂是 HBuilder 软件的著作权人；
2. 数字天堂拥有 HBuilder 软件中的代码输入法功能插件、真机运行功能插件、边改边看功能插件源代码著作权；
3. 两柚子的 APICloud 软件中对应插件源代码部分与涉案的三个插件具有同一性。

基于此，针对本著作权侵权控诉，两柚子抗辩理由只有 GPL 开源许可协议这一个突破口。而二审中对涉案代码量、侵权产品数量的认定，以及基于此对赔偿额的认定，只是量的维度问题。

开源许可证是法律文件

一审法院虽未明确 GPL 许可证的法律效力，但在论述涉案三个插件是否受 GPL 协议限制时，默认了 GPL 许可证具有法律约束力。这一点虽然是意料之中，但毕竟开源理念和大部分开源协议来源于国外，且应用于开源社区特定人群，这一认定给未来涉及开源软件的诉讼消除了部分不确定性。为了强调协议内容，下文涉及 GPL 许可证的除特指许可证本身外，都以 GPL 协议指代。

法院虽然默认了 GPL 协议具有约束力，即类似于协议或合同的法律效果，但并未进一步将 GPL 协议条款基于我国著作权法进行解释。社区内关于 GPL 协议的解释，特别是关于 GPL 传染性的解释是基于美国版权法，其能否为国内法院认可，依然存在不确定性。

随着开源理念的深入以及开源软件在世界范围内的普及，本案作为中国 GPL 第一案，对未来开源软件相关的诉讼意义重大。稍有遗憾的是，两审法院并未就开源软件以及 GPL 协议的关键问题进行阐述。当然，也不可能期待 GPL 问题通过一次诉讼案件完全解决，未来还需要更多的法律、学术、技术等人士贡献智慧。

关于一审认定的思考

既然法院确认了 GPL 协议的法律约束力，那么对 GPL 协议的解释要么采取社区通说解释，要么基于我国著作权法作独立解释。否则很容易出现矛盾或模糊，以至于增加企业开源实践中的法律不确定性。

关于 GPL 协议约束力范围（传染性），一审法院以涉案的三个插件可以独立运行，分别存放在三个独立的文件夹中且三个独立文件夹中无 GPL 许可证，据此认为涉案三个插件不属于 GPL 协议中所指应被开源的衍生产品或修改版本。

GPL 许可证中有关的原文如下：

The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".)——GPL 3.0

To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.

A “covered work” means either the unmodified Program or a work based on the Program.——GPL 2.0

结合 GPL 协议条款和 GNU 官网对于 GPL 传染性的解释，一审法院这一认定是值得商榷的，就像你不能认为总部在西城的 A 公司与其在昌平拥有独立办公场所的分公司 B 是完全独立的，这需要从 A 和 B 之间的财务、人事、业务等是否独立为基础判断。

同理，GPL 模块 A 与模块 B 之间是否独立，绝对不能以A和B是否位于独立的文件夹中来判断，还是需要从 A 和 B 之间的功能关系、通信关系、调用关系、依赖关系等来判断。

插件相对于主程序是否独立，需要看：

1. 插件的使命，是否为该主程序而存在；
2. 插件与主程序的交互方式，如管道、队列、函数调用；
3. 交换消息的密切性 （ intimate communication ） ；
4. 是否有例外声明等。

一审法院在确定赔偿额的时候又一次指出三个涉案插件是三个独立软件作品。一审法院从审判认定到赔偿衡量是一致的。这里，两柚子并没有就涉案三个插件的独立性进行抗辩，而这一点对 GPL 是否构成传染非常关键，在一审中被告代理律师对 GPL 许可证条款的理解也存在局限。

关于二审认定的思考

首先，二审中两柚子再次提出司法鉴定来否定涉案三个插件独立性，可能是准备利用GPL传染性中关于独立作品的认定来抗辩。不过，法院认为二审诉讼中再次提出第三次鉴定申请，有违司法程序公正和司法程序效率，即二审法院基于程序公正的角度考量不予准许。同时，二审法院认为两柚子提出的新的司法鉴定申请内容与本案待证事实之间无直接关联性，这一点是值得商榷的，因为 GPL 中作品是否独立直接影响作品是否受GPL约束，进而直接影响本案关于侵权的认定。二审法院的否决理由，直接回避了可能对 GPL 传染性问题的讨论。

其次，二审法院认定数字天堂现有证据不足以证明涉案三个插件可以独立于 HBuilder 开发工具软件中的其他程序独立运行，但针对不独立的插件却没有进一步讨论这种不独立是否能够进行 GPL 开源抗辩。也就是说，一审法院基于作品的独立认定 GPL 抗辩无效，二审法院采取了一审对 GPL 抗辩的意见，但却否定了作品的独立性这一前提。

是否为独立作品的认定直接决定作品是否属于 衍生作品 （ derivative work ） 或 修改作品 （ modified version ） ，进而直接影响是否受 GPL 约束。

当然，我们可以这样解读二审法院对于作品独立的认定，即 GPL 许可证里所说的作品的独立性，和一审、二审法院判决赔偿额对插件独立的认定是不同维度/层次，这是说的通的。但仔细阅读一审判决可知，法院在否决 GPL 抗辩中和赔偿额判定中对独立的认定是一致的，二审认可了一审对 GPL 抗辩部分的认定，却否决了赔偿额中对独立作品的认定，本身前后有矛盾嫌疑。

笔者认为，如果按照上述：GPL 传染性中独立性判定和对侵权作品数量中独立性判定是不同维度的独立性判定的假设，至少二审中需要重新认定 GPL 传染性的问题，从而将两个维度的独立性认定区分开来。

关于两柚子诉求理由的思考

两柚子在二审中再次申请司法鉴定：

1. 涉案三个插件是否可以脱离 Eclipse 主体软件在 Windows 环境中独立运行；
2. 将涉案三个插件源代码编译为插件以验证插件能否在 Eclipse 主体软件中独立运行；
3. 任意删除 Hbuilder 软件目录下的一个或多个以“org．eclipse”、“org．apache”、“com．aptana”为前缀的文件或目录 JAR 文件以验证涉案三个插件能否正常运行……

关于这三个补充鉴定事项，首先，笔者认为两柚子或者其律师在开源上做足了工作，但其中依然存在问题。首先，插件独立于 Eclipse 主程序，并不一定需要插件可以脱离 Eclipse 主程序在 Windows 中独立运行。插件的独立性在于：插件有明确的功能，可用于特定的主程序，但不依赖于特定的主程序。最后，主程序脱离插件，应当且必须可以独立运行，并且不损失主程序本身的所有功能。

再看诉讼本身

基于以上认识，我们再回头看看案件本身。首先说明，因本案需要进行多处技术鉴定，笔者无法也没有精力一一取证，仅仅基于几个假设，再捋一下 GPL 相关的问题。笔者认为，关于本案 GPL 传染性的认定需要从 3 个方面来看：

1. Eclipse 主程本身；
2. 基于 Eclipse 主程序的 GPL 插件；
3. 涉案插件与主程序，以及涉案插件与上述 GPL 插件的关系。

为方便读者理解，引用数字天堂代理律所对一审结果评述的一张图。

（1）从 Eclipse 主程序看

APICloud 和 HBuilder 都是基于主程序 Eclipse 平台，包含第三方开源插件+各自自研插件组成的集成开发环境 IDE。

首先，主程序 Eclipse 是采用 EPL（Eclipse Public License）许可证公开，EPL 与 GPL 不兼容。即便是 2017 年 8 月发布的 EPL-2.0 版本虽然添加了次级许可证选项，但其与 GPL 依然是不兼容的。因此，HBuilder 作为下游产品，其对 Eclipse 的包装分发不能变更 Eclipse 许可证。

其次，针对插件来说，无非是拓展 Eclipse 某一特定的功能，任何非 Eclipse 本身的第三方插件，可以说对于 Eclipse 主程序来说都是非必须的。其第三方公司开发的 Eclipse 主程序的插件，按照 EPL 传染性的规定，一般不视为 EPL 的衍生作品，不受 EPL 约束。

最后，需要强调的是 EPL 虽然是弱 Copyleft 许可证，但其依然是类似于 GPL 的具有“传染性”的许可证，其在给予用户更大使用方便的同时，对自身软件的 Copyleft 保护依然很强。因此，下游软件开发者在处理 EPL 软件和 GPL 软件时，需要认真对待它们的兼容性问题。

（2）从 Aptana 插件看

Aptana 在 2006 年推出时，以 EPL 1.0 发布，并于 2017 年 9 月 21 日修改为 GPL3.0 和 APL（Aptana Public License ）双许可。APL 不是开源/自由软件许可证，可以认为是商业许可，但对于非分发的内部使用是免费的。

Aptana 作为主程序 Eclipse 的插件，由于 EPL 和 GPL 不兼容，Aptana 中的 GPL 插件要和以 EPL 许可的 Eclipse 主程序连接，必须在 GPL 许可证里作例外声明。毫无疑问，笔者在 Aptana 官网找到了例外声明，即关于独立作品的 GPL 传染性例外声明，以及聚合程序的 GPL 传染性例外声明。部分内容如下：

GPL Section 7 Exception

……which are conveyed to you by Appcelerator, Inc. and licensed under one or more of the licenses identified in the Excepted License List below (each an "Excepted License"), as long as:

1. you obey the GPL in all respects for the Program and the modified version, except for Excepted Works which are identifiable sections of the modified version, which are not derived from the Program, and which can reasonably be considered independent and separate works in themselves,
2. all Excepted Works which are identifiable sections of the modified version, which are not derived from the Program, and which can reasonably be considered independent and separate works in themselves,
3. are distributed subject to the Excepted License under which they were originally licensed, and
4. are not themselves modified from the form in which they are conveyed to you by Appcelerator, and
5. the object code or executable form of those sections are accompanied by the complete corresponding machine-readable source code for those sections, on the same medium as the corresponding object code or executable forms of those sections, and are licensed under the applicable Excepted License as the corresponding object code or executable forms of those sections, and
6. any works which are aggregated with the Program, or with a modified version on a volume of a storage or distribution medium in accordance with the GPL, are aggregates (as defined in Section 5 of the GPL) which can reasonably be considered independent and separate works in themselves and which are not modified versions of either the Program, a modified version, or an Excepted Work.

If the above conditions are not met, then the Program may only be copied, modified, distributed or used under the terms and conditions of the GPL or another valid licensing option from Appcelerator, Inc. Terms used but not defined in the foregoing paragraph have the meanings given in the GPL

从以上 GPL 例外中可以看出，Aptana 只是部分限定了“衍生作品”解释，也就是运行采用 GPL 许可证的 Aptana 与像 Eclipse 这样独立的程序交互不会发生传染，仅此而已。而如果修改 Aptana，将其他程序并入 Aptana Studio，或者将 Aptana 与其他程序进行整合的作品依然受到 GPL 协议约束。简单的说，加入 GPL 例外的 GPL 程序依然是 GPL 程序，这一点必须强调。关于这一点，Aptana 官网还专门有问题解答：

Can I add EPL'd plugins to Aptana Studio package and redistribute it?
No. You can only redistribute the unmodified binary versions of the EPL'd plugins that are part of Aptana Studio when distributing any of the GPL'd code. Adding any files to Aptana Studio package creates a derivative work, and since all derivative works need to be made GPL'd, you will not be able to add EPL'd (or any other license) plugins without contacting us for a commercial license.

What if I want to make changes to some of Aptana Studio's EPL'd plugins?
You are free to make changes to any of Aptana Studio EPL'd code under the terms of the EPL. To get those redistributed as part of Aptana Studio, we encourage you to contribute those back to Aptana so that we may evaluate your changes for inclusion back into the product.

Can I take unmodified Aptana Studio binaries and combine them with an Eclipse distribution?
No. Combining our GPL'd licensed code with any other product requires that the entire product be GPL'd, and therefore you cannot include any Eclipse distribution.

数字天堂认为，其 HBuilder 是包含 Eclipse 平台框架和众多插件的聚合体软件包，但其基于 Eclipse 开发且打包了 Aptana 中的 GPL 插件。从 GPL 协议对独立程序和聚合程序的规定来看，HBuilder 不被感染很难成立。一旦这种潜在传染可能性成立，数字天堂的 HBuilder 发行版就不满足合规性，其内部 EPL 和 GPL 软件不兼容。直白的说，就是整个发行版都可能受到 GPL 的约束。同时，这对于 Eclipse 是不可接受的，哪怕 EPL 是弱 Copyleft 许可证。这些问题，多是对 EPL 和 GPL 的 Copyleft 性质认识不到位导致。

（3）涉案插件与主程序及 Aptana 插件的关系

其实，以上两步分析一旦得出受 GPL 约束的结论，就不需要下面的分析了。为了完整，同时供未来类似案例参考，简单介绍。

进一步分析 Aptana 与数字天堂的涉案三个插件之间的关系，若涉案三个插件与 Aptana 有调用、通信、依赖关系，那么涉案三个插件必然会被 GPL 传染，也即是受 GPL 约束。

从以上三步的分析可见，在 GPL 传染性判断时，是否为独立作品是非常关键的。这也是我在前面法院判决部分要强调一审法院对独立的认定虽未必符合 GPL 本身解释，但至少前后一致。而二审法院对作品独立的认定甚至前后矛盾。

当然，笔者没太多精力去调查技术细节，点到为止，有兴趣的读者可以进行深入研究。

以上分析，是基于 Eclipse 作为中立主程序（即 Eclipse 主程序著作权人非诉讼参与人），GPL 插件与非 GPL 插件判定的情况，换一种场景以上判断完全或者大部分不成立。关于开源软件和 GPL 的问题还有很多需要注意的，限于篇幅不再进一步说明，对本案或对开源感兴趣的朋友可以找我单独讨论。

付钦伟，集慧智佳高级咨询师、专利代理人，擅长专利分析布局、FTO 调查与风险应对、专利信息应用、开源软件风险与合规指导。

两者之间的差异对我们如何构建软件开发过程产生了影响。

制定标准规范和开源软件的开发有许多共同之处：两者都是竞争者可以合作的机制；两者都可以促进互操作性；两者都可用于促进新技术的采用；两者都可用于聚合或协调成熟技术。

一项技术可以同时使用标准和开源：有时一个先于另一个；在其他情况下，它们可以并行进行。它们越来越多地使用类似的工具和流程实践（例如，细粒度版本控制；利用问题跟踪器一起推动某些开发讨论）。

相似程度可能导致过度概括，错误地暗示一切都是可互换的（混合与搭配），在这儿选择一种做法；在那儿将它与一个过程相结合。实际上，获取在一个领域中获得的经验并查看它提供的好处是否可以在其他环境中获得，可能是有价值的。但是，对于某些实践而言，背景更为重要。

虽然有相似之处，但也存在显著差异。在前面的文章《没有规则的治理：复刻潜力如何帮助项目》中，我讨论了在利用 复刻 （ forking ） 潜力作为一种可以促进轻量级治理的力量方面，开源软件开发和标准开发治理能力的不同。另一个不同之处在于专利规则的选择。

如何对待专利

参与者专利权的处理通常在开源软件开发和标准开发中以不同方式排列。这种差异有一个理由。而且，这种差异会对构建开发过程产生影响。

• 开源：在为开源项目做出贡献时授予的专利许可通常由每个贡献者的贡献确定。
• 标准：参与者在标准制定方面做出的专利承诺通常由整个最终规范确定。

开源项目：基于贡献的专利规则

基于贡献的专利规则是什么意思？如果专利所有者提供软件，由于软件添加到项目中，项目软件侵犯了该贡献者拥有的专利，那么贡献者不应该返回来期望获得使用它所贡献的软件的专利许可费。当然，有许多不同的许可文本可以让我们忙于分析每个许可的解释，并讨论情况中的不确定性和细微差别。在另一篇文章中，我在 MIT 许可协议的背景下谈到了这个问题（《为什么 MIT 的专利许可不讨人喜欢？》）。我认为，基本上来说，开源开发中的共同期望就像我上面所描述的那样：当你为开源做出贡献时，你将为你提供的软件提供所有必需的权限，之后你将无法返回来再要求获得使用你所贡献软件的许可费。

标准制定：基于标准规范的专利规则

相比之下，在制定标准时，通常会有更高的期望：参与者应对专利做出承诺，这些专利对整个最终规范至关重要，而不仅仅是对其贡献。这些专利承诺并不取决于确定谁对规范提出了什么想法；对于那些参与开发规范的人来说，他们的承诺是整个标准规范。

包括在其中的专利

确定相关专利的分析在软件和规范之间也有所不同。软件通常包括与相应的标准规范相比不需要的实现细节；在提供软件时，将包括对这些细节使用任何专利的许可。相反，规范开发的专利承诺仅限于对规范“必要”或“必需”的专利。当然，这取决于规范的内容。对于互操作性标准，规范应仅包括实现互操作性所需的详细级别，从而允许实现细节在标准的竞争性实现之间有所不同。对必要专利的承诺不包括实施细节方面的专利，这些专利可用作竞争优势。

专利规则差异的基础

为什么在专利处理方面存在这种差异？鉴于标准和开源软件的开发方式存在差异，这种不同的处理方式很有意义。

更有限的与贡献范围相关的专利符合大多数协作软件开发的渐进式、开放式特性。开源项目经常持续发展，其方向可能会随着时间的推移而演化。虽然可以设置路线图和里程碑并发布快照版本，但这些不太常见，并且比标准项目中常见的范围限制和版本目标具有更少的限制性影响。

可以看出，考虑到标准规范开发结构的差异，标准开发的更高期望值（整个最终规范，不仅仅是贡献）是有意义的。标准规范通常采用具有明确范围的强版本导向演进。规范开发通常适用于特定的快照版本。标准开发活动通常具有一组目标功能（通常在诸如章程之类的文档中表示）。与许多软件开发活动的情况相比，这为可能应用到标准开发活动的技术范围提供了更清晰的公共的进展预期。这种范围的明确性有助于潜在参与者在开始参与时评估参与标准制定项目的专利影响。相比之下，开源软件开发项目更为开放，通常不会排除采用任何特定技术的可能性。

对开源项目和标准管理的影响

这些对待专利的不同措施需要不同的项目管理方法。

开源项目通常准备接受来自新贡献者的补丁。贡献者可能会随着时间的推移而来去。一些贡献者留下来。其他人可能会为该项目来解决一个有限的问题。通过软件贡献，可以更容易地了解谁贡献了什么软件，而不是准确理解谁以一种更抽象的方式“参与”。

另一方面，参与标准制定活动通常具有大量的正式手续。而且，在涉及专利承诺时，这种参与的正式性非常重要。当一个人参与该规范的大部分开发时，对最终规范的专利承诺是有意义的。标准制定过程是否可以从提供单一、有限贡献的人那里获得完整的最终规范承诺？重要的是要有一个过程，以便清楚地了解谁参与谁，谁不参与。需要明确参与者以支持来自实际专利所有者的专利承诺，实际专利所有者通常是由坐在桌旁（比喻，尽管这可能涉及实际的谈判桌）的个人所代表的公司。

如何获得基于规范的承诺？软件标准中典型的免许可费专利承诺最常被作为获得标准组织成员资格或负责规范开发的特定委员会成员资格的条件。为了使这一机制发挥作用，成员资格必须是一个定义明确的概念，以便有一个明确的成员资格决策点（即，用于触发专利承诺的明确行动）和承诺的受益人可以依赖的明确的记录文件。除了参与清晰度之外，为了促进持怀疑态度的专利参与者的参与，项目需要具有明确的范围和明确的开始和结束（明确指出专利承诺将适用的“最终规范”）。这种参与模式与典型的开源项目有很大不同，典型的开源项目可能有一个连续的参与，其范围包括维护几个主要的驱动程序到只提交一个补丁。

专利政策

虽然我所描述的差异通常是这种情况，但某些特定活动遵循不同模式可能有一些原因。例如，考虑作为标准开发活动附带的参考实现的软件。可能有一个强有力的理由期望参与者对完整的最终参考实施提供承诺，而不仅仅是限定于他们对它的贡献。当然，可能存在其他边缘情况；可能存在严格安排的开源开发；可能会有连续的、随心所欲的规范开发。

标准制定的专利政策可分为合理和非歧视（RAND）或免许可费（RF）：基本上来说，实施标准的专利许可费包括需要交（RAND）或不需要交（RF）。制定与软件相关的标准（本文的重点）更多地使用免许可费政策。关于专利许可费预期问题是许可或承诺范围政策之外的另一个维度。

结论

标准的制定和开源软件的开发通常具有不同的参与者专利期望范围（仅限于贡献或整个最终可交付成果）。这些不同的选择基于通常如何进行开发的显著差异，而不是任意差异。

作者简介：Scott Peterson 是红帽公司法律团队成员。很久以前，一位工程师就一个叫做 GPL 的奇怪文件向 Scott 征询法律建议，这个致命的问题让 Scott 走上了探索包括技术标准和开源软件在内的协同开发法律问题的纠结之路。

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

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

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

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

当我开启作为开源律师的职业生涯时，面临的一个重要问题是需要耗时费力去分析的新形式开源许可协议的激增，正如我的同事 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 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。

GPL 合作承诺 GPL Cooperation Commitment 消除了开发者对许可证失效的顾虑，从而达到促进技术创新的目的。

假如能免于顾虑，技术创新和发展将会让世界发生天翻地覆的改变。 GPL 合作承诺 GPL Cooperation Commitment 就这样应运而生，只为通过公平、一致、可预测的许可证来让科技创新无后顾之忧。

去年，我曾经写过一篇文章，讨论了许可证对开源软件下游用户的影响。在进行研究的时候，我就发现许可证的约束力并不强，而且很多情况下是不可预测的。因此，我在文章中提出了一个能使开源许可证具有一致性和可预测性的潜在解决方案。但我只考虑到了诸如通过法律系统立法的“传统”方法。

2017 年 11 月，RedHat、IBM、Google 和 Facebook 提出了这种我从未考虑过的非传统的解决方案：GPL 合作承诺。GPL 合作承诺规定了 GPL 公平一致执行的方式。我认为，GPL 合作承诺之所以有这么深刻的意义，有以下两个原因：一是许可证的公平性和一致性对于开源社区的发展来说至关重要，二是法律对不可预测性并不容忍。

了解 GPL

要了解 GPL 合作承诺，首先要了解什么是 GPL。GPL 是 GNU 通用许可证 GNU General Public License 的缩写，它是一个公共版权的开源许可证，这就意味着开源软件的分发者必须向下游用户公开源代码。GPL 还禁止对下游的使用作出限制，要求个人用户不得拒绝他人对开源软件的使用自由、研究自由、共享自由和改进自由。GPL 规定，只要下游用户满足了许可证的要求和条件，就可以使用该许可证。如果被许可人出现了不符合许可证的情况，则视为违规。

按照第二版 GPL（GPLv2）的描述，许可证会在任何违规的情况下自动终止，这就导致了部分开发者对 GPL 有所抗拒。而在第三版 GPL（GPLv3）中则引入了“ 治愈条款 cure provision ”，这一条款规定，被许可人可以在 30 天内对违反 GPL 的行为进行改正，如果在这个缓冲期内改正完成，许可证就不会被终止。

这一规定消除了许可证被无故终止的顾虑，从而让软件的开发者和用户专注于开发和创新。

GPL 合作承诺做了什么

GPL 合作承诺将 GPLv3 的治愈条款应用于使用 GPLv2 的软件上，让使用 GPLv2 许可证的开发者避免许可证无故终止的窘境，并与 GPLv3 许可证保持一致。

很多软件开发者都希望正确合规地做好一件事情，但有时候却不了解具体的实施细节。因此，GPL 合作承诺的重要性就在于能够对软件开发者们做出一些引导，让他们避免因一些简单的错误导致许可证违规终止。

Linux 基金会技术顾问委员会在 2017 年宣布，Linux 内核项目将会采用 GPLv3 的治愈条款。在 GPL 合作承诺的推动下，很多大型科技公司和个人开发者都做出了相同的承诺，会将该条款扩展应用于他们采用 GPLv2（或 LGPLv2.1）许可证的所有软件，而不仅仅是对 Linux 内核的贡献。

GPL 合作承诺的广泛采用将会对开源社区产生非常积极的影响。如果更多的公司和个人开始采用 GPL 合作承诺，就能让大量正在使用 GPLv2 或 LGPLv2.1 许可证的软件以更公平和更可预测的形式履行许可证中的条款。

截至 2018 年 11 月，包括 IBM、Google、亚马逊、微软、腾讯、英特尔、RedHat 在内的 40 余家行业巨头公司都已经签署了 GPL 合作承诺，以期为开源社区创立公平的标准以及提供可预测的执行力。GPL 合作承诺是开源社区齐心协力引领开源未来发展方向的一个成功例子。

GPL 合作承诺能够让下游用户了解到开发者对他们的尊重，同时也表示了开发者使用了 GPLv2 许可证的代码是安全的。如果你想查阅更多信息，包括如何将自己的名字添加到 GPL 合作承诺中，可以访问 GPL 合作承诺的网站。

via: https://opensource.com/article/18/11/gpl-cooperation-commitment

作者：Brooke Driver 选题：lujun9972 译者：HankChow 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

本文由高级咨询师薛亮据自由软件基金会（FSF）的英文原文翻译而成，这篇常见问题解答澄清了在使用 GNU 许可证中遇到许多问题，对于企业和软件开发者在实际应用许可证和解决许可证问题时具有很强的实践指导意义。

1. 关于 GNU 项目、自由软件基金会（FSF）及其许可证的基本问题
2. 对于 GNU 许可证的一般了解
3. 在您的程序中使用 GNU 许可证
4. 依据GNU许可证分发程序
5. 在编写其他程序时采用依据 GNU 许可证发布的程序
6. 将作品与依据 GNU 许可证发布的代码相结合
7. 关于违反 GNU 许可证的问题

7 关于违反 GNU 许可证的问题

7.1 如果发现了可能违反 GPL 许可证的行为，我该怎么办？

您应该进行报告。 首先，尽可能检查事实。然后告诉发行者或版权所有者涉及的具体 GPL 程序。如果是自由软件基金会，请写信给 mailto:[email protected]。此外，程序的维护者可能是版权所有者，他可能会告诉您如何联系版权所有者，因此将其报告给维护者。

7.2 谁有权力执行 GPL 许可证？（同 1.10）

由于 GPL 是版权许可，软件的版权所有者将是有权执行 GPL 的人。如果您发现违反 GPL 的行为，您应该向遵循 GPL 的该软件的开发人员通报。他们是版权所有者，或与版权所有者有关。若要详细了解如何报告 GPL 违规，请参阅“如果发现了可能违反 GPL 许可证的行为，我该怎么办？”。

7.3 我听说有人依据另一个许可证获得了 GPL 程序的副本。这可能吗？

GNU GPL 不允许用户将其他许可证附加到程序。但是，程序的版权持有人可以依据几个不同的许可证并行发布。其中一个可能是 GNU GPL。

对于您的副本中的许可证来说，假设由版权所有者放置，并且您合法地获得该副本，则是适用于您的副本的许可证。

7.4 遵循 GPL 的程序的开发者是否受 GPL 的约束？开发者的行为是否会违反 GPL？

严格来说，GPL 是开发者授予其他人使用、分发和更改程序的许可。开发者本身并不受其约束，所以无论开发者做什么，都不是 GPL 的“违规”。

但是，如果开发者做某些违反 GPL 的行为，那么开发者一定会失去在社区的道德地位。

7.5 我刚刚发现一家公司有一份 GPL 程序的副本，获取该副本需支付费用。他们会因为不能在互联网上提供副本而违反 GPL 吗？（同 4.12）

不会，GPL 不要求任何人使用互联网进行分发。它也不要求任何人特意去再分发程序。而且（一个特殊情况之外），即使有人决定再分发该程序，GPL 也不会要求他必须特意向您或其他人分发副本。

GPL 要求的是，如果他愿意，他必须有权将副本分发给你。一旦版权所有者将程序的副本分发给某人，如果某人认为合适，那么该人可以将程序再分发给您或任何其他人。

7.6 我可以在如果客户不继续支付订阅费用就停止运行的设备上使用遵循 GPL 的软件吗？

不可以。在这种情况下，继续支付费用的要求限制了用户运行程序的能力。 这是在 GPL 之上的额外要求，GPL 禁止这种行为。

7.7 “纠正” （ cure ） 违反 GPL v3 的行为意味着什么？

纠正违规行为意味着调整您的做法以符合许可证的要求。

7.8 如果有人在笔记本电脑上安装遵循 GPL 的软件，然后将笔记本电脑借给朋友，而不提供软件的源代码，他们是否违反了 GPL？

在我们调查这个问题的司法管辖区，这种借用不会被算作、 传递 （ convey ） 。笔记本电脑的所有者不会依据 GPL 承担任何义务。

7.9 假设两家公司试图通过让一家公司发布已签约的软件，另一家公司发布仅运行第一家公司签约软件的用户产品，以此来规避提供安装信息的要求。这是否违反了 GPL v3？

是的。如果双方通过一起工作来逃避 GPL 的要求，就可以追究它们的侵权行为。这是特别真实的情形，因为 传递 （ convey ） 的定义明确地包括会使某人对二次侵权负责的活动。

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