GPL开源许可“紧箍咒”——软件研发涉传染性开源许可证司法 ...

吉生

【引言】开源是一种分布式协作模式，通过对软件源代码的开放，参与者可以使用、修改、再发布，进而共享创新成果。如今，利用开源代码编写软件已成为软件研发的主流模式，然而“天下没有免费的午餐”，这种便利同样也受到开源软件所采用的开源规则的限制，譬如商业使用限制、署名要求、专利保留要求、新增代码开源要求等等。作为开发者，如果你打算开源自己的代码，务必要选择一种开源许可证；作为使用者，也应当了解相应许可证的权利与义务要求，合规创新以避免侵犯他人权利被诉诸赔偿。

目录预览
一、纷繁的开源许可证及其项下权利义务概述
二、如何理解GPL开源许可证的“传染性”？
（一）传播未被修改过的完整副本
（二）传播经修改过的副本
（三）独立可分离部分的区分适用规则
三、聚合（aggregation）——“传染性”的豁免
四、“开源”与“免费”：开源软件禁止商业化利用吗？
五、谁有权起诉？——开源软件侵权纠纷的诉讼主体资格问题
六、涉传染性开源许可证软件著作权侵权的司法认定
（一）传染性开源许可证的法律性质和效力
（二）前端代码使用GPL开源代码，后端代码是否也受GPL约束？
（三）使用开源语言软件开发的应用软件是否也应开源？
（四）违反GPL V3协议“传染性开源”要求的法律后果
七、利用开源代码进行软件研发的法律合规建议
八、结语

一、纷繁的开源许可证及其项下权利义务概述

开源许可证（Open Source License），本质上是作者与使用者之间具有法律约束力的“版权许可协议”，开发人员使用开源软件（代码）就必须要遵守作者选定的许可证中涉及的特定条款和条件。目前，开源许可证类型约有两百余种，复杂性及其设定的权利与义务丢不甚相同。常见的开源软件协议大致有MIT、BSD、Apache、GPL、LGPL等。
作为使用了开源代码的商业软件开发者，必然会关心其开发的后续衍生软件，是否也应当全部开源。以此为标准，MIT、BSD、Apache等许可证允许“闭源”，而GPL、LGPL、Mozilla等许可证要求后续衍生软件必须“开源”。
（一）MIT、BSD、Apache等较宽松的开源许可证

MIT和BSD许可证均源于美国的大学组织，两者均以简洁、自由、限制少而著称。
就MIT许可证而言，被授权人几乎不会受到限制，可以修改、发行及出售有关开源软件及其副本，也可以根据需要修改再授权内容。得益于此，MIT许可证的兼容性也极佳，适用MIT许可证的开源程序可与适用其他许可证的开源程序合并，而不会产生法律上的冲突。被授权人获得如此“慷慨”授权的同时，仅仅需要在其发行的软件及其副本中列明版权人和许可声明。
BSD与MIT在权利与义务的安排上基本一致，也可以将修改后的代码作为开源或者专有软件再发布，包括将后续衍生品作为商业软件发布和销售。不过BSD对使用者提出了几点限制：第一，不能用原始权利人的名字（名称）进行市场推广；第二，如果再发布的软件中包含源代码，则源代码必须继续遵循BSD许可证；第三，如果再发布的软件中只是二进制类库/软件，则需要在相关文档或版权文件中声明原始代码遵循了BSD协议。
与BSD类似，Apache 2.0也可以适用于商业软件，允许用户修改代码并再发布。开发者在开发遵循该协议的软件时，须遵守以下四个条件：第一，该软件及其衍生品必须继续使用Apache许可协议；第二，如果修改了程序源代码，需要在文档中说明；第三，衍生软件需要保留原始代码中的协议、商标、专利声明和其他原来作者规定需要包含的内容；第四，如果再发布的衍生软件中有声明文件，则需在此文件中标注Apache许可协议及其他你想增加的许可协议。
Apache协议还具有授权不可撤消等特性，可以说对商业性使用十分友好。
值得一提的是，中国开源云联盟（COSCL）发布的中国首个开源协议MulanPSL也属于宽松许可证。
（二）GPL、LGPL等传染性许可证

只要软件中包含了遵循GPL（GNU General Public License）协议的产品或代码，该软件就必须强制性适用GPL许可协议——开源免费。换言之，一旦调用GPL库，你的软件将被“感染”为GPL的软件，此之谓“传染性”。因此GPL许可证并不适合商用软件。
LGPL（GNU Lesser General Public License）是GPL的一个衍生版本，相比于GPL更加宽松一些。LGPL允许商业软件通过“类库引用”的方式使用LGPL类库，而不需要开源商业软件的代码。但是如果修改LGPL协议的代码或者衍生品，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。
因此适用LGPL协议的开源代码适合作为第三方类库被商业软件引用，但不适合通过修改和衍生的方式做二次开发的商业软件使用。
二、如何理解GPL开源许可证的“传染性”？

GPL规定只要软件中使用了GPL开源许可证的代码，则修改后的源代码或者衍生软件代码也必须采用GPL开源许可证发布，这就是所谓的“传染性”。目前，GPL开源许可证有v1，V2，V3三个主要版本。鉴于现在使用GPL v1许可证的已经比较少了，本文主要分析V2，V3两个版本。
（一）传播未被修改过的完整副本

根据GPL V2许可协议的第一条的规定：开发者复制（copy）和分发（distribute）开源代码需要满足以下三个条件：第一，开发者在每个副本上醒目且适当地发布版权声明和免责声明；第二，完整保留所有涉及该许可证和免责的事先声明；第三，将本许可证的副本与程序一起交给程序的其他接收者。
根据GPL V3许可协议的第四条的规定：开发者传播（convey）其获得的开源软件源代码需要满足以下四个条件：第一，开发者应在每个副本上醒目且适当地发布版权声明；第二，完整保留所有涉及该许可证及任何非许可（non-permissive）条款适用于源代码的事先声明；第三，保留所有免责的事先声明；第四，随程序给所有的接收者一份本授权的副本。
对比来看，在未被修改过的完整副本的传播要求上，GPL V3与GPL V2并无本质区别，仅在用词上略有调整，根据GNU发布的FAQ，分发（distribute）和传播（convey）并无明显差别。
（二）传播经修改过的副本

GPL V2许可协议允许开发者修改程序副本，从而形成新的作品并根据协议第一条的规定复制和分发，同时开发者必须做到以下两点：第一，醒目地说明其更改了文件以及更改日期；第二，开发者应使其作品作为一个整体获得许可且不得向所有第三方收取任何费用，受此限制的作品包括：①全部或部分包含本开源程序的作品，②派生（derive）自开源程序或其任何部分的作品。不过，GPL V2还规定了“独立可分离部分的区分适用规则”（详见下文）。
GPL V3许可协议同样允许开发者修改程序副本，开发者需满足以下条件：第一，醒目地说明其更改了文件以及更改日期；第二，作品必须明确说明它是根据GPL V3发布的，包括协议第7条附加的条件；第三，开发者应使其作品作为一个整体获得许可给第三方。
（三）独立可分离部分的区分适用规则

GPL V2许可协议规定了“独立可分离部分的区分适用规则”——如果作品的可识别部分（identifiable sections）不是来自开源程序，并且可以合理地认为其本身是独立可分离（independent and separate）的，那么当开发者将其作为独立作品发布时，GPL V2不适用于这些部分。但是，如果开发者在发布软件的时候将上述独立的部分与派生作品一起发布，则整体的发布必须遵守GPL V2而不论其作者是谁。
GPL V3没有延续GPL V2规定的“区分适用原则”，GPL V3将修改后的开源软件及其他部分（无论是否独立），均统一视为一个完整的作品，二不论其封装（package）方式如何，对该作品整体均应当适用GPL V3。
三、聚合（aggregation）——“传染性”的豁免

GPL V2规定了关于作品聚合（aggregation）不受传染的例外——仅仅将另一个不是基于本开源程序的作品，与本开源软件（包括派生作品）聚合在一起，并不会导致其他作品受到GPL V2的约束。
GPL V3延续了这一例外规定。并进一步明确了聚合的概念，它是指开源程序和其他独立程序的特殊组合，这一组合仅仅是为生成更大的程序，而非该开源程序的扩展，也非为在某个媒介上与开源程序结合（compilation），并且这一组合对使用者的访问限制不超过独立作品对使用者进行访问等合法权利的限制。
根据GNU发布的FAQ，“聚合”包含有多个独立的程序，并在同一个CD-ROM或其他媒介上发行。区分的合理标准既依赖于通信的机制（exec，pipes，rpc，共享地址空间的函数调用等），也依赖于通信的语义（交换了什么样的信息）。GPL V3允许开发者制作并发布一个聚合体，即使其中其他软件的许可证不是开源许可或与GPL不兼容亦可，除非聚合体的许可证禁止用户行使每个独立程序的许可证允许的权利。
不过，到底如何在复杂的现实情况下，界定“聚合”和“衍生”，GNU也指出“具体判断的工作则应交由法官决定”。
在我国的司法实践中，已出现了一起有关“聚合软件”认定的案例——柚子（北京）移动技术有限公司等与数字天堂（北京）网络技术有限公司侵害计算机软件著作权纠纷上诉案。该案中，涉案HBuilder软件有边改边看等三个插件，均处于独立的文件夹中且文件夹中并无GPL开源协议文件，权利人针对三个插件分别进行了著作权登记。
一审北京知识产权法院认为：涉案三个插件并不属于GPL协议所指应被开源的衍生产品或修订版本，该协议对涉案三个插件无拘束力。二审北京高院虽未直接认定HBuilder软件属于“聚合体软件”，但认可了数字天堂公司关于“HBuilder软件系包含Eclipse平台框架、Aptana插件、数字天堂公司为Eclipse开发的插件以及其他第三方公司为Eclipse开发的插件为一体的聚合体软件包”的诉讼意见。根据本案判决，笔者试归纳如下司法裁判观点：
第一，功能插件以独立文件夹形式存在于软件压缩包内，根目录及功能插件文件夹内均不存在GPL许可证的，GPL协议对插件无拘束力；
第二，插件是否能够独立运行，不影响“聚合体软件”的认定；
第三，插件是否单独进行了软件著作权登记，可以在“聚合体软件”认定中综合考虑。
【预告】本文的中篇将重点分析“传染性”的豁免规则，厘清“开源”与“免费”的认识误区，并就开源软件侵权纠纷的诉讼主体资格问题展开探讨。请关注李家杭律师查看文章。

孤行客人

支持，赞一个