汉坤知苑 | “未履行开源许可证义务的专有软件不受法律保护”——GPL抗辩的探讨（下）

2023-03-27 08:00:00

本文将着笔于法律层面的分析，就GPL抗辩是否存在法律依据，以及未履行许可证义务的专有软件是否有权获得著作权法上的保护与各位读者探讨。

作者 | 段志超鲁学振蒋海楠梁杰汉坤律师事务所

编辑 | 布鲁斯

在上篇中，我们对原告软件与开源组件SharpZipLib之间的通信关系进行了技术层面的剖析，并讨论了法院对GPL传染范围的界定标准以及本案是否满足许可证中规定的Classpath Exception。作为下篇，本文将着笔于法律层面的分析，就GPL抗辩是否存在法律依据，以及未履行许可证义务的专有软件是否有权获得著作权法上的保护与各位读者探讨。

目次

1.法院认定：被告就主程序的GPL抗辩成立

2.探讨：GPL抗辩的理据及适用边界

探讨1：主程序是否是侵权演绎作品？

探讨2：如果主程序是侵权演绎作品，其是否应予保护？

探讨3：诚信原则在本案的适用空间

3. 再思考：GPL的传染性与著作权法下演绎作品的交错

GPL协议文本：传染范围及于著作权法下的“演绎作品”

FSF 官方问答：通信机制已成为判断传染范围的行业惯例

一、法院认定：被告就主程序的GPL抗辩成立

基于对技术焦点的审理，法院认为原告的软件可分为主程序和预览程序两个部分，其中主程序受到GPL协议约束，而预览程序与主程序相对独立未受到GPL协议约束。就此，法院将原告的诉讼请求也对应到主程序和预览程序两个部分，并作出不同认定。

对于主程序，法院认为，因其受GPL协议约束但未履行开源义务，基于该部分的侵权主张不予支持。就该部分的逻辑，法院分两步展开：

第一步：由于主程序系GPL开源代码的衍生作品，受到GPL约束，原告未公开源码的行为违反了GPL协议，构成违约。违约行为导致授权人（即SharpZipLib权利人）与原告之间的许可授权自动解除，原告无权使用SharpZipLib开源代码。

第二步：原告在起诉被告侵权时未能从自身规范开源代码的使用，并证明自身代码的正当性，如果支持了原告的诉讼请求，将“导致一个不当、不法的行为人指责另一个实施相同行为的不当、不法行为人的逻辑怪圈”。在此基础上，“法院如果基于原告的该权利认定其他行为人构成计算机软件侵权，即会保护原告未来公司不当行为带来的收益，势必赋予其特殊法律地位和特别商事利益，不符合公平、诚信原则”，最终法院未予支持原告的侵权主张。

对于预览程序，法院支持了原告的侵权主张。考虑到被告存在持续侵权行为，主观恶意明显，原告要求被告承担惩罚性赔偿共计300万元。法院认为，预览程序不是涉案GPL开源代码的衍生作品，未被GPL开源代码传染，不受GPL协议的约束，在进行侵权行为分析时不受GPL协议的影响。

通过本案，南京中院在计算机软件著作权侵权纠纷中设立了GPL抗辩规则。该规则可被归纳为，如果被告可举证证明原告软件未履行GPL开源义务，那么就软件中受到GPL协议约束的部分，法院对原告的著作权侵权主张不予支持。前述受到GPL协议约束的部分是指被GPL协议所传染的代码，判断标准为是否“与原GPL软件密切通信使得二者高度牵连融合为一体”。换言之，软件开发者无法依据已被GPL传染但未开源的自有代码向未经许可的第三人主张著作权侵权。

二、探讨——GPL抗辩的理据及适用边界

涉及开源软件的民事纠纷尚不多见，南京中院在本案中为强化开源软件知识产权保护贡献了司法智慧，有利于促进开源软件的传播及构建开源生态秩序。南京中院在本案中提出的GPL抗辩的理据及其适用边界值得进一步探讨。

探讨1：主程序是否是侵权演绎作品？

在展开讨论之前，我们首先理清下著作权法下演绎作品的概念。演绎作品（同衍生作品）是利用已有作品的表达创作的新作品。演绎作品的作者享有著作权，但权利的对象仅限于自己的创作结果，不延及原作，演绎作品的作者在行使著作权之前必需征得原著作权人的许可。[1]

若将原告软件视为一个整体，原告软件可视为在开源软件SharpZiplib的基础上再创作而形成的新的作品，属于该开源软件的演绎作品。开源软件SharpZiplib适用GPL协议，如深圳中院法院在罗盒案[2]以及南京中院在本案中所认定的，GPL协议可理解为附解除条件的许可合同，因未履行GPL许可证义务，原告与开源软件权利人之间的许可合同自动解除。原告未经许可使用GPL组件，其软件产品属于侵权演绎作品。

640?wx_fmt=png

图1 将涉案软件整体上视为

开源软件的演绎作品

然而，司法实践也常将软件作品拆分为不同部分单独予以保护。本案中，南京中院认为，原告软件由主程序与预览程序组成，可以独立运行，各自构成独立的作品。这种将计算机软件作品拆分为多个作品予以保护的观点亦为最高院所认可。例如，在最高院审理的“不乱买诉闪亮时尚”[3]著作权侵权案件中，被告主张原告代码中含有大量开源代码，存在权属问题。对此，最高院认为“本案中不乱买公司明确其主张权利的代码为其后端代码而非前端代码，闪亮时尚公司并未举证证明不乱买公司后端代码中存在开源代码，闪亮时尚公司该上诉理由亦不能成立。”

640?wx_fmt=png

图2 将涉案软件分模块看待

那么独立的“主程序”是否是开源软件的演绎作品呢？如前所述，演绎作品是指在保持原有作品基本表达的基础上，增加符合独创性要求的新表达而形成的作品。[4]本案中，从源代码层面而言，原告的主程序由原告自主创作而成，体现了原告独立的智力成果，其中不包含开源代码，不涉及对开源代码的融合。在传统的著作权法理论下，主程序不属于在保持原有开源软件基本表达（即原作品）的基础上形成的演绎作品。

本案中，主程序通过链接的方式调用了开源软件，并与其进行了数据交换，这是否会影响主程序是否是开源软件演绎作品的认定？我们将在下文第三部分进一步展开分析。

探讨2：如果主程序是侵权演绎作品，其是否应予保护？

从司法实践角度而言，我国法院已在多个案件中确定了对侵权作品的著作权保护。例如，在（2015）民申字第119号案以及（2014）穗越法知民初字第437号案中，被诉侵权人都提出与本案GPL抗辩类似的不侵权抗辩逻辑，但法院均未予以认可。此外，我们还了解到在2011年由北京市第一中级人民法院终审判决的一起著作权侵权案件中，两审法院都对违反GPL协议的软件给予了著作权法上的保护，北京市第一中级人民法院在判决中强调“原告软件本身虽然是非法演绎作品，但其本身仍是创作活动的产物，原告付出了创造性劳动，原告对于软件享有著作权，有权禁止他人使用。被告关于原告软件应遵循GPL协议成为开源代码，任何使用该软件的第三方均不构成侵权的主张，本院不予支持。” [5]

从法理层面而言，侵权作品仍受著作权法保护符合知识产权的基本性质。知识产权的核心为禁用权，知识产权的享有不保证权利人有权使用智力成果，但权利人有权去禁止他人就知识产权客体的特定行为。[6]同样的，著作权专有权利的作用并不在于确认权利人有为某种行为的自由，而在于阻止他人未经许可利用其作品。[7]例如，违禁作品往往由于有悖于国家法律法规、社会道德而被认定为非法，但是并不影响违禁作品的著作权人对未经授权而出版、传播的行为主张侵权，并要求对方停止侵害。在本案中，尽管原告使用了开源代码而未履行许可证义务具有法律上的可责性（即原告存在侵权行为），但是权利有瑕疵并不等于没有权利，原告基于自有代码所享有排除他人未经许可的复制、使用的权利并不应被当然地剥夺。

因此，本文倾向于认为，即便是侵权作品，其在满足独创性要求，构成新作品的情况下，同样受到著作权法的保护，任何未经授权的复制行为都应在著作权法下得到制止。至于法院所关注的，原告是否违反了GPL协议，是否因未履行GPL开源义务而与案外人（开源软件权利人）存在违约/侵权纠纷等，这仅涉及原告是否有权使用软件中的开源代码，属于另案法律纠纷，不影响原告基于自己创作的满足独创性要求的新作品禁止他人的侵权行为。

探讨3：诚信原则在本案的适用空间

本案中，法院认为“开源许可协议已经成为国际软件行业内公认的有效契约文本，遵守协议文本规定也是信守诚实信用原则的体现”，“如果基于原告的该权利认定其他行为人构成计算机软件侵权，即会保护原告未来公司的不当行为带来的利益，势必赋予其特殊法律地位和特别商事利益，不符合公平、诚信原则”，基于此，法院进一步解释了不支持原告诉讼情况的合理性。法院这种将遵守开源协议等于信守诚实信用原则，并据此直接进行案件裁判的处理方式存在可探讨空间。

从司法适用的角度而言，诚实信用原则作为民法下的基本原则，其主要功能为填补法律漏洞，在法律没有具体规定时，诚实信用原则才可直接作为案件裁判的依据。[8]本案中，在著作权侵权的一般规则仍有适用余地的情况下，法院主动诉诸法律原则进行裁判有待商榷。

此外，即使遵守开源协议是诚实信用的体现，该诚实信用义务也仅存在于开源协议双方当事人而不是原被告之间。原告未履行开源义务的行为应由合同另一方当事人即SharpZipLib的权利人主张违约或侵权责任。本案中，基于自有代码提出侵权是原告与被告之间的法律关系，似乎没有适用基于开源协议文本所产生的诚信义务的空间。

诚实信用原则的适用还需兼顾社会秩序和公平正义[9]。本文倾向于认为，如果将创作过程中的违法行为和创作过程中的独创性混为一谈，否定作者对其智力投入而享有的著作权，且禁止其遏制下游的侵权行为，易引发侵权行为的持续扩张，也会对社会秩序产生一定的不利影响。

三、再思考——GPL的传染性与著作权法下演绎作品的交错

本案中，法院审理焦点始终围绕开源软件及其所适用的GPL许可证。就GPL的传染范围，法院给出了其判断标准——“确定被传染的部分应当是与原开源软件形成密切通信使得二者高度牵连融合成一体的程序，而非只要有数据交换就会构成传染”。南京中院的上述认定也是和行业实践中的惯常做法相一致的。

GPL协议文本：传染范围及于著作权法下的“演绎作品”

然而，就在业界广泛讨论GPL“传染性”，并试图从代码通信角度对“传染”这一概念进行解构并提出相应“隔离手段”时，我们似乎忽略了GPL协议中并没有“传染”一词。

通常认为，GPL的传染性源于GPL 协议中对程序（Program）一词的定义。以GPLv2为例，GPL v2第0条规定，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.”（下文中所说的“程序”指任何程序或作品，而“程序的衍生作品”指该程序或者著作权法下的衍生作品，即全部或部分包含了该程序的作品，无论是原样包含或做了修改，乃至翻译成了其他语言（后文中“修改”涵盖翻译）。每个许可获得者称作“你”。）根据该规定，GPL v2 的所能约束的计算机软件为“Program or any derivative work under copyright law”，意指开源软件本身以及著作权法下构成开源软件衍生作品（同演绎作品）的代码[10]。

GPL v2协议作者一方面拟借助著作权法下衍生作品的概念来限定开源义务约束的代码范围，但另一方面又未能明确具体适用哪一国家的著作权法对该概念进行解释，这导致实践中难以直接从法律角度对GPL协议进行解释。另一方面，GPL为格式合同且限制用户对协议文本进行修改，这进一步削弱了开源软件开发者主动向用户释明传染范围的动力。

FSF官方问答：通信机制已成为判断传染范围的行业惯例

鉴于法律难以就GPL传染问题给出标准并稳定的回答，而开源软件使用者有合法合规使用GPL组件的需求，使用者们将关注的焦点转移至了自由软件基金会（FSF）官方Q&A中。各种作为风险缓释措施的技术隔离手段也非来自GPL协议文本，而是基于FSF对GPL常见问题Q&A[11]的总结。

例如，FSF认为“究竟怎么区分是两个独立的程序，还是一个程序的两个部分呢？这是一个法律命题，最终会由法官来决定。我们相信合理的标准既依赖于通信的机制（exec、pipes、rpc、共享地址空间的函数调用，等等），也依赖于通信的语义（交换了什么样的信息）”。FSF从技术层面对何时相关代码属于开源软件的衍生作品，何时属于独立的程序进行了尝试性回答。实践中，这种回答也逐步取代了GPLv2协议文本中规定的 “derivative work under copyright law”而成为了某种行业惯例，并最终也影响了我国法院对GPL传染问题的理解。”可以认为，GPL的传染性判断规则正在与著作权法下演绎作品的概念逐步分离，这种概念的分化，也将更为深远的影响后续案件的审理。

注释

[1] 李琛，《知识产权法关键词》，法律出版社，第80页。

[2] 案号：(2019)粤03民初3928号

[3] 案号：(2019)最高法知民终663号

[4] 王迁《知识产权法教程》，中国人民大学出版社，2021年版，第225页

[5] “中国法院为什么保护违反GPL软件协议的行为？”https://law.wkinfo.com.cn/judgment-documents/detail/MjAxMDA0NDA5ODI%3D?searchId=279e320ef70946a7bdf7c77783bba2bf&index=1&q=GPL%20%E4%B8%AD%E5%9B%BD%E6%B3%95%E9%99%A2&module=

[6] 王迁《知识产权法教程》，中国人民大学出版社，2021年版第9页。

[7] 王迁《知识产权法教程》，中国人民大学出版社，2021年版第226页。

[8] 吴兆祥、陈龙业，《民法总则基本原则的解读》，载《民事审判指导与参考》2017年第1辑（总第69辑）。

[9] 李夏旭，《诚信原则法律修正功能的适用及限度》，载《法学》2021年02期。

[10] GPL v2将“Program or any derivative work under copyright law”解释为“a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language”。这和我国法律体系下对演绎作品的理解存在一定的偏差。例如，对开源软件少量的修改可能形成演绎作品，当综合GPL v2协议以及自由软件精神，修改后形成的新的版本（虽然未必构成演绎作品），也需要对外开源。

[11] https://www.gnu.org/licenses/gpl-faq.zh-cn.html#MereAggregation

联系作者

640?wx_fmt=jpeg