今天看到一篇文章《开源项目在闲鱼、b 站上被倒卖？这是什么骚操作？》，我突然想起了之前两个类似的案例，发现群众的开源知识普及依然不足，借这个机会再聊聊开源，从开源著作权人的角度做一次讨论。

案例 1：倒卖开源代码

本案例中，作者十三发现自己开源的代码被贩卖，一脸郁闷。先不讨论这些倒卖者的行为，笔者从作者提供的代码托管官网上看到其开源许可证是 MIT。

MIT 作为一个宽松型开源许可证，授予使用者几乎无限制的权限。也就是说倒卖者的行为固然让人讨厌，但其确实是可以这么做的。当然，作者十三除了困惑于开源的东西为何还有人拿去卖钱以及竟然还有人买之外，整体上是淡定、大度的。而倒卖者利用的正是大众的这种专业知识的缺失和信息的不对称性，严格意义上这是存在经济正当性的。

案例 2：王垠闭源

这个案例是 2017 年的旧闻，但很具代表性。BSD 许可证开源的软件被商业公司商业使用，还聘请了原开发者，最后闹的鸡飞狗跳。

注：原博文《为什么我的代码进入闭源状态》地址已经 404 无法访问，大家可以搜索相关转载。

王垠此人我不甚了解，据说曾经国内人气非常高，知乎、v2ex、csdn 博客上到处都有对他的评价和争论。但至少从这篇帖子可以看出，其对开源的理解很浅、也很狭隘（在 2017 年时，不代表现在）。其对开源抱有不该有的幻想，期待过高。

案例3：swoole 修改开源协议

这个案例也是 2017 年的，以 Apache 许可证开源的软件 swoole（撰文时经核实 swoole 依然是 Apache 许可证），与其复刻分支版本之间纷争。

这个案例更像各种 Android 发布版与 Google Android OS 之间的关系，以宽松型许可协议开源的软件被各种修改版骚扰、蹭热度的现象很普遍。

开源知识普及之路漫长

以上三个案例都可以称之为开发者的控诉，暂不评论其控诉是否合理。仅以这些事件本身以及在网上引起的纷争，都说明距离开源在国内普及，还有很长的路要走。但值得欣慰的是，从 2017 年到 2020 年我们看到了这种进步，案例 1 中的作者对开源的理解上虽有偏颇，但并没有出现知识或法律方面的硬伤。

从开源软件概念引入中国，到近几年开源运动如火如荼的开展，已有几个年头。但据笔者与企业及业内人士的接触发现，公众对开源的认知和理解程度依旧参差不齐。究其原因有以下几点：

1. 大部分关注开源的人，更多的是关注技术，不会关注其背后的许可证问题；
2. 开源许可证更偏向法律，真正做技术的不关注、也不懂；
3. 开源许可证法律条文晦涩难懂，不容易理解；
4. 懂技术、会看代码的专利、著作权、商标等领域的律师甚少，没有技术背景的律师纵使法律水平再高，在理解涉及开源软件相关问题时也力不从心；
5. 开源领域国内诉讼不多，没有充分引起大部分企业、学界等人员的重视；
6. 也因为诉讼少，经济驱动力有限，很难吸引律师深入研究这一领域。重赏之下必有勇夫，若有足够的利益驱动，修个计算机学位又何妨，或者报个代码速成班也不是不可能吧。

笔者有缘在多年前接触开源治理、合规问题，时不时看到网上爆出浅层次开源“事故”，说明大众的开源知识有限。今天蹭个热乎劲，再探讨一下开源基础知识（开源科普的知识网上并不少，没人关注归根结底还是这个领域内生动力不足所致）。既然内生动力不足，就靠外部热点的外部动力吧。

开源“事故”，你是否理解开源？

开源是什么？

开源就是奉献，无私或有私的奉献。此处不接受反驳。

开源运动起源于自由软件运动，自由软件运动的发起人 理查德·马修·斯托曼 （ Richard Matthew Stallman ） 是自由软件运动精神领袖。自由软件运动所要反对的就是后来以比尔盖茨（曾经）为代表的软件私有化运动。所以说，自由软件是旗帜鲜明的追求奉献、共享和软件自由的。

开源运动的兴起是自由软件运动向商业化的妥协（可以这么说，毕竟经济基础决定上层建筑），所以说开源软件运动虽然有别于曾经的自由软件运动，奉献和协作依然深深的烙在其血液里。如果你无法理解这一点，就再看 10 遍开源软件的定义（直到看懂为止）。

开源运动淡化了自由软件运动乌托邦式的理想主义，穿上了实用主义的外衣，毕竟空洞的理想是填不饱肚子的。

开源“事故”，背后的起因

网上时不时爆出的开源“事故”大都归于两类：

类型一：批判拿来主义者坐收渔利、不劳而获、贩卖别人劳动成果……。这一类主角，多是软件开发者自己，站在自己的立场上看待开源软件的使用者（合法使用者、不合法使用者）。

该类“事故”的原因有：

1. 软件的开发者没有充分理解开源的要义；
2. 对开源许可证不理解，开源自己软件时没能正确选择许可证，导致自己有被白piao的感觉；
3. 想借助大众或社区的力量优化自己的软件，获得免费劳动力；
4. 想借助开源扩大自己影响力（自我营销），却没考虑为此要付出的代价；
5. 看到其他人利用自己的开源软件获利，心理上有些许不平衡。

类型二：批判开源软件收费、许可证不人性，批判严格型许可证的传染性像病毒、吸血鬼、耍流氓，对别人行使著作权或协议约定的行为愤愤不平。这一类人，基本是拿来主义者，同样站在自己的立场上看待开源软件的开发者（仁慈的开发者、邪恶的开发者）。

该类“事故”的原因有：就是想白 piao 而已，因为你完全有选择用与不用的权力。

这两类“事故”的产生都源于没能深入理解开源运动的精髓和要义，纯粹的从利己主义出发思考问题，没有做到换位思考。忽略了开源的初衷：奉献和共享。

现实中，经常发生这样的事情：对同一个人，作为开源的使用者时他们常常讨厌 GPL 许可证，因为限制太多；作为开源软件开发者时又喜欢 GPL 的安全感，讨厌 MIT、BSD 等许可证让自己被白 piao 了却投诉无门。

开发者和使用者的权利义务

开源软件首先是开发者的劳动成果，是拥有著作权的。开源一定意义上就是奉献，每一个开源软件使用者都是开源的受益者。面对这种奉献，你需要做的就是尊重。但开源的使用者并不必然要求是高尚的、无私的，这种尊重基于开发者选择的开源许可证在合规的前提下行使权利，在尊重权利人的同时实现共赢和自身利益最大化。

而作为开源软件的开发者，也不必然要求是高尚的、无私的，开发者可以基于自己的目的来选择适当的开源协议。选择开源，就要审视自己内心深处的想法，开源的动机和目的是什么？后果是什么？……慎重的思考了这些问题后，还需要清楚的知道选择宽松型的许可证可能要面对的各种问题。

开源使用者是纯粹的受益者，即便是抱怨无非是对严格型许可证发发牢骚而已。而开源的开发者往往显得更值得同情，一般是从道义上（如案例 3）以及经济利益上（如案例 1、2）体现。但这就是开源运动运行的机制，它肯定不完美，但被证明是行之有效的。针对开源开发者，你需要做的就是当别人违法的时候拿起法律的武器捍卫自己的权利，当别人没有违法的时候，你心里再不爽也要保持淡定。

当然，诸如前述案例让人糟心的事情肯定很多，开发者也不是束手无策：

比如案例 1 中新蜂商城的作者，选择了 MIT 这个非常宽松的许可证。就意味着，其他人几乎可以拿来做任何事情，包括卖钱。但你依然有以下权利：

1. 不准拿你的大名做推广，或者类似名字这种具有身份意义、独特标识作用的符号；
2. 如果作品真的好且有市场，作者完全可以自己经营，将自己的品牌做大；
3. 别人卖的了你的源码卖不了你的实力，你可以不断迭代升级，源码和服务提供一站式解决方案。其实，现实中我们熟悉的开源软件大都如此，比如 Android、Linux 等；
4. 乐见其成，毕竟开源就是奉献自己的劳动成果让人使用，二手贩子们所做的事与开源者的目标是一致的。当然如果贩子们声称是自主源码云云（国内拿开源的东西声称自主开发的太多了），那必然是违法的，开源者可以大胆的拿起法律的武器。

主动开源，你真的准备好了吗？

基于国内的现实状况，笔者以往更多的是将精力放在帮助企业和开发者合规的使用和利用开源。因为我们曾经都是开源的受益者，需要基于合法、合规的前提汲取营养、学习知识。

目前，国内越来越多企业或个人开始思考反哺开源社区，这是非常好的开始，说明我们从受益者开始变为奉献者。但现实中这些才华横溢的开发者在开源中难免遇到案例中的问题，一旦遇到将严重挫伤其开源的积极性。

因此，开源开发者在主动开源之前，更需要深刻理解开源，明确自己开源的目的以及可能面对的潜在问题等。在慎重思考自己开源的目的和对开源后各种问题的考量后，选择适合自己的许可证。

以下是几个典型的开源动机面临的潜在风险：

1. 想借助大众或社区的力量优化自己的软件，获得免费劳动力
   开源软件千千万，真正取得成功或大众认可的软件凤毛麟角，不能说这种目的动机不纯，至少实现的可能性甚微。更多的可能是根本没有人看得上你的项目。
2. 想借助开源扩大自己影响力（自我营销）
   这可能是开源开发者，包括大企业做开源的一个非常重要的目的。具体能否实现，就看你的水平有多高，实力是否匹配自己的梦想。
3. 基于自己牛逼的软件，打造生态。
   这也是大部分企业的终极梦想，就像第一条所述，大部分的开源软件都归于路人甲，能否实现自己的生态梦取决于你的软件到底如何，能否支撑一个生态、够吸引外围群落。
   即便这些都满足了，还要思考一点，你自己的实力能否持续主导这个生态的发展。因为，开源社区的主导力是由实力说话的，如果你无法保持持续的创造力，别人fork一下就可能成为新的盟主而把你晾在一边坐冷板凳。Google 的 Android 生态就是道理，Google 对 Android 生态的领导力是建立在其持续的创造力之上的。
4. Just for fun
   最纯粹的开源。如果你开源软件的目的很单纯，就是因为喜欢而开源。那单纯的你需要知道不同开源许可证开源的后果。若别人拿你的开源软件去卖钱你也不要太上头，因为这是允许的，当然更不能看到别人赚了一大笔钱心里就不平衡了。就像大把的企业靠着 林纳斯·本纳第克特·托瓦兹 （ Linus Benedict Torvalds ） Just for fun 的软件 Linux 和 Git 赚了大笔的钱，你能做的就是乐见其成。

开源不仅仅是代码，更是人品和实力，也是策略和格局。希望每一个奉献和使用开源的你，都能感受到这个世界的善意。以上是基于本次热点，针对使用开源以及主动开源分享的点滴思考和建议。有兴趣可以找我讨论沟通。

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

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 调查与风险应对、专利信息应用、开源软件风险与合规指导。

关于 React.js 的开源许可证从去年 7 月份争议到现在，Apache 基金会终于确认了立场，反对使用 React.js 和 Facebook 其他使用此许可证（BSD+Patents licensed）的流行软件。

最近，随着开源运动不断壮大，这边 LC3 大会刚过去不久，人们的热情还是未曾消去，那边 Apache 和 Facebook 又搅动着整个社区。

作为本次事件焦点的 Facebook Patents license 已经不是第一次出风头了，时不时成为人们讨论的主题。

上一次挑动大众神经是在 2016 年 7 月，Facebook 给 React 应用的开源许可协议是，在 BSD3-clause 协议基础上加上旨在保护 Facebook 自身的扩展协议。而这一次依然是围绕 Facebook Patents license 展开，简单梳理此次事件：

• 2017 年 4 月，Apache Cassandra 项目正考虑增加 RocksDB 作为存储引擎，但考虑到专利授权的问题，Jeff Jirsa 向 Apache 法律社区寻求意见。
• 2017 年 6 月，Apache 法律社区开始讨论 Facebook Patents license 协议专利授权的不对称性问题，且该协议与Apache Software License（即 Apache 2.0 等）不兼容。
• 2017 年 7 月 15 日，Apache Software Foundation（以下简称 ASF）主管兼法律事务副主席 Chris Mattmann 正式发表声明称：Facebook BSD+Patents license（以下简称 FB+PL）已经正式被列入 “CategoryX” 列表，因此 Apache 项目中将不能够包含或依赖于 Facebook Patents license 的代码；而已经发布的代码，涉及 FB+PL 许可证的，需要在 8 月 31 号前完成替换。

这一结论一出场便自带光环，引起了整个社区的关注，包括国内著名社交论坛知乎。当然，其对 Apache 项目自身的影响不比外界的关注度低。

如，虽然 Facebook 已于本月 17 号将 RocksDB 许可证更新为 Apache 2.0 和 GPLv2 双许可，但更大的问题是 React 也是基于 FB+PL 开源，Apache 的 CouchDB 项目、Apache Superset 项目等都依赖于 React，但是要让其开发人员在一个月内摆脱对 React 的依赖似乎也不是一件简单的事情。

到底是什么原因让 ASF 对 Facebook 的 FB+PL 许可协议下禁止令？要回答这个问题，需要先分析一下 FB+PL 许可协议。

众所周知，Facebook 也算是开源社区的中坚力量，截至目前已经发布了很多开源软件技术，包括使用广泛的 React.JS 框架和键值数据库 RocksDB。

不过，Facebook 没有像其他社区一样，自定义自己的开源许可证，也没有仅采用现存的开源许可证，而是采用 “BSD+Patents license” 许可证组合授权其大部分项目，该协议组合也被称为 FB+PL 组合。

其中，BSD 是指 BSD3-clause license，是被 OSI 和 FSF 都认可的开源软件许可证，也是被业界称为“宽松型”的开源许可证。

正是这个“宽松型”的 BSD 许可证附加了专利条款的开源许可协议，已经被 ASF 列为 “Category X”，杜绝了任何以 FB+PL 授权的软件进入 Apache 项目中的可能性，等于 FB+PL 已被 Apache 明确打入冷宫。

FB+PL 协议中，BSD3-clause license 本身没有问题，问题自然就出在 Facebook Patents license，即 Facebook 开源软件组合协议 FB+PL 中的附加专利许可条款。

以下是 Facebook Patents license 条款内容：

Additional Grant of Patent Rights Version 2

"Software" means the React software distributed by Facebook, Inc.

Facebook, Inc. ("Facebook") hereby grants to each recipient of the Software
("you") a perpetual, worldwide, royalty-free, non-exclusive, irrevocable
(subject to the termination provision below) license under any Necessary
Claims, to make, have made, use, sell, offer to sell, import, and otherwise
transfer the Software. For avoidance of doubt, no license is granted under
Facebook's rights in any patent claims that are infringed by (i) modifications
to the Software made by you or any third party or (ii) the Software in
combination with any software or other technology.

The license granted hereunder will terminate, automatically and without notice,
if you (or any of your subsidiaries, corporate affiliates or agents) initiate
directly or indirectly, or take a direct financial interest in, any Patent
Assertion: (i) against Facebook or any of its subsidiaries or corporate
affiliates, (ii) against any party if such Patent Assertion arises in whole or
in part from any software, technology, product or service of Facebook or any of
its subsidiaries or corporate affiliates, or (iii) against any party relating
to the Software. Notwithstanding the foregoing, if Facebook or any of its
subsidiaries or corporate affiliates files a lawsuit alleging patent
infringement against you in the first instance, and you respond by filing a
patent infringement counterclaim in that lawsuit against that party that is
unrelated to the Software, the license granted hereunder will not terminate
under section (i) of this paragraph due to such counterclaim.

A "Necessary Claim" is a claim of a patent owned by Facebook that is
necessarily infringed by the Software standing alone.

A "Patent Assertion" is any lawsuit or other action alleging direct, indirect,
or contributory infringement or inducement to infringe any patent, including a
cross-claim or counterclaim.

就是以上这段不算长的附加专利授权条款，让不少开发者甚至开源社区组织顾虑重重。

对开源运动有了解的人可能都知道，开源社区对专利非常敏感，甚至有开源大佬和前辈毫不掩饰对软件专利的厌恶和痛恨。更甚者，国外有专门的反软件专利组织，但毕竟专利制度是很多国家的法律制度，不可能受某个人或某一个群体的人的意见而转移。

因此，开源社区能做的就是改变自己以及影响自己可以影响的人，所以不少开源软件许可证都有针对专利的规范条款。

不过，对于 Facebook 附加专利许可协议，开源圈内人士从一开始都不是特别待见。甚至一些反对软件专利的人认为 FB+PL 协议关于专利的授权，拥有这样的专利授权比没有这样的授权更糟糕。

究其原因，从以上 Facebook Additional Grant of Patent Rights（附加专利授权条款）可以看出，该协议是一个单边优惠协议，授予人和被授予人的权利不平衡。

简单说就是基于 FB+PL 授权的软件使用者以及基于 FB+PL 开发衍生代码的开发者，与 Facebook 的权利不平衡。一旦被许可人对 Facebook 及其子公司甚至关联公司提出直接的或间接专利诉讼，无论该诉讼是与所涉及项目有关还是无关，亦或是硬件专利诉讼，甚至是 Facebook 主动提出的专利诉讼而被告者进行的专利反诉，该协议授予用户的专利权利即刻自动终止。

另外，2015 年 4 月 10 以前，Facebook Additional Grant of Patent Rights 第一版中，针对 Facebook 任何形式的诉讼，包括反诉、以及与专利无关的诉讼，都会导致基于该协议的专利授权自动终止。后来由于社区人员对该条款争议较大， Facebook 进行了修改，也即是目前的第二版。

值得一提的是，在众多的开源许可证中，有专利权利终止以及许可证权利终止条款的许可证并不少见，例如，Apache2.0 以及GPLv2/v3 都有关于权利终止的条款约束。之所以 FB+PL 会有如此强烈的反应关键有两点：

1. FB+PL 专利终止条款过于宽泛；
2. FB+PL 专利条款使得被授予者与 Facebook 之间的权利不平衡。

从另一个层面上讲，Facebook 附加专利授权条款的存在也不是全无道理，毕竟开源软件无时无刻不在承受着来自软件专利的威胁。尽管这些年软件专利没有成功将开源运动送入坟墓，反而使其不断壮大，而开源社区对专利的排斥和恐惧却已深入骨髓。

Facebook 作为开源领域一员猛将，并且已经开源了大量的代码和技术，将所有可能导致侵权的专利技术授权给用户。另一方面，为了自身防护的原因，想办法建立一种自保的机制也在情理之中，毕竟谁都不想成为被鱼肉被屠宰的一方。

整体来讲，Facebook 附加专利授权条款是一个带有严格的惩罚性措施的协议，其严厉性特别表现在其第一版，虽然在第二版中，将诉讼范围限定于专利诉讼，但在许多人看来其范围依然是过大。

Facebook 附加专利授权条款有一种过激的表现，但是如果你能想象一个刚刚崭露头角的少年，还未有可观的积蓄（专利），在群狼环嗣，个个武装到牙齿的对手面前，那种本能的警惕，也许会对 Facebook 多少有点理解。

毕竟，即便 Facebook 附加专利授权条款在严格，对于个人开发者，以及不喜欢搞专利诉讼的组织来说，大家彼此相安无事，也不失为一件好事。

就我个人来讲，我对 Facebook 之于开源的真诚性是认可的。

目前，虽然“ 开源软件 （ Open Source Software ） ”和“ 自由软件 （ Free Software ） ”两种哲学理念还存在分歧，但很多社区以及组织包括像 Facebook 这样自我保护略显偏激的组织，都是开源/自由软件理念真诚的践行者。还有一部分像微软一样“从良”的，也为开源做了不少贡献，像这种老牌的商业公司背负了太多的包袱，一下子转身可能性不大。

当然，浑水摸鱼以及投机的分子也肯定不少。不过，开源是软件开发的未来趋势和必然走向，开源理念不仅避免了重复开发中时间、人力和资金了浪费，更是智力共享、集体智慧的完美实践。

因此，虽然目前开源运动还存在着种种的冲突和矛盾，但就像所有的新生事物一样，从萌芽到成长再到成熟都会有一个过程，而在这个过程中磕磕绊绊在所难免。

整体上说，这次 Apache 对 Facebook 附加专利授权条款下禁止令，只是开源运动在一件小事，而开源的生命力正是在这种碰撞、冲突和磨合中逐渐显现，慢慢成熟。

（题图：react-etc.net）

作者简介：付钦伟，专利代理人、专利咨询师，任职于集慧智佳知识产权咨询公司。研究生选专业“误入歧途”，进入高大上的知识产权领域，目前从事专利咨询分析工作，励志为中国知识产权事业抛头颅、洒热血。