打开APP
userphoto
未登录

开通VIP,畅享免费电子书等14项超值服

开通VIP
开源软件项目合规审查涉及的GPL协议的传染性与研究

一、GPL开源软件许可协议的“传染性”概述

(一) GPL开源软件许可协议的法律性质

GPL开源软件许可协议的全称为GNU通用公共许可协议(GNU General Public License),该开源协议自1989年推出第一版本以来,目前已经累计推出了三个主要版本,最新版本为2007年推出的GPL.v3。GPL系列许可证一直是开源软件领域最受欢迎的软件许可之一。在三个版本中,最为常用的是GPL.v2。

GPL开源软件许可协议并非放弃软件著作权,而是通过强制性承袭适用GPL协议的方式,保障所有的开发者都能够取得概括性的获得和使用开源软件的自由(copyleft)。因此,开源软件许可协议的法律性质依然是著作权许可合同[1]。

另外,由于适用GPL协议开源软件的后续开发者均无权选择排除适用GPL协议,而仅有开源软件的最初版本开发者可以选择开源软件适用何种协议,因此GPL开源协议也是一种由最初版本开发者预先拟定的格式合同。尽管开源协议中的义务性条款颇为严格,且没有任何商议的余地,但是相较于需要支付许可费用的商业著作权许可成本和需要投入人力、资金和时间的软件研发成本,秉持自由、共享和免费的开源协议对保障软件行业的高速发展具有重要意义。因此开源协议中约定的义务未不适当地损害使用人的利益,是有效的格式条款[2]。

(二) GPL开源软件许可协议的“传染性”以及违反的法律风险

为保证开发者运行、学习、修改、分发副本等“自由”(copyleft)不被中断,GPL开源协议具有“纵向”和“横向”两个维度的“传染性”。

在“传染性”的“纵向”维度上,开源软件会“传染”自身的修改版本(modifications)或衍生作品(a work based on the Program)。例如GPL.v2授予后续开发者修改开源软件(及其副本)的权利,但是对于修改后形成的修改版本或衍生作品,一旦涉及到分发(distribute)或公布(publish),则应满足使得修改版本整体继续依照对应的GPL协议进行开源[3]。

在“传染性”的“横向”维度上,在一定的条件下,开源软件会“传染”自身及修改版本以外的,一同分发、传输的软件或软件的其他部分。例如,GPL.v3规定,如果在开发者传输[4]的软件时,开源软件与其他软件之间组合的目的是为了生成一个更大的程序,则其他软件也需要成为受到相应的GPL协议传染的开源软件[5]。

根据GPL协议的规定,如果违反“传染性”条款,将直接导致通过开源协议获得著作权许可(自由 copyleft)无效和被终止[6]。因此,违反“传染性”条款以及其他GPL开源协议中的义务性条款的情形发生,构成著作权许可合同自动终止并自始无效的条件。

传染性条款的加入,使得GPL开源软件和派生作品的获取和使用“自由”能够得到有效保障,但是对于企业的开源软件合规审查也提出更高的要求。如果企业在软件的开发过程中有意或者无意中混入了GPL开源代码,而又未按照GPL要求履行相关开源义务,则可能会导致软件合规法律风险,例如:按照GPL的规定,如果开发者不遵守本协议,则开源协议授予的“自由”将会被无效和被终止,使用开源软件的行为将直接成为一种未经授权的著作权侵权行为,开发者可能会面临来自开源软件著作权人的侵权索赔以及停止使用的知识产权行为禁令。同时,如果在企业对外宣传“自主研发具有自主知识产权”的软件中被发现存在适用GPL协议的开源代码,而企业又并没有履行开源义务,也会对企业的商誉造成的负面影响。

二、GPL.v1的“传染性”条款摘要及评述

(一) GPL.v1的“传染性”条款摘要

第2条. You may modify your copy or copies of the Program or any portion of it, and copy and distribute such modifications under the terms of Paragraph 1 above, provided that you also do the following:

您可以修改本程序的副本或程序的任何部分,并可以根据第1款的授权复制和分发此类修改,但前提是您还必须执行以下操作:

a) cause the modified files to carry prominent notices stating that you changed the files and the date of any change; and

a)使修改后的软件文件带有明显的声明,声明您已修改代码和修改的日期;和

b) cause the whole of any work that you distribute or publish, that in whole or in part contains the Program or any part thereof, either with or without modifications, to be licensed at no charge to all third parties under the terms of this General Public License (except that you may choose to grant warranty protection to some or all third parties, at your option).

b)【传染性条款】您应当使分发或发布的全部作品(包括本程序或其任何部分的全部或部分内容,无论是否经过修改)均根据本通则的条款,免费授予所有第三方GPL许可证(除非您选择向第三方提供代码担保可以进行收费)。

c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the simplest and most usual way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this General Public License.

c)如果修改后的程序在运行时通常以交互方式读取命令,则必须以一种最简单,最常用的方式使它在开始运行以进行交互使用时,打印或显示声明,其中包括适当的版权声明以及没有担保(或者说您提供担保),并且用户可以在这些条件下重新分发程序,您还需要告诉用户如何查看此通用公共许可证的副本。

d) You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.

Mere aggregation of another independent work with the Program (or its derivative) on a volume of a storage or distribution medium does not bring the other work under the scope of these terms.

【传染性例外条款】仅将本程序(或其衍生产品)与另一项独立作品聚合到一定数量的存储或分发介质上,并不会将独立作品归入GPL的管辖。

第3条.You may copy and distribute the Program (or a portion or derivative of it, under Paragraph 2) in object code or executable form under the terms of Paragraphs 1 and 2 above provided that you also do one of the following:

您需要根据上面的第1和第2款规定,以提供目标代码或可执行格式,复制和分发本程序(或根据第(2)款的规定,复制或分发程序的一部分或衍生作品)。除此之外,您还需要执行以下任一操作:

a) accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Paragraphs 1 and 2 above; or,

附上相应的源码。源码要求完整且机器可读,并在条款一、二的约束下

……

Source code for a work means the preferred form of the work for making modifications to it. For an executable file, complete source code means all the source code for all modules it contains;

作品的源代码是指对作品进行修改的首选形式。对于可执行文件,完整的源代码表示该文件包含的所有模块的所有源代码。

(二) GPL.v1的“传染性”条款评述

为了保障开源软件自由使用的行为,在开源软件协议GPL.v1中就规定了“传染性”条款。

根据GPL.v1的“传染性”条款,如果开源软件的修改者和使用者,需要复制或分发开源软件,则GPL.v1对于完整包含了开源软件全部或部分、完整包含了修改过的开源软件全部或部分从而形成的派生作品,要求继续遵循GPL.v1进行开源。

根据GPL.v1的“传染性”例外条款,GPL.v1规定阻断传染性的情形是:如果“独立作品”与开源软件“仅仅聚合”在同一介质上,则“独立作品”并不会因为聚合行为而被GPL.v1传染,该“独立作品”可独立选择适用的许可协议。

三、GPL.v2的“传染性”条款摘要及评述

(一) GPL.v2的“传染性”条款摘要

第2条:You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

您可以修改开源软件的副本,或者开源软件的副本的任何部分,从而形成一个基于开源软件的作品(派生作品)。只要满足上面的三个条件(免责声明、保留协议、一同发售)以及下列条件,就可以对开源软件的派生作品进行复制和发行

a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

您必须在您修改了的文件中醒目地声明您的修改、修改日期

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

【传染性条款】您发行或者发布的作品,如果包含开源软件的全部或部分,或派生自开源软件或开源软件的部分。那么您就应该将这个作品整体,允许第三方在遵守本协议的情况下,进行本协议的使用,并且不能收费。

c) ……

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

【独立部分的发布方式对传染性的影响】上述要求对派生作品整体有效。但是如果该派生作品中某些可区分的部分并非派生自开源软件,并且可以被合理地看作是从中分离的独立作品,则当您将它们分开发布时,这种独立部分可以不受本协议约束。但是如果开发者在发布开源软件的时候将上述独立的部分与派生作品一起发布,那么整个派生作品连同独立部分将被视为一个整体,受GPL.v2协议约束。

Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

因此,本节的目的不是主张权利或反对完全由你开发的作品的权利; 相反,目的是控制分发开源软件的派生作品或汇编作品的行为。

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

【传染性例外条款】另外,仅仅将另一个作品(并非基于开源软件)和开源软件或者开源软件的衍生作品聚合在一起,并不会导致其他的作品受到本协议的约束。

(二) GPL.v2的“传染性”条款评述

GPL.v2依然延续了GPL.v1“传染性”条款,即GPL.v2对分发开源软件修改后形成的派生作品依然采用严格的开源限制。只要开发者分发或发布的作品包含开源软件的全部或部分,或派生自开源软件或开源软件的部分,均应当将作品整体开源,允许第三方在遵守本协议的情况下,进行本协议的使用,并且不能收费。

在GPL.v1“传染性”条款基础上,GPL.v2还进一步明确了:“传染性”对开源软件的派生作品中的独立部分(section)的区分适用原则。

当作品中不涉及开源软件代码的独立部分(section)具有足够的独立性,且开发者将该作品中独立部分(section)与作品中涉及开源软件的其他部分(section)分开发布,则作品中这种独立部分(section)可以作为传染性的例外,不受GPLv2的约束;但如果开发者将原本独立的部分(section)与作品中涉及开源软件的其他部分一起发布,则原本独立的部分(section)则会被传染,需要开源并受到GPLv2的约束。

在聚合作品“传染性”例外问题上,GPL.v2与v1并没有实质的区别。与基于开源软件的派生作品聚合的独立作品,可以不受到开源软件的传染性的约束。

四、GPL.v3的“传染性”条款摘要及评述

(一) GPL.v3中“传染性”条款摘要

第4条. Conveying Verbatim Copies.传播完整版本

You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.

您可以原封不动地分发您获得的开源软件的源代码,只要您:

1、显著而适当地在每个副本上发布一个合适的版权通告;

2、保持完整所有叙述本授权和任何按照第7节加入的非许可的条款;

3、保持完整所有的免责申明;

4、并随程序给所有的接受者一份本授权的副本。

您就可以通过任何媒介发布卖手游账号平台程序源代码的未被修改过的完整副本

第5条. Conveying Modified Source Versions.传播修改过的源代码

You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:

您可以在第4节的条款下以源码形式发布一个基于本程序的软件,或者从本程序中制作该软件需要进行的修改,只要您同时满足所有以下条件:

a) The work must carry prominent notices stating that you modified it, and giving a relevant date.

软件必须包含明确的通知说明您修改了它,并给出相应的修改日期。

b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”.

软件必须包含明确的通知,声明这个软件是在本协议(以及本协议第七节增加的所有条件)授权下发布的,本条款修改了第四节的“保持所有通知完整”的要求。

c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.

【传染性条款】被许可人必须将整个作品整体性地通过本许可证许可给持有复制件的人,无论组件以何种方式组成作品,本许可证及第7节所附加条款都将适用于作品的整体及其一切组件。本许可证不包括以其他方式授权作品许可。但被许可人单独接收到许可不会导致该许可证失效。

……

A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

【传染性例外条款】一个受保护的开源程序和其它独立程序的“组合”,该“组合”作品并非该开源程序的扩展,也不是为了在某个存储或发布媒介上,和开源程序的进行组合,为的是生成更大的程序,且如果“组合”的版权对使用者进行访问等合法权利的限制,不超过独立的作品对使用者进行访问等合法权利的限制。那么这样的“组合”就被称为“聚合体”。包含开源程序的聚合体中,GPL并不会适用于开源程序以外的该聚合体的其他部分;

(二) GPL.v3的“传染性”条款评述

GPL.v3在规定传染性问题时,首先调整了此前v2版本的用词,v2版本在规定传染性问题时,着眼点为“分发”(distribute),而v3版本的着眼点为“传输、传播”(convey)。根据GNU发布的说明,分发与传播,并无明显区别,只是由于GNU在制定过程中,制定者发现一些法律体系在其版权法中使用“distribute”一词,但是含义和GPL.v2的distribute并不相同。因此为了避免同词不同义的情况发生,GNU创造了新的术语convey,用来避免这些不同造成的混淆和问题[7]。因此,GPL.v2和v3在将“传染性”作为原则这一点上并没有明显的差别。

GPL.v3没有延续GPL.v2中“传染性”对开源软件的派生作品中的独立部分(section)的区分适用原则。GPL.v3采用了更严格的统一传染性标准,GPL.v3将修改后的开源软件及其他部分(无论是否是独立部分),均统一视为一个完整的作品,因此在传输(convey)、分发这样的作品时,无论其中开源部分与独立部分如何组合(无论是分开发布或一起发布),对这个作品整体应当适用开源协议GPL.v3。

在横向传染性上,经过两个版本的迭代演进,v3对于“传染性”的例外规定比v2更为清晰,v3进一步明确了“聚合”(Mere aggregation)的概念边界。“聚合”软件指的是,除独立软件与开源软件及其衍生作品存储在同一个介质上并进行组合,为的是生成更大的程序以外,独立作品与受开源协议保护的作品的“组合”,且这一“组合”(A compilation)的版权对使用者进行访问等合法权利的限制,不超过独立的作品(包括独立的作品和开源软件及其衍生作品)单独自身对使用者进行访问等合法权利的限制。

注释:

[1] 徐瑄,张汉华.计算机开源软件许可证的许可条款性质认定——美国联邦巡回上诉法院第2008-1001号裁决评析[J].知识产权,2014(06):85-93.

[2] 罗瑞雪,《开源协议适用范围及其对软件著作权侵权判定的影响》,中国版权,

ipc.court/zh-cn/news/view-842.html

[3] 参见GPL.v2协议第2条,You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:……b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

[4] GPL.v3对于相关行为义务的表述进行了修改,用词改为convey而非第二版本的distribute,根据自由软件基金会的解释,前述用词的改变并没有改变行为的实质,只是为了避免与部分法域的法律术语相冲突因而进行的技术性调整。

[5] 参见GPL.v3协议,第5条,该条规定了构成软件“聚合体”(aggregate)的前提之一为开源软件与其他软件的“组合”并非为了形成更大的程序,反之,如果这样的“组合”被法院认定为一个更大的软件的两个部分,那么将无法构成“聚合体”,从而应当进行整体开源。

[6] 以GPL.v2为例,该协议第4条规定:You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. 在本协议授权之外,您不能复制、修改、再授权或分发开源软件。任何用其他方法复制、修改、再授权或分发开源软件的企图都是无效的,并使您从本协议获得的权利自动终止。

[7] Frequently Asked Questions about the GNU Licenses,

gnu/licenses/gpl-faq.en.html

(第二部分)

五、GPL开源软件项目法律合规业务中需要关注的问题

开源软件促进了软件智力成果的共享,越来越多的企业将开源软件(代码)直接或再开发后用于商业用途。免费自由使用开源软件给企业带来便利的同时,也要求企业履行开源许可协议项下的义务。如未能履行开源软件协议项下义务将使企业面临巨大的法律风险。下文将对GPL开源软件项目法律合规业务中需要重点关注的几个问题进行分析。

(一) 确定GPL开源协议的版本

企业需要明确自身使用的GPL开源软件适用的开源协议版本。例如后文提及的最高院审理的开源协议案件,适用的开源协议为GPL第三版本,其中对于“聚合体”软件有特有的论述,从而能够成为法院认定的依据。

需要注意的是,虽然同为GPL开源协议,其三个版本均为共存、独立有效状态,而非法律修订的新旧替代关系。因此,确定GPL开源协议的版本为GPL开源软件合规业务需要关注的首要问题。

如果GPL开源软件系通过开源社区进行下载,那么开源社区通常会标注该开源软件适用的GPL开源协议的版本号。如果并非从规范的开源社区下载,由于开源协议通常会要求在分发复制件时原封不动地附上开源协议的文本。因此在开源代码的文本中,也能够找到对应的开源协议版本。

(二) 判断其他软件与开源软件是否具有独立性

对商业企业来说,商业软件的开发者下载GPL开源代码之后,通常都会将GPL开源代码或修改后的开源代码和其他自研软件代码整合进企业自己的商业软件之中,并一同分发和使用。因此商业企业需要审查评估其自研软件与GPL开源软件之间的关系,即GPL开源软件/基于开源软件的衍生作品与其他自研软件作品是否互相为独立的软件。如果GPL开源软件和自研软件属于独立软件,则自研软件并不会被GPL协议所传染;如果GPL开源软件和自研软件不属于独立软件,则自研软件会被GPL协议所传染。

如何判断软件独立性需要结合技术与法律,下文将从就自由软件基金会对软件独立性问题的解答、开源软件实例和我国的司法判例进行介绍。

1、自由软件基金会对软件独立性问题的解答

根据自由软件基金会发布的GPL相关问题的解答,“聚合体”包含有多个独立的程序,并在同一个CD-ROM或其他媒体上发行。GPL.v3允许开发者制作并发布一个聚合体,即使其中其他软件的许可证不是自由许可证或不是GPL兼容的许可证也可以。唯一的条件是聚合体的许可证不能禁止用户行使每个独立程序的许可证允许的权利。区分软件究竟是两个独立的程序,还是一个程序的两个部分的合理的标准既依赖于通信的机制(exec、pipes、rpc、共享地址空间的函数调用,等等),也依赖于通信的语义(交换了什么样的信息),具体判断的工作则应交由法院完成[1]。

2、“OpenHarmony”开源项目中对开源软件独立性的说明

近期,华为公司自行研发的“OpenHarmony”开源项目也公开了相应的软件结构和代码说明,其中就有开发者针对软件独立性的特别说明。举例而言,“OpenHarmony”中包含一个名为“third_party_mtd_utils”的开源软件,该软件适用GPL.v2,“OpenHarmony”的开发者对该开源软件进行了如下说明:“third_party_mtd_utils用于编译生成jffs2文件系统镜像的打包工具,该工具用于打包jffs2格式的rootfs和userfs镜像,代码不会编译打包到kernel_liteos_a内核中,故kernel_liteos_a内核不受GPL影响”;又例如,“OpenHarmony”开源项目中有一名为“

vendor_hisi_hi35xx_thirdparty_uboot_src”的开源软件,开发者对其的说明是:“uboot是作为独立进程,不会导致boot外的软件受到GPL许可证的影响”[2]。由此可见,华为公司在开发“OpenHarmony”开源项目时,已经注意到开源义务,从而在软件的结构上,维持开源软件的独立性,从而规避开源软件的传染性。

3、我国司法实践中对软件独立性的认定思路

(1)柚子(北京)移动技术有限公司与数字天堂(北京)网络技术有限公司侵害计算机软件著作权纠纷案

该案的原告数字天堂公司主张被告柚子公司侵犯了原告的软件著作权,被告柚子公司主张原告的涉案软件中使用了GPL开源代码,对应的GPL协议的版本为第三版。一审法院审理认为,因原告主张被告使用的是涉案软件中的三个插件,而该三个插件属于独立的软件作品,因此,需要判断的是该三个插件是否是受GPL协议限制。一审庭审中,被告认可该三个插件均处于独立的文件夹中,该文件夹中并无GPL开源协议文件。据此,一审法院认为:“涉案三个插件的文件夹中并无GPL开源协议文件,而涉案软件的根目录下亦不存在GPL开源协议文件的情况下,尽管涉案软件其他文件夹中包含GPL开源协议文件,但该协议对于涉案三个插件并无拘束力,涉案三个插件并不属于该协议中所指应被开源的衍生产品或修订版本,被告柚子公司认为原告数字天堂公司软件为开源软件的相关抗辩理由不能成立。被诉行为构成对著作权人复制权、改编权及信息网络传播权的侵犯”[3]。

被告柚子公司在二审中提出GPL协议的“传染性”问题,被告主张涉案软件中既然已经采用了GPL开源代码,那么无论是否仅涉及插件,GPL的传染性也会导致整个涉案软件均应适用GPL协议从而成为可以供他人自由使用的开源软件。但是二审法院依然没有对GPL协议的文本进行研究,在二审判决中依然强调没有在涉案软件的根目录中发现GPL协议文件,从而不认可被告主张的GPL协议传染性观点,进而否认涉案软件已经成为开源软件的观点[4]。

该案为我国司法实践中涉及GPL开源协议的第一案,但是从法院的审查严谨性上,似乎并不尽如人意。该案实际上已经触及了GPL开源协议最关键的“传染性”问题,就判决书中查明的案件事实来看,原告主张权利的涉案软件的部分代码确实是用了开源代码,其软件整体的确存在已经被传染成为开源软件的可能性。但是一、二审法院都并没有对涉案软件和插件的通信机制和通信语义进行审查,而是仅凭软件目录中没有开源协议文本就认定了涉案软件不受开源协议的规制,直接排除了涉案软件整体已经被传染称为开源软件的可能性。事实上,假使原告在开发涉案软件的过程中有意没有遵循开源协议的义务放置开源协议的文本,抑或是第三方开发的过程中,规避开源的义务而没有放置开源协议的文本,均有可能导致该案的结果截然相反。本案作为开源协议“传染性”的第一案,在认定是否适用“传染性”的问题上,法院没有结合开源协议传染性条款相关内容和软件技术细节进行深入审查讨论,判断依据简单,得出结论仍有进一步商榷讨论的空间。

(2)北京闪亮时尚信息技术有限公司、不乱买电子商务(北京)有限公司侵害计算机软件著作权纠纷案

本案中,原告不乱买公司主张被告闪亮公司侵犯原告的软件著作权。原告同样抗辩涉案软件已经被GPL开源协议传染从而整体成为开源软件。本案涉及的是GPL.v3开源协议。本案中,被告举证证明了原告的网站的前端代码中采用了开源代码,如果能够进一步证明前端代码和后端代码构成一个整体软件进行分发,那么涉案软件可能已经受到“传染性”的影响。本案的一审法院认为,原告的网页仅有前端代码明确使用了开源代码,原告主张权利的是其后端代码。前端代码开发主要是指前端用户可见的操作界面如页面布局、交互效果等页面设计的一种实现方式,后端代码开发则主要是指后端用户不可见的服务端相关逻辑功能等模块的实现,二者展示方式不同、所用技术不同、分工亦有明显区别,属于可独立的程序[5]。因此一审法院认为,不乱买公司虽在其前端代码中使用了开源代码,但其后端代码程序并非其前端程序的衍生品或修订版本,故根据GPL协议的相关规定,该协议对涉案权利代码并无拘束力。

在二审中,被告上诉称原告的前端代码和后端代码存在交互且没有进行有效隔离,不是相互独立的,根据GPL协议的相关内容以及极强的传染性特性,不乱买公司的前端文件和后端文件共同构成的其主张著作权的软件,整体软件都可以视为前端程序的修订版本,应当遵循GPL协议向所有第三方无偿开源。最高院在二审判决中认为,首先,前端代码和后端代码具有独立性,“前端代码与后端代码是可以分别独立打包、部署的。因此,前端代码与后端代码在展示方式、所用技术、功能分工等上均存在明显不同,不能因前端代码与后端代码之间存在交互配合就认定二者属于一体,原审法院认定前端代码与后端代码相互独立并无不当”。其次,涉案软件是由前端代码和后端代码联合构成的“聚合体”:“根据2007年6月29日发布的GPL协议第3版第5条关于'一个受保护程序和其它独立程序的联合作品,在既不是该程序的自然扩展,也不是为了生成更大的程序,且联合作品和产生的版权未用于限制编译用户的访问或超出个别程序许可的合法权利时,被称为聚合体。包含受保护程序的聚合体并不会使本许可应用于该聚合体的其他部分’的规定,闪亮时尚公司所称GPL协议的“传染性”应当是指GPL协议的许可客体不仅限于受保护程序本身,还包括受保护程序的衍生程序或修订版本,但不包括与其联合的其他独立程序。本案中,虽然不乱买公司认可其前端代码中使用了GPL协议下的开源代码,但其主张权利的是后端代码,其后端代码是独立于前端代码的其他程序,并不受GPL协议的约束,无需强制开源”[6]。

最高院的在该案中的二审判决引用了GPL.v3开源协议中对开源传染性的例外条款。当开源代码与软件的中的其他独立程序组成“聚合体”时,开源协议不会对其他程序进行传染。最高院参考了自由软件基金会判断软件独立性的标准,考虑了通信的机制和通信的语义,得出后端代码具有独立性的结论。最高院的前述判断依据更为科学合理,得出结论也更准确。

(三) 审查是否全面履行相应的开源协议义务

开源协议合规的落脚点必然是履行协议要求的开源义务。对于GPL开源协议项下的义务,在开源软件合规项目中应当注意审查企业是否不折不扣地全面履行了相关开源义务。否则极有可能自动触发著作权许可合同的解除或终止条件,随之面临巨大的软件著作权侵权法律风险。

如果发生开源义务要求与企业商业软件的保密要求之间的矛盾确实无法调和时,可以建议企业在阻断GPL传染性的基础上,采用自研软件进行替代。

注释

[1] Frequently Asked Questions about the GNU Licenses,gnu/licenses/gpl-faq.en.html

[2]

gitee/openharmony/docs/blob/master/zh-cn/contribute/第三方开源软件及许可证说明.md

[3] 数字天堂(北京)网络技术有限公司诉柚子(北京)科技有限公司、被告柚子(北京)移动技术有限公司侵犯计算机软件著作权纠纷一案,北京知识产权法院,(2021)京知民初字第631号。

[4] 同上。

[5] 参见北京闪亮时尚信息技术有限公司、不乱买电子商务(北京)有限公司侵害计算机软件著作权纠纷,北京知识产权法院,(2021)京73民初1111号。

[6] 参见北京闪亮时尚信息技术有限公司、不乱买电子商务(北京)有限公司侵害计算机软件著作权纠纷案,最高人民法院,(2021)最高法知民终663号。

本站仅提供存储服务,所有内容均由用户发布,如发现有害或侵权内容,请点击举报
打开APP,阅读全文并永久保存 查看更多类似文章
猜你喜欢
类似文章
【热】打开小程序,算一算2024你的财运
解读我国开源协议司法判决的第二案(附判决)
开源软件许可协议简介
开源组织之FSF与OSI,开源协议之BSD、GPL、APACHE
Google:将来还会有人遵守开源许可协议吗
几种开源许可协议介绍
高端论道|张平:开放创新,知识产权问题值得深思
更多类似文章 >>
生活服务
热点新闻
分享 收藏 导长图 关注 下载文章
绑定账号成功
后续可登录账号畅享VIP特权!
如果VIP功能使用有故障,
可点击这里联系客服!

联系客服