原标题：汉坤 • 观点 | “未履行开源许可证义务的专有软件不受法律保护” — GPL抗辩的探讨（上）

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

在专有软件中使用开源软件但未履行开源许可证义务可能会影响专有软件权利人的后续行权。我们注意到近期南京市中级人民法院（“南京中院”）在一起涉及开源代码的软件著作权侵权案（（2021）苏01民初3229号）中，首次支持了被告的“GPL抗辩”，驳回了原告的侵权主张

1。根据南京中院在本案中确立的裁判规则，在计算机软件著作权侵权案件中，如果作为原告权利基础的计算机软件使用了GPL开源代码而未履行开源义务，权利人就该计算机软件所享有的著作权将不再得到法律保护，第三人可使用专有软件相关代码而无需承担侵权责任。南京中院在本案中的裁判观点为使用开源软件的企业提出了更高的合规要求，值得业界关注。

本文将以案涉GPL开源软件为切入点，从技术分析和法律适用层面逐步厘清法院对GPL抗辩的审理思路，辨析GPL抗辩的法律依据，并最终就企业合规给出建议。我们对该案件的分析将分为上下两篇，本篇主要从技术层面出发，分析GPL v2及Classpath Exception的适用问题；下篇主要从法律适用的角度探讨GPL抗辩成立的法理基础。

目次

1. 案件简述

2. 何为Classpath Exception？

3. 涉案开源软件是如何与原告的其他代码通信的？

4. 原告软件是否被GPL组件传染？

5. 原告软件是否适用Classpath Exception？

6. 案件之外：企业开源合规启示

一、案件简述

本案中，原告研发了“未来软件—投标文件制作工具”软件，该软件使用了开源软件SharpZipLib（适用GPL v2.0 with Classpath Exception许可证

2）。原告认为被告所开发的“云蜻蜓软件-投标文件制作工具”使用了其软件代码，且被告对代码亦存在接触可能性，因此以软件著作权侵权为由将被告诉至法院。被告认为，原告软件使用GPL组件，整体被GPLv2协议约束；即便认定原被告软件构成实质性相似，被告也因和原告存在GPL许可关系而不构成侵权。此外，原告未以GPL协议开源其代码，属于违反诚实信用原则，不应该支持其侵权诉讼请求。

法院最终认定，原告在主程序中使用了GPL组件，且其使用方式不满足Classpath Exception，原告负有将其软件代码以GPL协议开源的义务但未履行，不支持就相关代码的侵权诉讼请求。原告开发软件的预览程序未使用GPL代码，被告对该部分代码的使用侵犯了原告的著作权，需承担惩罚性赔偿的法律责任。

二、何为Classpath Exception？

涉案开源软件为SharpZipLib，主要功能是实现文件压缩，采用GPL v2.0 with Classpath Exception许可证。根据该许可证要求，如果在使用过程中将SharpZipLib与独立模块链接以生成可执行软件，那么最终形成的可执行文件因满足Classpath例外，而不受GPL协议约束，无需履行许可证义务。

Classpath Exception（也称Classpath例外）的原文及译文我们摘录如下:

Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

将此库与其他模块静态或动态地链接就是基于该库制作组合作品。因此，GNU 通用公共许可证的条款和条件涵盖了整个组合。

作为一个特殊例外，此库的版权所有者允许您将此库与独立模块链接以生成可执行文件，而不管这些独立模块的许可条款如何，并根据您选择的条款复制和分发生成的可执行文件，前提是对于每个链接的独立模块， 您还满足该模块许可证的条款和条件。独立模块即不从该库派生或基于该库的模块。如果您修改此库，则可以将此例外扩展到您的库版本，但您没有义务这样做。如果您不希望这样做，请从您的版本中删除此异常声明。

追根溯源，Classpath Exception并非由SharpZipLib作者首创，其最早出现在为Java程序设计而开发的OpenJDK开源项目中

3。

Java应用程序的开发需要使用JDK（Java Development Kit）将编写好的源代码文件转换为可供运行的应用程序。在此过程中，编写好的源文件.java在JDK中编译成.class字节码文件，JVM再将.class字节码文件翻译为机器可读的机器码（二进制语言）

4。在解释器（interpreter）进行解释的过程中，链接（link）操作将会被执行

5，目标程序（开发者自有部分）与被调用的库函数（存在于JDK中）将被链接在一起。

OpenJDK是常用的开源的JDK，早期版本适用GPLv2协议。而根据GPLv2协议，链接将导致GPL 下的传染问题。因此，通过OpenJDK进行源代码编译将导致整个软件需按照GPL协议开源，这对于Java生态而言是极不友好的。针对该问题，OpenJDK的项目作者在GPL v2.0上附加了Classpath例外

6，允许用户通过静态/动态链接方式使用OpenJDK而不履行开源义务。

图1 Java应用程序与JDK的关系

通过对GPL协议设置例外，以促进开源软件传播的情形并不少见。例如，开源软件MySQL即设定了 Universal FOSS Exception，允许MySQL与特定开源软件通过接口通信而不需履行开放源代码的义务

7。

三、涉案开源软件是如何与原告

的其他代码通信的？

回归本案，本案中法院已查明原告软件中就开源软件SharpZipLib调用方式是基于函数的调用，其调用方式见下图所示：

图2 涉案软件与开源软件SharpZipLib的关系

欧易(OKX)

用戶喜愛的交易所

立即注冊立即下载

币安(Binance)

已有账号登陆后会弹出下载

立即注冊立即下载