GPL协议显然不是一份传统意义上的法律文件，为什么要创制出Copyleft这一机制？遵守或者违反这一机制，对商业用途使用以及二次开发会造成什么影响与后果？进一步而言，不同使用人前后相继地连续违反GPL协议的行为，分别应当受到什么法律评价？作者 | 俞峰 国浩律师（苏州）事务所合伙人编辑 | 布鲁斯一、由 来1983年，Richard M. Stallman发起名为“GNU”（意为“GNU's Not Unix”）[1]的自由软件运动，Linux操作系统即是该运动的直接产物之一。为防止其他商业实体违背GNU的初衷而不当利用自由软件，Stallman成立非营利的自由软件基金会（Free Software Foundation, 简称“FSF”）并与律师共同草拟如今已获得广泛使用的GNU通用公共协议证书（GNU General Public License, 以下称为“GPL协议”），通过GPL协议创造了所谓“Copyleft”授权方式，以其特有的“强传染性”区别于MIT、BSD、Apache等相对宽松的开源协议/许可证。按照Stallman的解释，“Copyleft”最初的含义为“反转所有权利”（all rights reversed）[2]，这一名称显然是对“著作权”（Copyright）一词及其蕴含的“保留所有权利”（all rights reserved）原则的颠覆。随着互联网、人工智能的迅速普及以及电子产品智能化、小型化趋势，以Linux为代表的开源软件（Free and Open Source Software，以下称为“FOSS”）在商业领域获得广泛应用，由此引发FOSS的权利人、以FSF为代表的非营利组织，与经营活动涉及FOSS的商业实体之间的折冲、矛盾，尤以适用GPL（General Public License）的两个版本（v2[3]/v3[4]）[5]开源协议的FOSS为甚。2000年之后，GPL协议相关司法案件在欧洲和美国开始蔓延，GPL协议效力以及Copyleft式维权陆续获得司法机关的接纳与认可。我国互联网行业在2000年后迅速进入高速发展期，几与欧美同步，上述问题很快被引入我国司法审查的视野，贡献出“不乱买公司诉闪亮公司案”、“数字天堂诉柚子移动案”以及“罗盒”系列案等经典案例。然而，欧美诸国与我国受理此类案件的诉因存在明显差异：前者主要是FOSS权利人（或者公益组织）主张商业实体违反GPL协议，要求停止侵权、赔偿损失；后者则有相当比例是被诉的侵权方在软件侵权案件中以被侵权方违反GPL协议为由提出不侵权抗辩，意图减轻甚至免除侵权责任，较为典型的是2022年至2023年披露的两个案件：未来公司案南京市中级人民法院（2021）苏01民初3229号（裁判日期2022年9月19日）未来公司拥有“未来网上投标文件制作工具软件”的著作权。未来公司认为云蜻蜓公司发布的“云蜻蜓软件-投标文件制作工具”在功能及实现上与原告软件存在高度近似，构成侵权。云蜻蜓公司认为未来公司软件中的SaveFile及CloseFile等Cell组件的有关函数系第三方开发，未来公司不享有著作权。但未来公司坚持认为其软件代码不受GPL协议约束。未来公司向中国版权保护中心的提交软件登记的材料中，包含一份涉案软件不适用GPL协议的声明。案件审理过程中，未来公司当庭表示不会公开涉案投标工具软件源代码。人民法院认为：未来公司涉案软件主程序源代码中的FutureZR文件夹下的Main.cs、SharpZipBaseException.cs、AssemblyInfo.cs等多个文件中包含GPL声明（2.0版本），因此主程序部分受GPL协议约束，而预览程序部分不受GPL协议约束。本案中，对原告违反GPL协议的行为给予侵权法上的保护，势必虚置GPL协议关于源代码持续开源的相关规定，对于通过GPL协议让源代码持续开源传播产生不利影响。预览程序不是涉案GPL开源代码的衍生作品，未被GPL开源代码传染，故不受GPL协议的约束。原告主张该部分软件著作权的保护，以及被告是否侵害该部分软件著作权的判断，均不受GPL协议的影响。最终人民法院部分支持了未来公司的侵权赔偿请求。网经公司案最高人民法院（2021）最高法知民终51号（裁判日期2023年10月12日）网经公司拥有“OfficeTen”的网关产品系统软件的著作权。网经公司认为亿邦公司、启奥公司在类似软件上使用了“OfficeTen”的源代码，构成侵权。亿邦公司、启奥公司提出不侵权抗辩，声称“OfficeTen”系基于OpenWRT系统开源软件开发而成，应当遵循GPLv2协议的约束，权利属于OpenWRT系统软件开源代码权利人。网经公司本就负有公开涉案软件源代码的开源义务，因此，亿邦公司与启奥公司即便使用了涉案软件源代码，该使用行为亦不构成侵权。人民法院认为：尽管涉案软件涉及GPLv2协议这一许可合同，但在OpenWRT系统软件权利人并非本案当事人情形下，基于合同相对性原则，本案不宜对涉案软件是否全部或部分受GPLv2协议约束、网经公司是否违反GPLv2协议、网经公司是否因此需承担任何违约或侵权责任等问题进行审理。其次，关于涉案软件是否受GPLv2协议约束，该问题涉及底层系统软件是否受GPLv2协议约束、上层功能软件是否构成GPLv2协议项下“独立且分离的程序”、二者间采用的隔离技术手段、通信方式、通信内容等如何界定以及软件领域对GPLv2协议传导性的通常理解与行业惯例等因素。在OpenWRT系统软件权利人并非本案当事人情形下，亦难以查明与GPLv2协议有关的前述系列事实。再者，亿邦公司与启奥公司并无证据证明网经公司通过GPLv2协议已放弃其就涉案软件依据我国著作权法享有的著作权。退而言之，即便假定网经公司因违反GPLv2协议导致涉案软件存在权利瑕疵，该假定瑕疵亦不影响网经公司在本案中针对被诉行为寻求侵权救济。综上而论，在软件尚未被开源、该软件著作权人认为其软件不受GPLv2协议约束、被诉侵权人则依据GPLv2协议提出不侵权抗辩的侵权纠纷中，软件开发者自身是否违反GPLv2协议和是否享有软件著作权，是相对独立的两个法律问题，二者不宜混为一谈，以免不合理地剥夺或限制软件开发者基于其独创性贡献依法享有的著作权。但需指出，本案最终认定被诉行为构成侵权并支持网经公司部分诉请，并不表明网经公司将来在潜在的违约和/或侵权之诉中可免予承担其依法应当承担的违约和/或侵权责任。最终，人民法院酌情支持亿邦公司与启奥公司赔偿网经公司50万元并消除影响。上述两个案件在分析路径和裁判趣旨上大相径庭：(1)未来公司案中，人民法院对原告是否违反其与第三方之间的GPL协议进行审查，并采用了类似“净手原则”的思路，认为“违反GPL协议的行为给予侵权法上的保护，势必虚置GPL协议关于源代码持续开源的相关规定”，从而认定被告无需就应当公开部分源代码承担侵权责任；(2)网经公司案中，人民法院基于“合同相对性”原则，认为不宜审查原告是否违反其与第三方之间的GPL协议；即便原告违反该等GPL协议导致涉案软件存在权利瑕疵，也不影响原告寻求侵权权利。人民法院进一步指出，被诉侵权人根据开源协议提出不侵权抗辩的情况下，软件开发者自身是否违反GPLv2协议和是否享有软件著作权，是相对独立的两个法律问题，二者不宜混为一谈，以免不合理地剥夺或限制软件开发者基于其独创性贡献依法享有的著作权。笔者尚未检索到未来公司案的上诉情况，该裁判文书未必是终审结果，但网经公司案件已发生法律效力。仅就两份判决书而言，其差异性值得我们对以下问题进一步提出追问和思考，即：GPL协议显然不是一份传统意义上的法律文件，为什么要创制出Copyleft这一机制？遵守或者违反这一机制，对商业用途使用以及二次开发会造成什么影响与后果？进一步而言，不同使用人前后相继地连续违反GPL协议的行为，分别应当受到什么法律评价？二、分 析01 软件给著作权法律价值带来冲击美国第一部《版权法》（Copyright Act）诞生于1790年，法律保护的客体范围从一开始的书籍、地图，逐步延伸至音乐、戏剧、舞蹈、美术、建筑、电影、摄影等艺术作品。但直到美国1980年修订《版权法》之后，软件及其源代码方才开始作为一项著作权客体（在此之前仅作为一般的商业秘密）受到法律保护，但即使软件作为著作权客体被广泛接受，随之而来的价值批判仍不绝于耳。正如Sapna Kunar指出：以著作权保护到期后的书籍或者音乐为例，出版商可以廉价的方式印刷这些书籍或者上传至网络，音乐可以数字化增益、重制，或者通过刻录光盘而公开。但是与这些传统的表达方式不同，软件的应用极度依赖于技术。当一项软件著作权到期，安装该软件的硬件设备会过时，软件的目的也会落空。因此，部分学者和软件作者要求大幅度降低对软件的财产性保护力度，甚至有人主张取消对软件的法律保护。但是，也有群体试图通过建立一套平行的知识共享体系作为平衡手段，以抵销（软件著作权）强大的财产性权利属性[6]。FSF总法律顾问Eben Moglen 指出[7]：版权法的要义，像其他产权规定一样，是一种排他权。版权持有者可以合法排除其他人复制、分发和制作衍生作品[8]的活动…而GPL，在另一方面，对版权做了减法而不是加法。许可证不用那么复杂，因为我们要尽量减少对用户的限制。版权给予出版商禁止用户复制、修改和分发的权利，而我们相信用户应该有这些权利；所以GPL解放了几乎所有版权系统的限制。软件对于技术的依赖，及其对人类社会进步发展的重要程度，远高于其他受著作权保护的表达方式。鉴于开发者对于软件的持续技术垄断，假设著作权法律对于软件的保护等同于书籍、音乐等传统权利的保护程度，有可能损害长远的社会公共利益。有些观点则走得更远，例如自由软件之父Stallman在2001年发表的《Science Must Push Copyright Aside》一文中提出：“美国宪法上说，版权的存在是“为了推动科学的进步”。当版权阻碍科学进步时，科学必须摒弃版权”[9]。GPL协议的诞生，可以说是对软件著作权保护的平衡、弱化与制约。02 GPL协议的目的FSF在其网站对GNU运动的目的解释如下[10]：让程序成为自由软件最简单的方法是放弃对它的版权并把它放到公有领域中。这使得他人在需要的时候可以共享这个软件及其对它的改进。但这也使得其他一些不愿合作的人把它们转变成专有软件。他们可以或多或少地进行修改，并把成果作为商业产品发布。这些修改过的程序不再像它们的原始作者所期望的那样允许用户自由地使用，这种自由被中间商剥夺了。在GNU工程中，我们的目标是让所有的用户可以自由地重新发布或修改GNU软件。如果允许中间商剥夺这种自由，我们也许会以此“获得很多的用户”，但这些用户便不再拥有自由。所以我们并不把GNU软件发布到公有领域，我们对它保留“Copyleft”。所谓Copyleft是指任何人都可以重新分发软件，不管有没有进行修改，但必须同时保留软件所具有的自由特性。Copyleft是为了保证所有用户都拥有自由。FSF认为，著作权剥夺了用户使用软件的自由。为了解决这一问题，他们的解决方案颇有中国传统“以子之矛、陷子之盾”式的智慧[11]：一个程序遵循Copyleft，我们首先声明它是有版权的；然后，我们给它加上发布条款，这个条款就是一个法律声明，它赋予所有人有使用、修改和重新发布程序的代码及其衍生作品的权利，但要求在这个过程中保持发布规则不变。这样的话，代码和自由权利在法律上就不可分割了。商业软件开发人员通过版权剥夺了用户的自由，我们使用版权来给予他们自由。这就是为什么我们把“版权（Copyright）”改称为“Copyleft”。Copyleft 是一种对程序进行版权保护的方法。它并不是放弃版权，实际上，这样会使 Copyleft 变得不可操作。“Copyleft”中的“left”并不使用它在英语中“离开”的意思，而是指它（left，左）与通常的“版权（Copyright）”中的“right（右）”具有镜像的关系。Sapna Kunar一针见血地指出，软件开源背后的哲学，实际上是反对通过垄断软件实现利润最大化[12]。GPL协议通过其传染性条款（Infection）实现上述目的，这也是GPL区别于MIT、BSD、Apache等宽松协议的标志，笔者将在第3部分中详细阐述。从法律技术的观点来看，GPL并非一份传统、典型的法律文件。从其制定的过程来看，GPL协议完全可以说是程序员们的作品，律师参与的功能是最大程度上保障程序员们的目的可以在法律执行（Enforcement）中得以实现。GPL的目的，是利用著作权法律中的工具来反对著作权法律对于软件的“过度保护”。因此，单纯从著作权法律的进路出发去研究、解释与适用GPL协议，可能陷入逻辑上的不自洽。当我们研究GPL条款之前，必须了解GPL协议的作者写作这些条款的目的。03 GPL协议的性质GPL在美国司法领域的早期实践中，大多以和解方式结案（例如FSF诉思科案），GPL的定性问题并未进入专业视野，反倒是德国成为第一个明确GPL具有合同效力的法域。但正如张韬略所指出[13]：FSF及其创立者理查德·斯托曼曾经旗帜鲜明地反对将GNU GPL在法律上定性为一种合同。GPL v2第五条明确表明，自由软件许可使用关系的成立不必遵循普通合同的要约和承诺过程——“因为您并未在本授权上签名，所以您无须（表示）接受本授权”。GPL v3草案第九条的标题甚至直接明示GPL 不是合同，后来应该是考虑到GPL v3的目标受众主要位于美国之外其他国家，无法回避合同法的规制（当时德国法院已经明确了德国《民法典》的合同规则对GPL v2的适用），因此最后删除了该具有争议的表述。FSF坚持GPL的法律性质不属于合同，有其美国法之下的特殊原因。第一，FSF抵制美国合同法领域的州模范法即《统一计算机交易法》（Uniform Computers Information Trade Act，UCITA），认为该模范法的推广适用对自由软件不利。FSF甚至直接在官网呼吁自由软件行业抵制 UCITA，生产“UCITA是一项由私有软件开发者设计的法律提案，它将灾难性地威胁自由软件社团。”第二，美国合同法属于州法的范畴，如果GPL的法律定性是合同，那么在诉讼之中首先会面临“联邦优先原则”的审查，判断联邦版权法是否优先适用从而排除州合同法的适用美国《版权法》第301条。而如果最后适用州法，那么GPL及版佐（笔者注：即Copyleft）条款的法律效力就取决于各州合同法的制定法和案例法。这样的维权过程将有很大的不确定性，很有可能产生不一致的裁判结果（例如有的州的合同法对合同的约因或对价有较严格的判例法规则），这绝不是自由软件社区希望看到的局面。相反，如果依照GPL的字面含义即通用公共“许可证”，将GPL认定是版权许可证，那么版佐条款的效力在美国法之下将更加牢固：一方面可以直接借助版权的排他性而具有对世效力，不必考虑合同相对性的制约；另一方面是按照许可证的相关规定，一旦软件用户违反许可证即终止版权许可。关于美国版权法律中“版权合同”与“版权许可证”的区别，Maxime Lambrecht[14]指出：在美国法律中，与其他普通法系一样，财产法区分合同许可证（Contractual License）和“单方许可证”（Bare License）[15]。如果存在某些条件：要约、接受和对价，许可证可以被视为合同。但许可也可以被视为“单方许可”：许可人允许被许可人做法律不允许她做的事情。因此，在我们的案例中，单方许可证是“版权许可证”，即在特定条件下使用作品的单方面许可，其违规行为将受到版权禁令的制裁。这两种制度之间有许多不同之处。与合同不同的是，单方许可证不需要被许可人的同意：它只是表明使用作品不侵犯版权的条件。如果不满足这些条件，许可证将不复存在，违法者将侵犯版权。因此，违反单方许可证的行为将受到版权严格责任制度的制裁，并受到严厉的法定损害赔偿。此外，虽然合同的终止受到法律（和合同条款）的限制，但单方许可证可以随时撤销。截至目前，似乎美国司法部门对于GPL协议的态度，尚在“版权合同”与“版权许可证”（单方许可证）之间摇摆，例如Jacobsen诉Katzer案以及Artifex Software Inc.诉Hancom Inc.等。幸运的是，我国既不存在合同许可和单方许可的二分，也没有联邦法和州法之间的选择困境。与德国法类似，在我国的法律体系（特别是《著作权法》第七章）项下，GPL协议只能唯一地解释为具有合同效力。但必须强调的是，GPL之所以具有合同效力，是因为在我国法律体系下并没有其他的合理解释空间，但就GPL的设计者本意而言，他们并不认为这是一份合同，GPL协议应当具有对世效力，如此可以最大限度上达成其设计GPL的目的。我们在将GPL协议作为合同解释的同时，不宜忽视上述目的。04 GPL协议的传染性及其影响如前所述，GPL协议的目的主要通过其传染性条款实现，以v2/v3两个版本为例：v22.你可以修改你的软件副本的任意部分，以构成本软件的衍生作品，并在满足上述条款及以下三点要求的前提下复制和分发该修改版：a）你必须在你修改了的文件中醒目地声明你的修改及标注修改日期；b）你必须使你分发或发布的作品，部分或全部包含本程序或其衍生作品，允许第三方在本协议约束下使用，并不得就授权收费；c)（略）v34.发布未经修改的副本 你可以通过任何媒介发布本程序源代码的未被修改过的完整副本，只要您在每个副本上显著而适当地发布一个合适的版权通告；保持完整所有叙述本授权和任何按照第7节加入的非许可的条款；保持完整所有的免责申明；并随程序给所有的接受者一份本授权。5.发布修改过的源代码 您可以第4条规定的源码形式，发布一个基于本程序的软件，或者对本程序进行修改而得的软件，只要您同时满足所有以下条件：a）作品中必须明确声明，说明修改了它，并给出相应修改日期；b）作品中必须明确声明，作品依据本授权许可证及本授权许可证…；c）您必须把整个软件作为一个整体向任何获取副本的人按照本授权协议授权…（略）FSF在其网站公布的FAQ[16]中对于GPL条款的解释，获得了我国司法机关的充分尊重并多次在相关判决中加以引用。根据这些解释，接受和使用GPL协议意味着允许（或者禁止）以下事项：(1)对于适用GPL协议的FOSS，你可以自由、免费地使用、修改；(2)如果你需要再次分发（即提供给其他组织或者个人）上述FOSS，包括未经修改或者经过修改的版本（即开源性质传染给非独立的修改或者衍生版本，除非是独立于FOSS的软件并且你不同意将其开源），需要按照GPL协议的要求发布版权声明，并允许任何人在遵守相同规则的前提下继续免费使用；(3)无论是否用于商业目的，你可以在组织内部不受限制地使用、修改上述FOSS（如果不是适用AGPL协议的情况下，甚至在网站上以SaaS形式提供商业性在线服务也可以被认定为组织内部使用），包括未经修改或者经过修改的版本，在此情况下GPL协议不会强制传染或者要求你公开该修改版本，前提是不对外再次分发；如果需要再次分发，则需要遵从前述开源规则；(4)在遵守GPL前述开源义务的前提下，GPL协议并不限制你在对外分发FOSS（包括未经修改或者经过修改的版本）时收取费用，无论销售还是捐赠，但不得将付费作为获得FOSS的前提或者强制义务。换言之，如果商业软件使用FOSS并受到传染，对外销售（无论是单独销售还是捆绑在机器中）即可能违反GPL协议；除非商业软件中能够以独立原则区分开源部分和非开源部分，保证非开源部分不受开源部分的传染，并在销售过程中确保开源部分依然遵从GPL协议；[17](5)除GPL本身规定的义务之外，GPL协议要求对FOSS的开源不附加任何其他义务，包括不得限制符合GPL协议规定的商业性使用，甚至不得限制符合GPL协议规定的军事用途。此外，对于GPL协议传染性的具体表现形式，FSF在其FAQ列举了一些认定规则和特定场景，但同时也相当明智地将具体的传染性判断规则的认定权利交给司法机关。不过从GPL协议相关司法实务来看，我国司法机关较为宽容友好地接受FSF的相应解释和规则。05 违反GPL协议的后果GPL协议对于传统法律的离经叛道，在早期曾经使人们产生一个疑问，即法律是否会真正去承认并执行它，例如微软就在2001年前后掀起的一场有关GPL协议是否可以执行的争论，直至2010年美国联邦上诉法院在Jacobsen v. Katzer案中给出可以执行的最终结果。截至目前，大部分国家均承认GPL协议是一份法律上可以执行的合同（虽然就其性质而言还存有一定争议），违反GPL协议将承担相应的后果。以GPL v2版本为例，违反GPL协议的法律后果是永久终止许可，其第7条规定：倘若你不能在发布本程序时同时满足本协议和其他文件的要求，你就不能发布本程序。这一点在GPL v3版本中进一步予以明确，其第8条规定：除非在本协议明确授权下，你不得传播或修改受保护作品。其他任何传播或修改受保护作品的企图都是无效的，并将自动终止你通过本协议获得的权利。GPL v3版本也作出两个重要的例外：（1）对于初犯者，如果你第一次收到了特定版权持有人关于你违反本协议（对任意作品）的通告，且在收到通告后30天内改正，那你可以继续享有此授权；（2）当你享有的权利如本条所述被终止时，已经从你那根据本协议获得授权的他方的权利不会因此终止。除了终止授权之外，按照各国通常的法律原则，违反GPL协议还产生侵权损害赔偿的问题，但是GPL制定者明确不以损害赔偿作为维权的首要目的，再次与著作权法律倡导的权利原则分道扬镳。FSF总法律顾问Eben Moglen在其《Enforcing the GNU GPL》[18]一文中指出，对于违反CPL协议的行为，FSF通常的要求仅仅是要求其改正并构建企业层面的GPL合规项目：在将近十年的 GPL 实施过程中，我从未坚持要违规方向基金会支付违规带来的损害赔偿，也极少要求违规方公开承认错误。我们的立场一直都是以保证合规与不再违规作为最重要的目标。我们尽量让违规者能够更容易做到合规，并且我们一直是既往不咎。这一思路也体现在GPL v3版本修订中，与v2版本不同，违反GPL v3版本协议的初犯者如果在收到通告后30天内改正，允许其继续享有授权。当然，FSF认为应将违反GPL协议的损害赔偿交给司法机关判断，而司法机关在适用不同法域的法律、尤其是在对GPL协议进行合同解释时，不能不考虑GPL协议及其制定机构FSF对于侵权损害赔偿的态度。正如张韬略所指出的[19]：在国内罗盒系列案之中，我们看到自由软件版权人分别提出了1500万（罗盒诉玩友）和2000万（罗盒诉风灵）的高额损害赔偿金请求[20]，这样的主张明显是将追求经济利益作为最主要目的，已经开始带有“版权流氓”（copyright troll）的味道，显然与FSF的自由软件社区导向的理念是完全相悖的。对这类行为，我国法院宜立足于自由软件许可证本身及社区所倡导的理念与原则，从严适用损害赔偿计算的相关规则。在罗盒诉风灵案件中，深圳市中级人民法院在考虑开源软件在侵权软件中所起的作用、FOSS权利人履行GPL协议的情况、开源软件的商业版本对外授权许可情况以及侵权方的侵权行为性质、侵权时间及拒不履行开源协议等因素的前提下，酌定侵权方赔偿50万元，而FOSS权利人的诉讼请求为损害赔偿（2000万元）以及维权开支（50万元）。而在罗盒诉玩友案件中，广州知识产权法院以几乎相同的理由酌定侵权方赔偿50万元，FOSS权利人的诉讼请求为损害赔偿（1500万元）以及维权开支（15万元）。耐人寻味的是，网经公司案中，人民法院同样酌定侵权方赔偿50万元，这恐怕无法完全以巧合来解释。最后，使用人违反GPL协议、未能公开衍生软件的源代码的情况下，FOSS权利人是否可以按照GPL协议的规定，强制要求使用人披露上述衍生软件的源代码？张韬略的观点[21]是，在现阶段仅有理论探讨的意义，中外法庭支持这种激进主张的可能性很小。06 GPL协议的传染性对于软件侵权案件的影响（1）单一侵权类案件根据前述规则，假设特定的FOSS权利人发布一项FOSS并加入GPL协议，使用人在商业软件中使用了上述FOSS并传染到衍生软件：(a)如果使用人未能遵从GPL v2版的规定予以发布商业软件，按照GPL v2版的规定，使用人的授权将被永久终止，理论上FOSS权利人有权要求使用人给予损害赔偿；(b)如果使用人未能遵从GPL v3版的规定予以发布商业软件，按照GPL v3版的规定，FOSS权利人应给予初犯者30天的整改宽限期，如果使用人在期限内未能按照GPL协议的规定予以开源，则使用人的授权将被终止，理论上FOSS权利人有权要求使用人给予损害赔偿。但GPL协议的本意仅在于制止使用人的不合规行为，如果司法机关按照著作权法律的一般原则给予高额的损害赔偿，不符合GPL协议的目的。（2）连续侵权类案件在连续侵权案件中，假设特定的FOSS权利人发布一项FOSS并加入GPL协议，而使用人1在商业软件1中使用了上述FOSS并传染到衍生软件（如有）但未按照GPL协议的要求公开衍生软件的源代码，而使用人2未经使用人1的同意在商业软件1的基础上修改形成商业软件2，同样也未按照GPL协议的要求公开其修改的源代码（如有）。这一情形较为复杂，但恰恰在我国司法实践中较为常见，试分析如下：(a)商业软件1中属于FOSS权利人的开源部分（未修改部分），假设适用GPL v2版的规定，因使用人1未按照GPL协议的要求公开衍生软件的源代码，导致其使用FOSS权利人的开源部分的授权终止；(b)商业软件1中因对FOSS权利人的开源部分进行修改、编译等原因受传染而应当开源的衍生部分，不宜轻易否定使用人1的著作权。虽然GPL协议规定衍生部分受传染而应当公开，但按照GPL的规定以及著作权法律的原则，使用人1未公开衍生部分源代码的后果仅是失去开源部分的使用授权，GPL协议本身未规定衍生部分的著作权因传染而失权。此外，受我国《民法典》项下合同相对性的限制，除FOSS权利人之外的第三人应无权要求使用人1公开衍生部分的源代码，况且在现行法律框架内即便是FOSS权利人也难以强制使用人1公开上述源代码。因此，使用人2承担其侵权使用衍生部分的赔偿责任应无异议。但应当指出，GPL协议的目的带有强烈的公益性和对世效力，使用人1在使用FOSS开源软件时应视为明知GPL协议对其衍生部分所作出的权利限制，司法机关在酌定使用人2的相应侵权责任时似应充分考虑这一点，对GPL协议示以应有的尊重；(c)商业软件1中未受传染的独立部分，即使按照GPL协议也属于使用人1的著作权，使用人2应当按照《著作权法》的规定承担侵权责任。三、结 论我国《著作权法》第1条开宗明义地指出，著作权的目的是“保护文学、艺术和科学作品作者的著作权，以及与著作权有关的权益”。但GPL协议的目的并非如此。GPL协议的制定者认为，软件不应受到著作权法律的过度保护，希望对软件的财产性质进行平衡、弱化，抵御软件成为著作权之后的强大财产属性。略有讽刺的是，最终他们选择以著作权保护的方式实现上述目的，以保障软件的自由传播、使用以及修改，这一功能主要通过GPL协议中的传染性条款予以实现。GPL协议的制定者认为，即便通过著作权保护的方式保障软件自由，其目标效果也仅仅是促成违反者的合规经营：尊重开源，促进软件自由。他们并不追求将损害赔偿作为违反GPL协议的救济目的，因为这与他们设计这一机制的目的背道而驰。其次，他们希望GPL协议拥有对世效力，而不仅仅是FOSS权利人与使用者之间的合同（至少在普通法体系下是如此），但是他们也尊重不同法域将GPL协议作为合同处理（从GPL v3版本的修改过程可以得出这一结论）。让我们回到问题的开端。未来案件中，GPL协议制定者一定会对以下文字击节叫好：“对原告违反GPL协议的行为给予侵权法上的保护，势必虚置GPL协议关于源代码持续开源的相关规定”，但从法律角度审视，可能失之偏颇（当然这也可能是因为判决书篇幅的原因导致我们未能掌握全部事实）。如前所述，未来公司在开源软件中不享有任何权益，更何况还存在违反GPL协议的行为，给予侵权保护不符合法律精神；但如果未来公司对开源软件的二次加工形成衍生软件，未来公司未公开衍生软件部分的源代码导致其违反GPL协议，违约后果也只是未来公司无权继续使用开源软件，但GPL协议并没有排除未来公司就衍生软件部分享有的著作权，理应按照《著作权法》并考虑其已受到GPL协议传染的因素，给予一定程度的保护，尤其在侵权方恶意使用的情况下，否则可能造成实体上的不公。至于网经公司案，笔者对于法官基于合同相对性而对网经公司是否违反GPL协议不予理涉的分析进路持保留意见。首先，GPL协议中并未授权使用人1就开源部分行使诉权，无论GPL协议是否终止，使用人1至少就开源部分不存在起诉、胜诉的权利。其次，根据GPL v2版协议的规定，网经公司的违约直接导致其永久失去开源软件部分的许可，而且GPL协议项下的许可没有《著作权法》项下的财产权益、也不产生再许可的利益；如是，被诉侵权方的侵权客体如何确定？损害的范围、程度如何界定？显然这将导致判决陷入不能逻辑自洽的境地。更何况，GPL协议的制定目的本身即带有强烈的对世色彩，虽然在我国《民法典》中找不到相应的立足点，但在解释GPL协议条款时似不应忽视这一因素。当然，也不排除限于判决书篇幅的原因而导致事实披露不充分，法官有可能已经充分考虑开源部分与衍生部分在侵权客体中的比例，最终给出了一个笔者认为尚属公允的判决结果。事实上，类似的案件早在2004年即在美国出现。在Computer Associates International, Inc.（“CA”）诉Quest Software, Inc.（“QUEST”）及其员工一案中，被告Quest公司指出原告诉称被侵权的软件中含有违反GPL协议的开源代码。相当部分的美国学者和司法界人士认为，根据美国联邦最高法院1945年在Precision Instrument Mfg. Co. v. Automotive Co.案中确立的“净手（clean hands）原则”，如果原告违反GPL协议并试图起诉被告侵犯软件著作权，被告可以原告不符合净手原则而提出抗辩[22]。最终，CA与QUEST以和解方式结案。涉及GPL协议的软件侵权案件中，所有当事人有必要扪心自问：是否带着干净的手进入法庭？注释[1] Linux获得巨大的成功之前，自由软件运动不怎么为人所知，而众所周知，Linux的诞生是对Unix的叛逆。[2] 参见https://www.gnu.org/gnu/thegnuproject.html，脚注3，最后访问于2024年1月18日[3] https://www.gnu.org/licenses/old-licenses/gpl-2.0.html#SEC3，非官方的中文翻译可参见https://jxself.org/translations/gpl-2.zh.shtml[4] https://www.gnu.org/licenses/gpl-3.0.html，非官方的中文翻译可参见https://jxself.org/translations/gpl-3.zh.shtml[5] GPL 的第一个v1版本发布于1989年。GPL v3版本发布于2007年但并未取代GPL v2版本，两个版本目前处于共存状态，GPL v2仍然是GPL诸多版本协议中最为常用的一个，此外还有LGPL（更为宽松）和AGPL（更为严格）两个版本的协议。只能由开源软件的最初版本开发者选择适用何种GPL协议。[6] Sapna Kumar：《ENFORCEING THE GNU GPL》，P2，参见https://scholarship.law.duke.edu/cgi/viewcontent.cgi?article=2505&context=faculty_scholarship，最后访问于2024年1月18日[7] https://www.gnu.org/philosophy/enforcing-gpl.zh-cn.html，最后访问于2024年1月28日[8] 正如丁华、陈岱源所称：GPL开源协议具有“纵向”和“横向”两个维度的“传染性”。在“传染性”的“纵向”维度上，开源软件会“传染”自身的修改版本（modifications）或衍生作品（a work based on the Program）。例如GPL.v2授予后续开发者修改开源软件（及其副本）的权利，但是对于修改后形成的修改版本或衍生作品，一旦涉及到分发（distribute）或公布（publish），则应满足使得修改版本整体继续依照对应的GPL协议进行开源。在“传染性”的“横向”维度上，在一定的条件下，开源软件会“传染”自身及修改版本以外的，一同分发、传输的软件或软件的其他部分。例如，GPL.v3规定，如果在开发者传输的软件时，开源软件与其他软件之间组合的目的是为了生成一个更大的程序，则其他软件也需要成为受到相应的GPL协议传染的开源软件。参见https://www.allbrightlaw.com/CN/10475/5d3121e725d018ea.aspx，最后访问于2024年1月18日。本文中笔者出于行文方便考虑，将“纵向”和“横向”两个维度的被传染部分统称为“衍生作品”。[9] https://my.fsf.org/donate?mtm_campaign=fall23&mtm_source=banner，最后访问于2024年1月18日[10] https://www.gnu.org//licenses/copyleft.zh-cn.html，最后访问于2024年1月18日[11] 同上[12] Sapna Kumar：《ENFORCEING THE GNU GPL》，P4，参见https://scholarship.law.duke.edu/cgi/viewcontent.cgi?article=2505&context=faculty_scholarship，最后访问于2024年1月18日[13] 张韬略：《请求停止侵权还是披露代码？——违反自由软件“版佐”许可条款的责任承担方式》，载于《电子知识产权》2022年第8期[14] 参见https://www.technollama.co.uk/us-court-declares-gpl-is-a-contract，最后访问于2024年1月18日[15] 也称为pure license，这一般认为是普通法中不动产法律中的概念。Sapna Kunar指出，纯许可证是指一种从事某种行为的、可撤销的许可，如果没有这一许可可能导致违反法律。有了这一许可，被许可人可以合法地进入他人的土地从事某种行为…在不动产法之外，这类许可包括停车区域、林业许可和结婚证，这些许可大部分都是由政府颁发。对大陆法国家以及我国而言，上述许可带有强烈的公法色彩，通常不会由私人或者私人组织来颁发。[16] 参见https://www.gnu.org/licenses/gpl-faq.en.html，最后访问于2024年1月18日[17] 有一些商业软件为使用者保留两种选择权：适用开源协议，承担开源义务，免费使用该软件；或者从权利方购买商业许可，不承担后续的开源义务。从GPL协议的观点来看，似乎并不违反GPL协议。[18] https://www.gnu.org/philosophy/enforcing-gpl.zh-cn.html，最后访问于2024年1月18日[19] 张韬略：《请求停止侵权还是披露代码？——违反自由软件“版佐”许可条款的责任承担方式》，载于《电子知识产权》2022年第8期[20] 济宁市罗盒网络科技有限公司与广州市玩友网络科技有限公司等侵害计算机软件著作权纠纷案（广州知识产权法院（2019）粤73知民初207号民事判决书）以及济宁市罗盒网络科技有限公司与广州市玩友网络科技有限公司等侵害计算机软件著作权纠纷案（广州知识产权法院（2019）粤73知民初207号）[21] 张韬略：《请求停止侵权还是披露代码？——违反自由软件“版佐”许可条款的责任承担方式》，载于《电子知识产权》2022年第8期[22] Sapna Kumar：《ENFORCEING THE GNU GPL》，P31，参见https://scholarship.law.duke.edu/cgi/viewcontent.cgi?article=2505&context=faculty_scholarship，最后访问于2024年1月18日（本文仅代表作者观点，不代表知产力立场）封面来源 | 知产力
0 评论