开源许可证GPL的法律效力及疆界

本文来自中国开源云联盟 本发布于2020.11.29 原文链接： https://mp.weixin.qq.com/s/hU0jf5A6p58F4q7Zc6CiRA

—— 兼论“柚子案”“不乱买案”两案终审判决

权利：
作者 詹毅，上海执业律师，华东政法大学兼职教授，微信ZhanyiAttorney。
声明：
传播本文时，请于文首呈现权利及声明。本律师个人观点，仅供参考，不构成法律意见书。

序言

近年来，随着开源操作系统Linux、Android的风行，以及开源在云原生、人工智能、大数据等新领域的大维度部署，开发、使用开源代码也在中国产业界普及开来，例如在操作系统、容器技术、微服务技术、DevOps技术上，都能看到中国企业的迅猛势头。由此而生的市场竞争日益激烈，与开源相关的法律纠纷也开始出现。
由于业界遵循的开源规则，主要来自于国外的开源许可证，例如，GNU GPL许可证项下的Linux kernel，Apache许可证项下的Android[1]、Hadoop等等。因此，中国的法律及法院怎么看待定义未来：开源法这些开源许可证，包括怎么来认知开源的性质，以及许可证条文是否具有法律效力，如果有，其效力范围或者说法律疆界在哪？对于产业的合规前行就显得十分重要。
要确定开源许可证GPL在我国法域内的法律疆界，碰到的第一个问题是，我国法院是否认可其法律效力。接下来，我们通过“柚子案”“不乱买案”的案情，先来探讨在GPL是否具有法律效力这一问题上，法院通过判决表明的态度。

一、“柚子案”判决认可了GPL许可证的法律效力

2019年11月6日，北京高级人民法院对“柚子”案作出终审判决，号称中国的GPL第一案[2]。所谓“柚子案”，是指柚子（北京）科技有限公司（简称柚子科技公司）、柚子（北京）移动技术有限公司（简称柚子移动公司，合称柚子公司）与数字天堂（北京）网络技术有限公司（简称数字天堂公司）侵犯计算机软件著作权纠纷一案。
在“柚子”案里，原告是数字天堂公司（也是终审程序的被上诉人），被告是柚子公司（也是终审程序的上诉人）。数字天堂公司开发了软件HBuilder，该软件包括三个插件：代码输入法功能插件、真机运行功能插件、边改边看功能插件。柚子公司开发了软件APICloud。
数字天堂公司认为，柚子公司的APICloud使用了上述三个插件的源代码，侵害了其对HBuilder享有的软件著作权，起诉到法院请求判决柚子公司承担赔偿损失等法律责任
柚子公司抗辩说，HBuilder使用了GPL项下的程序，因此这三个插件程序也应该适用开源许可证GPL，柚子公司可以自由使用，不构成著作权侵权。
一审法院判决，柚子公司构成著作权侵权，应赔礼道歉并赔偿数字天堂公司经济损失125万元，合理支出21万元。法院不支持柚子公司提出的GPL抗辩，理由是数字天堂公司的三个插件均处于独立的文件夹中，该文件夹中并无GPL开源协议文件。而且HBuilder软件的根目录下亦不存在GPL开源协议文件。根据GPL协议的相关规定，尽管HBuilder软件其它文件夹中包含GPL开源协议文件，但该协议对于涉案三个插件并无拘束力。
可以看出来，一审法院是根据GPL的条文来判断三个插件程序的性质，虽然结论是这三个插件不属于受GPL约束的衍生产品或修订版本，即不属于GPL上的“单独程序”（“单独程序”（separate and independent works[3]——GPL定义的一个法律原则，记住这个概念，本文将详细讨论它），但一审法院实际上承认了GPL的法律效力。
二审法院也终审判决柚子公司构成著作权侵权，仍然不支持柚子公司提出三个插件受GPL约束的抗辩，理由是一审庭审中，柚子公司认可涉案三个插件中并无GPL开源协议，在Hbuilder软件的根目录下亦不存在GPL开源协议，所以对柚子公司有关涉案三个插件应受GPL协议约束的主张不予支持。因此，二审法院也认可了GPL的法律效力。
但值得注意是，二审法院认为三个插件程序并不属于独立程序，涉案的只有一个独立程序即整体的HBuilder软件（本文第四部分将分析原因）。据此，二审改判柚子公司赔偿数字天堂公司经济损失50万元，合理支出21万元。

二、“不乱买案”判决也认可了GPL许可证的法律效力

2019年12月23日，最高人民法院知识产权法庭对“不乱买案”[4]作出了终审判决。所谓“不乱买案”，是指“北京闪亮时尚信息技术有限公司（以下简称闪亮时尚公司）与不乱买电子商务（北京）有限公司（以下简称不乱买公司）侵害计算机软件著作权纠纷一案”。 在“不乱买案”里，原告是不乱买公司（也是终审程序的被上诉人），被告是闪亮时尚公司（也是终审程序的上诉人）。不乱买公司开发了“不乱买时尚海淘软件”用于网站运营。闪亮时尚公司也开发了网站运营软件。
不乱买公司认为，闪亮时尚公司的相关代码文件使用了不乱买软件的源代码，侵害了其享有的软件著作权，起诉到法院请求判决闪亮时尚公司承担赔偿损失等法律责任。
一审法院判决，闪亮时尚公司构成著作权侵权，应停止侵权、消除影响并赔偿不乱买公司经济损失25万元及诉讼合理支出3万元。法院不支持闪亮时尚公司提出的GPL抗辩，理由是，根据GPL协议的相关规定，GPL协议的许可客体是在GPL协议许可下批准的受版权保护的程序以及基于该程序的衍生产品或修订版本。就该案而言，不乱买公司主张的权利的后端代码中已排除开源代码，不乱买公司虽在其前端代码中使用了开源代码，但其后端代码程序并非其前端程序的衍生品或修订版本，故根据GPL协议的相关规定，该协议对涉案权利代码并无拘束力。据此，闪亮时尚公司的相关抗辩理由不能成立。
可以看出来，一审法院再次根据GPL的条文来判断涉案程序的性质。只是涉案的问题是网站的后端代码，相对于前端代码，是否构成GPL意义上的“单独程序”？所以，一审法院也再次认可了GPL的法律效力。
二审法院终审维持了一审判决，并认同一审法院根据GPL规定的“单独程序”原则作出的判断。

三、GPL法律疆界的划定，本质上就是对GPL“传染性”的阻断

在认可GPL的法律效力以后，接下来的问题就是这个效力的范围有多大，即划定GPL的法律疆界。这样才能给开发、使用GPL代码的公司一个明确的合规指引，避免法律诉讼及承担赔偿责任。
在中国法律的适用空间范围内，GPL法律疆界的划定的问题，主要取决于中国的法院对GPL的核心内容——GPL“传染性”的认可程度。认可到哪里，GPL“传染性”就阻断在哪里。
“传染性”是开源许可证领域特有的一个法律概念，大体上涉及的问题有：如果对开源许可证项下代码进行修改，修改的代码要不要继续开源？如果继续开源可不可以选择其它的许可证？或者开发的软件，如果引入[5]了一些开源代码后，合并后的程序是否也要受到这些开源代码所属许可证的节制？
“传染性”具有相对性。这个相对性，就是说“传染性”是在各主要开源许可证之间比较出来的。我在《对“木兰”许可证的法律评论》一文里提出了一个“光谱条”，来表示各许可证“传染性”的强弱；并将GPL 3.0许可证（即GPLv3）与Apache 2.0许可证作了一个对比来说明这一问题[6]
通过对目前主流开源许可证的比较，可以得出这样的结论——GPLv3属于具有较强“传染性”的许可证[7]。GPLv3的“传染性”强，通俗地讲，就是程序内一旦有GPL代码，那么整个程序就被“传染”了，应当按照这个许可证来公开源代码，并在传播、传递过程中使代码可阅读、可修改[8]。
“不乱买案”的一个亮点是，最高法院在终审判决里对GPL的“传染性”给出了认定：“GPL协议的‘传染性’，应当是指GPL协议的许可客体不仅限于受保护程序本身，还包括受保护程序的衍生程序或修订版本，但不包括与其联合的其他独立程序。”[9]
“柚子案”的一审法院也明确提出，根据GPL协议的相关规定来审查GPL协议的许可客体。这即是GPL许可证规定的“单独程序”原则，法院以此来判断三个涉案插件程序是否受GPL的约束。
因此，从两案的终审判决来看，法院对GPL的“传染性”条文是认可的，即采用了GPL规定的“单独程序”原则，作为“传染性”阻断的依据，也就是划定GPL法律疆界的法律标准。需要说明的是，这一标准同时也是一个事实标准，或者说也是技术事实的判断问题，本文第四部分将对此进行讨论。
需要指出的是，法院以GPL“传染性”条文[10]作为划定GPL法律疆界认定的标准，并不会是无条件的全部接纳，而是要进行审查，采用具备合法性的部分。例如，根据许可证条文[11]，GPL会“传染”到部分引入了GPL代码的程序（例如，子例程的动态链接，或者少量（非实质性）使用GPL代码[12]），但法院会根据法律上的公平原则进行审查，如果发现显失公平的情况，则会通过判决对GPL认可的“传染性”进行阻断，达到GPL开源精神与代码版权保护之间的平衡。

四、GPL的法律疆界只能在个案中划定，但要考虑GPL的宗旨及性质

虽然法院接纳了GPL许可证的“单独程序”原则，但在什么情况下构成“单独程序”，从而阻断GPL的“传染性”，还存在一个具体分析、判断、认定的问题。本文认为，“单独程序”的判断、认定，首先是一个法律问题，理由很简单，这是一项划定开源软件许可证的法律疆界的工作，而非一项划定软件的功能模块的工作。
既然是法律问题，自然需要有法律上的方法。在“柚子案”里，法院使用的是“独立文件夹”测试法，但对于数字天堂公司的三个插件是独立的程序，还是HBuilder整体属于“一个”软件的问题，一审法院与二审法院的结论上存在较大的不同，下文会分析其原因。
一审法院认为，数字天堂公司开发的三个插件是“独立的软件作品”[13]，所处的文件夹中并无GPL开源协议文件，整个软件的根目录下亦不存在GPL开源协议文件。因此，虽然软件的其它文件夹中包含GPL开源协议文件，但无法“传染”到数字天堂公司的这三个插件。
而二审法院在终审判决里，继续坚持了“独立文件夹”的方法，但认为数字天堂公司开发的三个插件程序并不属于独立程序，否定了数字天堂公司的整个HBuilder开发工具软件构成GPL上的“聚合体软件包”[14]。
这里，一审法院所指的“独立的软件作品”，是法律意义上的，而非计算机程序技术意义上的，因此可以视为与GPL的“单独程序”原则在含义上相一致或者并不冲突。一审法院也进而运用“独立文件夹”来进行GPL“传染性”测试。对于解决一个法律问题而言，这在逻辑上是自洽的。
二审法院支持了一审法院的侵权判决结果，但否定数字天堂公司的三个插件是独立的程序。本文推断，其否定的目的，可能并非基于是否构成侵权的分析，而是基于判定侵权行为是一个还是多个、进而确定侵权的赔偿数额分析。因此，二审法院对于HBuilder是“一个”软件而非一个“聚合体软件包”的判断，应属于技术意义上的，否则会与判决结果产生较大的冲突。
而在“不乱买案”里，对于GPL“单独程序”的判断，法官使用了一个新的方法——“展示方式—所用技术—功能分工”测试法。
一审法院认为，不乱买公司的前端代码开发主要是指前端用户可见的操作界面如页面布局、交互效果等页面设计的一种实现方式，后端代码开发则主要是指后端用户不可见的服务端相关逻辑功能等模块的实现，二者展示方式不同、所用技术不同、分工亦有明显区别，属于可独立的程序。
二审法院也认为，前端代码与后端代码是可以分别独立打包、部署的。因此，前端代码与后端代码在展示方式、所用技术、功能分工等上均存在明显不同，不能因前端代码与后端代码之间存在交互配合就认定二者属于一体，原审法院认定前端代码与后端代码相互独立并无不当。……本案中，虽然不乱买公司认可其前端代码中使用了GPL协议下的开源代码，但其主张权利的是后端代码，其后端代码是独立于前端代码的其他程序，并不受GPL协议的约束，无需强制开源[15]。
这里，一审法院所称的“可独立的程序”，以及二审法院所称的“后端代码是独立于前端代码的其他程序”，其含义与GPL的“单独程序”相当，可以构成对GPL“传染性”的阻断。
然而，由于涉及的是计算机程序，“单独程序”原则同时也是一个技术问题。也就是说两个程序在技术层面的通信机制，也会影响到“单独程序”的判断。
从两案的终审判决的分析，我们可以看到，GPL“传染性”的阻断，即“单独程序”的认定问题，不管从法律上，还是从技术上，都需要根据个案的情况来判断，从而正确地划定GPL在软件技术具体实践里的法律疆界。但这并不是说没有一般性的标准。
除了“单独程序”原则作为一般的判断标准外，GPL的宗旨及性质也可以作为一个指导准则。在是否要将一个使用了开源代码的程序，从开源许可证构建的技术秩序里剥离，作为一个“单独程序”给予传统的版权专有保护时，可能还需要考虑一下GPL的宗旨。
GPL强调源代码的公开，强调用户的权利，主要保障用户对开源代码的使用、传播、修改、分享四个方面的自由[16]，也就是俗称的“自由软件”理想。因此，GPL对代码持续开源的关注与要求，性质在于代码开放，宗旨在于构建一个代码透明、自由分享的世界，以此来推动软件技术的全球性的大维度协作，叠续式推动更多更大的创新[17]。如果一个软件大量使用了开源代码，但仍然要对独立写出的一小部分代码主张传统的专有权利。在这个时候，法官不仅要考虑法律、技术上的具体判断方法，也要考虑一下这种情况是否符合开源法的精神。
需要补充说明两点。第一点，经过审判实践验证可行的具体方法，也有助于GPL法律疆界划定的确定性。例如，“柚子案”使用的“单独文件夹”测试法，如果经过更多的案例证实其可行性，就可以作为一个可反复适用的方法，“不乱买案”的“展示方式—所用技术—功能分工”测试法也是同样的道理。
第二点，“柚子案”的GPL“传染性”阻断问题，还涉及到主程序相关的开源许可证，与插件程序相关的开源许可证的“兼容性”[18]判断，本文不作讨论，但足见开源许可证“传染性”阻断问题的复杂性，同时也能说明GPL法律疆界的划定，只能是通过个案来明确。

小结

“柚子案”与“不乱买案”的判决，开启了GPL在中国的法律实践，从中可以得出以下初步结论：
1.中国法院认可GPL开源许可证的法律效力。
2.GPL“传染性”与“单独程序”原则相关。
3.对GPL“传染性”的阻断，就是对GPL法律疆界的划定。
4.GPL法律疆界的划定既是一个法律问题，也是一个技术问题，并与各开源许可证“兼容性”交织在一起。
5.GPL法律疆界的划定需要个案判断。
6.个案判断应以“单独程序”为原则，具体认定方法还需要审判实践经验的积累与总结。
需要补充说明的是，无论“柚子案”还是“不乱买案”，中国法院对GPL许可证的整体法律效力，保持了审慎的态度。法院在判决里只是认可了引用的GPL部分条文，即GPLv3的“定义部分”“第五条”“第七条”。
对于GPL的其他部分条文，其法律效力仍然有待法律的审查。例如，对于GPL项下开发的保护版权的技术措施程序，GPLv3的第3条并不禁止进行破解，甚至是为破解提供了一种合规保护。
而2020年11月11日全国人常委会通过的关于修改《著作权法》的决定[19]的第29条规定未经权利人许可，不得故意避开或者破坏技术措施，不得以避开或者破坏技术措施为目的制造、进口或者向公众提供有关装置或者部件，不得故意为他人避开或者破坏技术措施提供技术服务。而该决定第30条关于可以合法规避技术措施的几种情况，并不包括根据GPL许可证开发的程序。因此，GPLv3第3条的规定很可能违反了中国法律的强制性规定，其法律效力无法得到认可。

（以下无正文）

注释

[1]内核是Linux kernel，所以适用的许可证仍然是GPL2.0许可证。

[2] 北京市高级人民法院民事判决书(2018)京民终471号。实际上在此之前，浙江等一些地方法院审理的知识产权案件里，已经有涉及GPL理由的不侵权抗辩，只是判决未就此作出实质的回应。

[3] GNU GENERAL PUBLIC LICENSE，Version 3, 29 June 2007，https://www.gnu.org/licenses/gpl-3.0.en.html，2020年11月18日最近一次访问。

[4] 中华人民共和国最高人民法院民事判决书（2019）最高法知民终663号。

[5] “引入”在技术上一般是指直接的复制开源代码，有的许可证也指间接的以链接等方式使用库文件等技术事实。

[6] https://blog.csdn.net/kaiyuanshe/article/details/99619475，2020年11月19日最近一次访问。

[7] 强“传染性”许可证，即在光谱条上处于红色端的许可证，我认为是GNU AGPL许可证。

[8] 不同许可证项下的代码，能否组合在一个程序里？这样做在大多数情况下有利计算机科学的进步，也有利于软件的集成。这就涉及许可证兼容的问题，有时间将专门撰文讨论。

[9] 中华人民共和国最高人民法院民事判决书（2019）最高法知民终663号。

[10] 还包括FSF对条文的解释、说明。

[11] GNU GENERAL PUBLIC LICENSE，Version 3, 29 June 2007，https://www.gnu.org/licenses/gpl-3.0.en.html，2020年11月19日最近一次访问。

[12] 第二种情况取决于对GPLv3里“a work based on the Program”这一概念的理解。按照对GPL的一般说法，本文举例的情况应落入了该概念的范围。

[13] 北京知识产权法院民事判决书（2015）京知民初字第631号。

[14] an “aggregate”，https://www.gnu.org/licenses/gpl-3.0.en.html，2020年11月24日最近一次访问。

[15] 中华人民共和国最高人民法院民事判决书（2019）最高法知民终663号。

[16] https://www.gnu.org/licenses/quick-guide-gplv3，2020年11月25日最近一次访问。

[17] 开源的开放原则，具体可以参考《定义未来：开源法》。我在这篇文章里谈了对开源法的模型及其法律原则的设想，https://www.sohu.com/a/359358470_99915568，2020年11月25日最近一次访问。

[18] 主要涉及EPL、GPLv3、MIT等开源许可证项下的主程序、插件程序，还涉及主张非开源的插件程序。

[19] 全国人民代表大会常务委员会关于修改《中华人民共和国著作权法》的决定（2020年11月11日第十三届全国人民代表大会常务委员会第二十三次会议通过），http://www.npc.gov.cn/npc/c30834/202011/272b72cdb759458d94c9b875350b1ab5.shtml，2020年11月25日最近一次访问。