为节省篇幅，以下对案情进行摘要和总结，详细案情可见一审链接和二审链接。
经过一审和二审对事实的调查和确认，两柚子认可：
数字天堂是HBuilder软件的著作权人；
数字天堂拥有HBuilder软件中的代码输入法功能插件、真机运行功能插件、边改边看功能插件源代码著作权；
两柚子的APICloud软件中对应插件源代码部分与涉案的三个插件具有同一性。
基于此，针对本著作权侵权控诉，两柚子抗辩理由只有GPL开源许可协议这一个突破口。而二审中对涉案代码量、侵权产品数量的认定，以及基于此对赔偿额的认定，只是量的维度问题。
开源许可证是法律文件法院虽然默认了GPL协议具有约束力，即类似于协议或合同的法律效果，但并未进一步将GPL协议条款基于我国著作权法进行解释。社区内关于GPL协议的解释，特别是关于GPL传染性的解释是基于美国版权法，其能否为国内法院认可，依然存在不确定性。
随着开源理念的深入以及开源软件在世界范围内的普及，本案作为中国GPL第一案，对未来开源软件相关的诉讼意义重大。稍有遗憾的是，两审法院并未就开源软件以及GPL协议的关键问题进行阐述。当然，也不可能期待GPL问题通过一次诉讼案件完全解决，未来还需要更多的法律、学术、技术等人士贡献智慧。
关于一审认定的思考既然法院确认了GPL协议的法律约束力，那么对GPL协议的解释要么采取社区通说解释，要么基于我国著作权法作独立解释。否则很容易出现矛盾或模糊，以至于增加企业开源实践中的法律不确定性。
关于GPL协议约束力范围（传染性），一审法院以涉案的三个插件可以独立运行，分别存放在三个独立的文件夹中且三个独立文件夹中无GPL许可证，据此认为涉案三个插件不属于GPL协议中所指应被开源的衍生产品或修改版本。
GPL许可证中有关的原文如下：
结合GPL协议条款和GNU官网对于GPL传染性的解释，一审法院这一认定是值得商榷的，就像你不能认为总部在西城的A公司与其在昌平拥有独立办公场所的分公司B是完全独立的，这需要从A和B之间的财务、人事、业务等是否独立为基础判断。
同理，GPL模块A与模块B之间是否独立，绝对不能以A和B是否位于独立的文件夹中来判断，还是需要从A和B之间的功能关系、通信关系、调用关系、依赖关系等来判断。
插件相对于主程序是否独立，需要看：
插件的使命，是否为该主程序而存在；
插件与主程序的交互方式，如管道、队列、函数调用；
交换消息的密切性(intimatecommunication)；
是否有例外声明等。
一审法院在确定赔偿额的时候又一次指出三个涉案插件是三个独立软件作品。一审法院从审判认定到赔偿衡量是一致的。这里，两柚子并没有就涉案三个插件的独立性进行抗辩，而这一点对GPL是否构成传染非常关键，在一审中被告代理律师对GPL许可证条款的理解也存在局限。
关于二审认定的思考首先，二审中两柚子再次提出司法鉴定来否定涉案三个插件独立性，可能是准备利用GPL传染性中关于独立作品的认定来抗辩。不过，法院认为二审诉讼中再次提出第三次鉴定申请，有违司法程序公正和司法程序效率，即二审法院基于程序公正的角度考量不予准许。同时，二审法院认为两柚子提出的新的司法鉴定申请内容与本案待证事实之间无直接关联性，这一点是值得商榷的，因为GPL中作品是否独立直接影响作品是否受GPL约束，进而直接影响本案关于侵权的认定。二审法院的否决理由，直接回避了可能对GPL传染性问题的讨论。
其次，二审法院认定数字天堂现有证据不足以证明涉案三个插件可以独立于HBuilder开发工具软件中的其他程序独立运行，但针对不独立的插件却没有进一步讨论这种不独立是否能够进行GPL开源抗辩。也就是说，一审法院基于作品的独立认定GPL抗辩无效，二审法院采取了一审对GPL抗辩的意见，但却否定了作品的独立性这一前提。
是否为独立作品的认定直接决定作品是否属于衍生作品(derivativework)或修改作品(modifiedversion)，进而直接影响是否受GPL约束。
当然，我们可以这样解读二审法院对于作品独立的认定，即GPL许可证里所说的作品的独立性，和一审、二审法院判决赔偿额对插件独立的认定是不同维度/层次，这是说的通的。但仔细阅读一审判决可知，法院在否决GPL抗辩中和赔偿额判定中对独立的认定是一致的，二审认可了一审对GPL抗辩部分的认定，却否决了赔偿额中对独立作品的认定，本身前后有矛盾嫌疑。
笔者认为，如果按照上述：GPL传染性中独立性判定和对侵权作品数量中独立性判定是不同维度的独立性判定的假设，至少二审中需要重新认定GPL传染性的问题，从而将两个维度的独立性认定区分开来。
关于两柚子诉求理由的思考两柚子在二审中再次申请司法鉴定：
涉案三个插件是否可以脱离Eclipse主体软件在Windows环境中独立运行；
将涉案三个插件源代码编译为插件以验证插件能否在Eclipse主体软件中独立运行；
任意删除Hbuilder软件目录下的一个或多个以“org．eclipse”、“org．apache”、“com．aptana”为前缀的文件或目录JAR文件以验证涉案三个插件能否正常运行……
关于这三个补充鉴定事项，首先，笔者认为两柚子或者其律师在开源上做足了工作，但其中依然存在问题。首先，插件独立于Eclipse主程序，并不一定需要插件可以脱离Eclipse主程序在Windows中独立运行。插件的独立性在于：插件有明确的功能，可用于特定的主程序，但不依赖于特定的主程序。最后，主程序脱离插件，应当且必须可以独立运行，并且不损失主程序本身的所有功能。
再看诉讼本身基于以上认识，我们再回头看看案件本身。首先说明，因本案需要进行多处技术鉴定，笔者无法也没有精力一一取证，仅仅基于几个假设，再捋一下GPL相关的问题。笔者认为，关于本案GPL传染性的认定需要从3个方面来看：
Eclipse主程本身；
基于Eclipse主程序的GPL插件；
涉案插件与主程序，以及涉案插件与上述GPL插件的关系。
为方便读者理解，引用数字天堂代理律所对一审结果评述的一张图。
（1）从Eclipse主程序看APICloud和HBuilder都是基于主程序Eclipse平台，包含第三方开源插件+各自自研插件组成的集成开发环境IDE。
首先，主程序Eclipse是采用EPL（EclipsePublicLicense）许可证公开，EPL与GPL不兼容。即便是2017年8月发布的版本虽然添加了次级许可证选项，但其与GPL依然是不兼容的。因此，HBuilder作为下游产品，其对Eclipse的包装分发不能变更Eclipse许可证。
其次，针对插件来说，无非是拓展Eclipse某一特定的功能，任何非Eclipse本身的第三方插件，可以说对于Eclipse主程序来说都是非必须的。其第三方公司开发的Eclipse主程序的插件，按照EPL传染性的规定，一般不视为EPL的衍生作品，不受EPL约束。
最后，需要强调的是EPL虽然是弱Copyleft许可证，但其依然是类似于GPL的具有“传染性”的许可证，其在给予用户更大使用方便的同时，对自身软件的Copyleft保护依然很强。因此，下游软件开发者在处理EPL软件和GPL软件时，需要认真对待它们的兼容性问题。
（2）从Aptana插件看Aptana在2006年推出时，以发布，并于2017年9月21日修改为和APL（AptanaPublicLicense）双许可。APL不是开源/自由软件许可证，可以认为是商业许可，但对于非分发的内部使用是免费的。
Aptana作为主程序Eclipse的插件，由于EPL和GPL不兼容，Aptana中的GPL插件要和以EPL许可的Eclipse主程序连接，必须在GPL许可证里作例外声明。毫无疑问，笔者在Aptana官网找到了例外声明，即关于独立作品的GPL传染性例外声明，以及聚合程序的GPL传染性例外声明。部分内容如下：
从以上GPL例外中可以看出，Aptana只是部分限定了“衍生作品”解释，也就是运行采用GPL许可证的Aptana与像Eclipse这样独立的程序交互不会发生传染，仅此而已。而如果修改Aptana，将其他程序并入AptanaStudio，或者将Aptana与其他程序进行整合的作品依然受到GPL协议约束。简单的说，加入GPL例外的GPL程序依然是GPL程序，这一点必须强调。关于这一点，Aptana官网还专门有问题解答：
数字天堂认为，其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调查与风险应对、专利信息应用、开源软件风险与合规指导。
