| 导读 | 近日, 北京市集佳律师事务所代理原告数字天堂（北京）网络技术有限公司，在诉被告柚子（北京）科技有限公司、柚子（北京）移动技术有限公司侵犯计算机软件著作权纠纷案件中获得胜诉：北京知识产权法院一审认定二被告侵权成立，应承担法律责任，包括：在被告官方网站及微信公众号显著位置向原告赔礼道歉、消除影响，支付损害赔偿与合理支出一百六十五万四千八百元。 |
本案不同于一般的计算机软件著作权侵权案件之处在于涉及 开源软件协议（《GNU通用公告许可协议》，GPL V3） 抗辩。随着开源协议在计算机软件开发过程中的重要影响不断凸显，法院在本案审理过程中的举证责任分配、事实认定及法律分析思路一方面对于类似案件的审判实务具有较高参考价值，同时对于国内开发者如何合法使用开源资源、如何合理维护自研软件的权利也具有重要的指导意义。
原告诉称，二被告通过其官方网站发布名为 APICloud 的软件抄袭了原告享有著作权的 HBuilder 开发工具软件中的三个插件（代码输入法功能插件、真机运行功能插件、边改边看功能插件）的源代码。二被告的行为侵犯了原告对 HBuilder 软件享有的复制权、修改权及信息网络传播权。
二被告辩称，原告的 HBuilder 软件是 GPL 协议下的开源软件分支，被告有权在 GPL 协议授权下使用其代码并构建衍生软件产品，无需经过原告许可，二被告行为未侵犯原告著作权。
代码输入法功能插件、真机运行功能插件、边改边看功能插件这三个插件，虽包含于涉案 HBuilder 软件，但其 均可以独立运行，且原告针对上述三个插件分别进行了著作权登记，故其属于独立的计算机软件作品，原告享有著作权，有权禁止他人以著作权法第十条所规定的方式使用该软件作品。
经过对被诉侵权软件和原告软件 源代码的同一性鉴定，法院认定：1、原告软件中只有一小部分源代码与第三方或开源软件相同；2、被诉侵权软件复制了原告软件中的绝大部分文件，只对其中小部分进行了修改，上述行为落入原告复制权及修改权的保护范围。并且二被告在其网站提供被诉侵权网站供用户下载，该行为则落入信息网络传播权的保护范围。
第一，原告的三个插件 均处于独立的文件夹中，该文件夹中 并无 GPL 开源协议文件。第二，在 HBuilder 软件的 根目录下也不存在 GPL 开源协议文件。因此该三个插件不受到 GPL 协议限制，不属于该协议中所指应被开源的衍生产品或修订版本，二被告认为原告软件为开源软件的相关抗辩理由不能成立。
律师评述
本案原告向用户提供的 HBuilder 并不是一个 .exe 安装文件，而是一个聚合了多个用户开发常用软件的 .zip 软件包。该软件包中涉及的文件及其框架结构如下图所示。其中：
Eclipse 是一个基于 Java 的可扩展开发平台。其本身只是一个框架和一组服务，用于通过插件组件构建开发环境。每个针对 Eclipse 平台开发的插件，都是运行于该平台的独立软件。
原告为 Eclipse 开发了多个功能插件，其中最为核心的是：代码输入法、真机运行、边改边看三个独立插件。
Aptana 同样是第三方 Appcelerator 公司为 Eclipse 开发的一些插件的集合，其中个别插件受开源协议 GPL V3 限制。
被告主张 Aptana 个别插件中所带的 GPL V3 协议具有严格的“传染性”，原告在将自研三插件纳入 HBuilder 整包发布时即受其传染而必须开源。这一逻辑到底是否能够成立呢？
回归到 GPL 开源协议本身，其作为自由软件运动的滥觞，所强调的是开发者之间自愿地通过授权协议形式来共享研发成果，确保已开源的代码不被闭源使用，而非攫夺他人研发成果的工具。其协议条款的设置完全尊重开发者著作权，也适应时代发展对可能存有争议的情形进行了明确阐释，以确保该协议的平等性、合理性和有效性。从 GPL 协议看，其对后续开发者发布程序的开源限制主要是针对基于原程序开发的衍生程序（a work based on the Program）或者修改（modifications）。结合第 5 条最后部分（如下）对“聚合体”形式软件的说明，原告认为开源协议的本质是开发者之间就原程序的后续修改和发布（即原程序衍生出的下游软件）进行的约定，其并没有对上游软件或者无衍生关系的第三方软件进行开源限制，也没有对后两者进行限制的事实和法理基础。
本案中 HBuilder 软件包中包括 C 代码、jre、 Eclipse 平台框架、 Aptana 插件、原告自研插件及其他第三方插件（可以从 Eclipse 软件市场方便地获取）。按照被告“全面传染”的逻辑，只要与 GPL 协议下的开源软件聚合在同一个软件包中，则不仅是原告三插件，连 Eclipse 平台框架、第三方插件都需要开源——那么只要将已知商业软件与任何 GPL 开源代码打包发布，世上就无不可开源的软件了。
事实上，与传统一个软件对应一份授权不同的是，当前市场环境下更多软件——尤其是使用了开源代码的软件——大都是以软件聚合体的形式发布，即软件包中不是单独、完整的一个程序，而是类似原告软件包这样的、涉及很多个独立软件的“聚合体”，“聚合体”中的所有独立软件各自有单独的授权。保障这些独立软件的“不被强行传染”，不仅是对当事人自主意思表示的尊重，也是开源软件能够在一定程度上消除开发者关于被强制开源的顾虑，被广泛采用、推广、普惠公众的一个基础。
本案的司法认定及判赔数额，对于包括原告在内的创新开发者而言，在反编译和抄袭乱象层出的当下也无疑是一颗重要的定心丸：其只要在开发过程中事先充分了解和研究不同的开源协议条款、选择符合开发预期的开源协议并诚实遵守，完全可以对有效维护自身权益保持信心，在自主研发的道路上奋马扬鞭.
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/118024.html