没有无义务的权利：从开源软件侵权谈GPL开源合规

一、GPL — 开源精神的推动者

GNU通用许可证（GNU General Public License，GPL）是开源软件领域最受欢迎的许可证之一，其为反抗上世纪八十年代软件商业化、私有化的产物[3]。为了建立一个自由、共享、互助的自由软件 区，并确保开源的软件不被后续的使用者在闭源项目中使用，理查德·斯托曼于1989年发布了最初版本的GPL许可证（GPL v1）。后来，为了避免专利和开源在同一个软件上的权利冲突，斯托曼在GPL v2中增加了新的许可章节，规定设立在同一软件上的其他法律许可不得与GPL许可证冲突，否则该许可必须在软件发行时完全撤销。GPL后续又针对软件 区新的实践需要，对某些条款进行了修改，并在2007年发布了GPL v3，至今仍备受企业青睐。

GNU宽松通用公共许可证（GNU Library/Lesser General Public License，LGPL），是在GPL许可证基础上主要为类库设计的开源许可证。在GPL许可证的使用过程中，斯托曼发现如果要求使用GPL许可证下的库必须开源，会导致这些本身期望不开源的项目转而选择使用其他非开源库，并不利于开源 区的发展。于是他将GPL许可证修改为更加宽松的LGPL v2.1，允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。同样地，LGPL在2007年发布了第三版。后来，为了对云服务商通过SaaS（Software-as-a-Service，软件即服务）服务等方式逃避GPL许可证义务进行限制，在GPL许可证的基础上又演变出了更为严格的AGPL v3（GNU Affero General Public License version 3）许可证及SSPL（Server Side Public License）。

二、 GPL — 会“传染”的开源许可证

GPL类许可证授予使用者在一定条件下对GPL类程序（Program）进行复制、修改和分发的权利。根据其文本，只要一个作品（work）衍生自（derived from）[4]GPL类程序，则该作品在复制和分发时，必须也采用相同的GPL类许可证进行开源。这就是所谓的GPL类许可证的“传染性”，这种“传染性”保证了其衍生作品以相同的许可证回馈给开源 区。

GPL类许可证存在“纵向传染性”和“横向传染性”两个维度。“纵向传染性”主要指GPL类程序会“传染”自身的修改版本（modifications）。如下图1所示，程序A适用GPL类许可证，则基于程序A得到的修改版本也要采用与程序A相同的许可证进行开源。“横向传染性”主要指GPL类程序会“传染”包含（contain）其全部或部分源代码或修改版的作品。如下图1所示，程序B包含GPL类程序A或其修改版，则程序B也要采用与程序A相同的许可证进行开源。

图1 GPL类许可证“传染性”示意图

三、争议频发 — 开源软件法律风险不容忽视

开源软件的授权人将其享有的著作权授予用户，其目的是创设一种自由开发、使用或传播的环境。当使用者违反了GPL类许可证限定的条款，其基于该许可证获得的授权将立即终止，开源软件的所有人可以向使用者主张著作权侵权。实践中，因使用者未合规使用开源软件产生的纠纷日益增多。

(一) 诉权的行使：著作权人无需贡献者的授权或同意即可提起诉讼

本案中，深圳中院根据 “罗盒（VirtualApp）V1.0”著作权登记证书记载的著作权人及Github 站上的开源软件VirtualApp载明的项目发起人Lody为原告法定代表人及股东等相互印证的事实，认定原告对涉案软件享有合法权利。其次，深圳中院亦明确原告提起本案诉讼无需贡献者的同意或授权，因为本案项目人对“主分支”中VirtualApp源代码的形成起到了决定作用，而贡献者的内容未对涉案软件著作权产生实质性影响，且贡献者亦应按照GPL v3协议许可其贡献；贡献者通常人数众多、互不相识又身居世界各地，要求原告获得全体贡献者的一致同意或授权将导致维权行为无从谈起。

(二) GPL v3许可证的性质：授权人与用户订立的著作权许可协议

在判决中，深圳中院明确认定GPL v3许可证是授权人与用户间订立的著作权协议，属于我国《合同法》调整的范围。深圳中院认为，开源许可证已经成为国际行业内共同认可和遵守的契约文本，履行相关义务也是诚实信用原则的体现。首先，GPL v3协议属于发生私法上效果的意思表示，而意思表示是民事法律行为的核心要素，因此GPL v3协议是一种民事法律行为，用户在对源代码进行复制、修改或发布时许可证成立，同时许可证发生法律效力；其次，GPL v3协议以电子文本方式表现其内容，而电子文本是一种有形的表现形式，属于以书面形式订立的合同。

此外，在（2018）京民终471 案和（2019）最高法知民终663 案中，北京市高级人民法院和最高人民法院亦分别间接认可了GPL许可证的法律效力。

(三) GPL v3许可证的特性：具有“强传染性”

(四) 违反GPL v3许可证的后果：授权终止并构成著作权侵权

深圳中院的这一认定符合包括GPL v3许可证在内的绝大多数开源许可证的目的追求，即只有在严格履行相关义务的前提下才能享受许可证赋予的权利，如果违反许可证规定的使用条件，未经许可的使用行为即构成著作权侵权。

在确定本案侵权损害赔偿额时，深圳中院综合考虑了多方面因素，包括涉案VirtualApp在侵权软件中所起的作用（即技术贡献度），侵权软件的下载次数和盈利方式，被告的财务数据，VirtualApp商业版本对外授权许可的情况，被告的侵权行为性质、侵权时间及拒不履行开源协议的情况及维权合理支出等，最终酌定赔偿数额为50万元。开源许可协议缔约方式和缔约主体的特殊性导致了违约或侵权行为更具隐蔽性。法院酌定支持原告的损害赔偿诉请，也体现了法院保护开源软件著作权的明确态度。

近年来，为了解决著作权领域长期存在的违法成本低等问题，2020年新修订的《著作权法》加大了侵权损害赔偿的力度，不仅调整了侵权损害赔偿的计算方法和适用次序，还将法定赔偿额上限由五十万元调高至五百万元[5]。此外，增加了侵权惩罚性赔偿制度，明确规定对故意侵害著作权或者与著作权有关的权利，情节严重的，可以按照损失赔偿额的一倍以上五倍以下给予赔偿。这无疑加大了著作权侵权的违法成本，也对打击重复侵权等行为具有震慑作用，同时也为使用开源软件进行项目开发的企业敲响了警钟。

四、技术+法律 — 防范GPL“传染”风险

开源软件促进了知识共享，在很大程度上避免了重复开发。但是如上所述，违反开源软件许可证也会带来巨大法律风险。企业在使用开源软件时需要全面进行合规分析，采取必要措施防范法律风险。

(一) 确定具体的GPL类许可证文本

根据GNU官 ，GPL许可证常用的有2.0和3.0版本，LGPL许可证常用的有2.1和3.0版本。需要注意的是，不同版本的GPL/LGPL许可证均处于有效、独立、共存的状态，其并非更新替代关系。而且，不同版本许可证规定的权利和义务亦不尽相同。授权人可以选择某一特定版本的许可证，也可以声明用户有权选择该特定版本后的任一版本，以使软件可以受到后续版本许可证的保护。

通常，GPL类许可证的版本 较容易确定。如果所使用的开源软件是通过开源 区下载，那么开源 区通常会对该软件所适用的许可证类型和版本 等信息进行明确标示；如果开源软件提供者并未进行标示，通常也可以在该软件的源代码文件中找到完整的特定版本开源许可证文本，常见的文档有LICENSECOPYINGCOPYRIGHT或直接以特定许可证名称命名的文件等。

(二) 确定是否存在触发GPL类许可证 “传染性”的行为

实践中，可以将开源软件的使用场景分为自用（即不分发）和分发两种。GPL类许可证的“传染性”通常只有在分发时才会被触发。

自用的外延较广，个人使用、公司员工/部门使用，甚至是在公司内部分发都属于这里的自用。此外，对于编译器等工具类软件，其主要作用是对代码进行加工，亦可以归为自用。此时，通常不会触发GPL/LGPL许可证的传染性，即不会被强制开源。值得注意的是，对于采用GPL/LGPL许可证的软件，如果以在服务器/云上以SaaS（Software-as-a-Service，软件即服务）方式对外提供服务，也被认为属于自用的范畴。但是，AGPL许可证要求在修改源代码的情况下以远程 络交互（Remote Network Interaction）方式提供服务，同样需要提供源代码。

分发（distribute或covey）是指能够使第三方获得开源作品的传播方式，因此使用电子邮件、U盘、 页链接、私有化部署等方式提供给用户下载或安装GPL许可证下的开源软件都视为构成分发。如果构成对开源软件的分发，则可能会触发GPL/LGPL许可证的开源义务，此时需要审查评估项目与GPL/LGPL软件之间的关系，即判断二者是否相互独立。如果是，则不会被“传染”；如果不是，则需要采取相应的技术措施来避免被“传染”。

(三) 通过技术手段避免GPL类许可证的“传染性”

01

通过隔离地址空间方式避免被GPL许可证“传染”

GPL许可证的传染性较LGPL许可证强，动态链接或静态链接方式均无法避免被GPL许可证“传染” [6]。因此需要采取更严格的隔离措施实现自有代码与GPL许可证下的软件的真正相互独立。

Free Software Foundation对“聚合版”和“修改版”的对比解释说明提供了规避GPL协议“传染性”的解决方案[7]。Free Software Foundation认为，“聚合版”包含有多个独立的程序，并在同一个CD-ROM或其他媒体上发行。如果两个模块都包含在同一个可执行文件里，那么它们一定是一个程序的组件；如果两个模块运行时是在共享地址空间连接在一起的，那么它们几乎也构成一个组合软件。反过来，pipes、sockets和命令行参数通常都是两个不同程序通信的机制。因此，如果使用它们来通信，这些模块正常应该是独立的程序。但是如果通信的语义非常密切，交换复杂的内部数据结构，那么它们也被会认为是一个大程序的两个组合部分 。

由上可知，通常可以通过采取管道（pipes）、套接（sockets）和命令行参数等通信方式使自研项目与GPL程序在相互隔离（非共享）的地址空间内运行来增强二者的独立性，以避免被“传染”，并被迫开放源代码。实践中，可以通过测试两个模块是否在不同的进程中运行来辅助确定二者是否位于非共享的地址空间。

02

通过动态链接方式避免被LGPL许可证“传染”

由于LGPL许可证最初目的为专门针对库而制定，采用LGPL许可证的库相对来说应该已经考虑了对调用程序的影响，更容易避免被“传染”[8]。根据LGPL v2.1许可证第6(b)条，采用共享库的机制将LGPL库与自有代码进行链接，且保证用户可以在接口兼容的前提下修改链接的库，此时自有代码不会被“传染”，用户可以自由选择整个作品使用的许可证。动态链接即为典型的共享库的机制。

如下图所示，在动态链接的情况下，LGPL库A不会分别和程序B1或B2编译成一个可执行文件C1或C2，而是在运行时由C1和C2共用同一个LGPL库A，此时C1和C2虽然和库A一起分发，但由于满足了上述共享库、接口兼容前提下可对库进行修改的条件，保证了后续版本的库A都可以在该作品中正常运行，因此可以避免被LGPL许可证“传染”。

图2 动态链接含义示意图

与动态链接不同，如图5所示，静态链接调用时，LGPL库A会被分别与程序B1、B2一起编译成可执行文件，此时在运行时两个文件不会共享LGPL库，用户无法实现对该库的修改。虽然根据LGPL v2.1许可证第6(a)条，用户可以通过提供1）除了LGPL库以外的部分的目标代码和/或源代码，2）LGPL库及其修改部分的源代码（以便后续用户进一步修改该库），来避免将自有部分开源，但由于该要求明显高于动态链接方式，且用户很可能并不希望将对LGPL库本身的修改进行开源，因此实践中通常会采用动态链接方式来避免被“传染”。

图3 静态链接含义示意图

(四) 审查是否履行全部许可证义务

如果自有代码被GPL类许可证“传染”，且未能采取必要技术措施避免，则必须按照该许可证的要求提供相应的源代码，如果违反该义务，将导致GPL类许可证在授权人与用户之间自动解除，用户基于协议获得的许可即时终止。除此以外，GPL类许可证还约定了其他义务，如要求使用者不能对许可证内容进行修改，在分发软件的同时需要为用户提供一份完整的相应协议文本，对GPL类许可证下的软件进行修改需要注明相应的修改信息，以及不同许可证间的兼容性等问题。

五、结语

开源 区的蓬勃发展为企业研发带来了巨大便利，所有开源参与者都有责任建立并维护一个自由、共享、互帮互助的开源 区。企业违反GPL类许可证不仅会导致无法使用开源软件，还会带来著作权侵权等诸多法律风险。新修订的《著作权法》及相关司法解释大大提高了著作权侵权成本，高判赔额已是大势所趋。对GPL类许可证的理解和遵守需要法律和技术相结合，企业应主动在战略层面重视开源合规工作，并在管理实践中建立技术开发人员、内部法务人员与外部律师的协作机制，在技术和法律层面全方位防控GPL类许可证的法律风险。

[2] 参见深圳市中级人民法院（2019）粤03民初3928 民事判决书。虽然本案一审判决可能还需要经过最高人民法院二审后才能生效，但深圳中院在一审判决中的相关论述仍具有较大研究和指引意义。

[3] [美]理查德·斯托曼：《自由软件，自由 会：理查德·M·斯托曼选集（第3版）》，北京GNU/Linux用户组译，第9页。

[4] 根据GP v2许可证第0条，衍生作品是指包含全部或部分GPL 程序（修改或未修改）的作品。

[5] 《著作权法（2020修订）》第五十四条第一至三款：侵犯著作权或者与著作权有关的权利的，侵权人应当按照权利人因此受到的实际损失或者侵权人的违法所得给予赔偿；权利人的实际损失或者侵权人的违法所得难以计算的，可以参照该权利使用费给予赔偿。对故意侵犯著作权或者与著作权有关的权利，情节严重的，可以在按照上述方法确定数额的一倍以上五倍以下给予赔偿。权利人的实际损失、侵权人的违法所得、权利使用费难以计算的，由人民法院根据侵权行为的情节，判决给予五百元以上五百万元以下的赔偿。赔偿数额还应当包括权利人为制止侵权行为所支付的合理开支。

[6] 参见GNU许可证常见问题 站，
https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic， 2021年9月10日访问。

[7] 参见GNU许可证常见问题 站，
https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation，2021年9月10日访问。

[8] 薛亮：《ABC时代，GPL许可证传染性问题探讨》，
https://linux.cn/article-9072-1.html，2021年9月10日访问。