兰迪研究 | 开源协议专题二：GPL协议的法律解析（上）

作者 | 黄克、周庆越

严格开源协议具体可以分为强传染性和弱传染性两类，前者包括GPL（GNU通用公共许可证）等，后者则包括MPL（Mozilla公共许可证）等。二者的区别在于：强传染性协议（GPL）要求任何基于该协议发布的软件及其衍生作品都必须以相同的许可条款发布，确保整个项目的源代码开放；而弱传染性协议（MPL）则允许部分代码在特定条件下保持闭源，但仍然要求某些核心部分或修改的部分保持开源。

GPL协议共有三个版本，本文将以《GNU通用公共许可证第三版》（GNU General Public License version 3，以下简称GPL v3）^[1] 为例，分为上下两篇详细探讨其主要内容和法律性质。上篇将重点介绍GPL v3的主要条款，旨在提供一个全面的理解框架。鉴于传染性条款的重要性及其对开源社区的影响，下篇将专门探讨这一关键条款，深入分析其法律含义和应用。

GPL v3是自由软件基金会（Free Software Foundation, FSF）于2007年发布的开源软件许可协议，旨在确保软件的自由使用、修改和分发。它与前两版的内容对比如下：

1. 权利许可条款

权利授予与不可撤销性：协议第二条是基本许可条款，其授予的权利在程序版权有效期内均有效，并且在满足规定条件的情况下不可撤销。这一条款确保了权利的长期性和稳定性，防止软件原作者或权利人随意撤销已授予的权利。具体而言，只要用户遵循开源协议的规定，即使创建者或发布者将软件由开源转为闭源，也不能阻止用户对已经开源的版本的使用。

例如，在罗盒诉玩友案中^[4]，罗盒公司的股东之一罗某开发完成涉案软件的初始版本后，将软件源代码上传至GitHub开源社区，并最终选择适用GPL v3开源协议。随后，罗某将其软件著作权转移给罗盒公司，该公司删除了该协议并停止更新该项目，转而开发不开源的商业版本。对此，广州知识产权法院认定，即使授权方删除GPL v3协议，该行为也不具有回溯力，根据协议规定和特性，一旦某个软件版本采用了GPL v3协议，那么这个版本的源代码就必须永远保持开源状态。即使原授权方试图移除该协议也不会对已发布的版本产生影响；授权方仅能在后续的新版本中更改或取消该协议，但这不会改变之前版本依然遵循协议的事实。这一判决从司法层面进一步确认了GPL v3协议下权利授予的不可撤销性，强化了在保护开源软件自由传播方面的法律效力。

2. 专利许可

授予专利许可：协议第十一条规定，每个贡献者都授予使用者一个非独占、全球性、免版税的专利许可，允许使用者在贡献版本的基础上进行制作、使用、销售、修改、传播等活动。这意味着如果软件涉及到专利的内容，贡献者通过本许可证授予专利许可，允许其他人免费使用其专利技术。

歧视性专利许可：如果专利许可的范围有限制，或专利许可的条件不允许行使协议下的某些权利，则该专利许可就被视为歧视性专利许可。协议禁止授予歧视性的专利许可（除非是在GPL v3颁布之前）。这条目的是避免专利许可的限制影响到作品的自由使用。

3. 许可方式

自动许可机制：根据协议第十条的规定，当受保护作品被传递时，接收者将自动从原始授权方获得一个许可证，允许他们按照本许可证的条款运行、修改和传播该作品。这样即使在多层分发的情况下，也能保持软件的开放性。此外，授权方不得附加额外的限制，旨在防止限制软件的自由使用的情形。

专利许可的自动扩展：根据协议第十一条的规定，若授权方在传播受保护作品时向某些接收者授予专利许可，则该专利许可将自动扩展至所有接收者。这一规定旨在禁止传播者对接收者进行差别对待，确保GPL许可的普遍适用性。

4. 接受许可的时间

根据协议第九条的规定，接受该协议的时间点是在实际进行受保护作品的修改或传播时。具体而言，接收和运行程序本身并不强制要求接受GPL协议，即下载、安装或使用软件并不需要接受该协议，协议第二条亦有类似内容，用户可以无限制地运行程序的未修改版本。只有当程序的运行输出本身构成一个受保护作品时，该输出才会受到GPL协议的约束。此外，通过点对点传输接收到副本所引发的辅助性传播也不需要接受协议。然而，一旦决定对受保护作品进行修改或传播，则必须在执行这些行为之前接受GPL协议。此时用户的行为本身就表明已经接受协议，并且必须遵守其条款。

1. 转发完整副本

传播原样复制品的条件：协议第四条允许用户在任何媒介上复制和分发未经修改的软件源代码，但需保留版权声明、附加条款、许可证声明及免责声明的完整性，并提供许可证副本。

收费与支持服务的灵活性：协议允许权利人自由选择是否对软件转发收费。开发者与分发者可以选择不收取任何费用，直接将软件提供给任何人使用，也可以选择收取一定的费用来分发软件，还可以提供额外的服务，比如帮助安装、配置软件，解决使用中遇到的问题等收取额外的费用，以支持商业利用。

2. 转发修改过的源码版本

协议允许以源码形式转发基于本程序的作品或修改的内容，用户如果对源代码修改后再分发，则需要满足以下条件。

首先满足转发完整副本的要求：传播修改过的源代码首先需要满足上一条的要求，既传播原样复制品的要求。

其次要满足以下条件：

a）作品须显著标明修改信息及日期。

b) 作品须显著标明其在本许可证下发布，并符合第7条添加的任何附加条款。

c) 必须将作品整体在本许可证下向任何接收副本者授权，即只能按照GPL协议来授权整个作品，以确保所有部分都遵循相同的开源规则。

d) 若作品含有交互式用户界面，则需显示适当的法律通知；但若原程序的交互界面未显示此类通知，则无需显示。

关于集合的规定：协议明确当被许可的作品与独立作品汇编在一起但不形成更大程序时，这种汇编称为“集合”。集合中的其他独立部分只要保持独立并不与开源软件紧密结合，则不受GPL协议约束。此条款旨在防止“传染效应”影响到无关的软件，允许商业开发者将开源和专有软件共同发布而不必开放所有软件的源代码。

如在不乱买诉闪亮时尚案^[5]中，法院认为涉案软件的前端代码与后段代码可以是相互独立的，前端代码由于使用GPL下的开源代码而应当开源，而后端代码作为独立程序并未受到“传染”，因此不受GPL协议约束。GPL协议要求开源的是本身接受其协议的软件代码及针对这些软件代码的修订或者根据这些软件代码开发的延伸程序，而不包括与这些代码有数据交换等联合的其他独立程序。

3. 以非源码形式转发

协议规定在传输非源代码形式（例如以二进制形式分发）的覆盖作品时，必须提供相应的源代码和安装信息，以确保用户能够修改和运行软件。它强调开发者不需要提供持续的技术支持或更新，同时要求源代码和安装信息应公开且易于访问，确保用户能够充分行使修改和再分发的权利。

协议第七条规定，授权方和被授权方能够在GPL协议的基础上增加特定的附加条款，这些附加条款在GPL标准条款的基础上限制或放宽某些要求，但不得对开源软件的核心自由（如使用、修改和再分发的权利）造成不当限制。

1. 适用范围

附加条款可以适用于整个程序或者程序的一部分。如果附加条款适用于整个程序，则被视为开源协议的一部分；如果附加条款仅适用于程序的一部分，则该部分受附加条款约束，其他部分不受影响。

2. 删除附加条款

被授权方在传播被GPL覆盖的作品时，可以选择删除任何附加权限，将作品恢复到标准的GPL条款下进行分发。

3. 新增附加条款

被授权方在拥有版权许可的前提下，针对其贡献的材料可以增加附加条款，即可以针对其贡献的部分施加额外的限制或者豁免。

4. 进一步限制的处理

任何不属于附加权限的限制条款都被视为“进一步限制”（further restrictions），这违反了GPL的核心精神。GPL协议允许删除这些条款以恢复对用户的全部自由，确保任何附加条款都不能削弱软件的开源本质。

5. 公开声明要求

添加附加条款后必须在相关的源代码文件中明确声明这些附加条款，或说明在哪里可以找到这些条款，目的是使下游用户能够清楚了解其权利和义务。

1. 程序无担保

协议第十五条规定，除非另有书面说明，程序按“现状”（“as is”）提供，不作任何明示或暗示的担保，版权持有人和其他分发方不对程序的质量、性能或缺陷承担任何责任。程序的质量和性能风险完全由用户承担。如果程序出现缺陷，用户需自行承担修复、维护或纠正的全部费用。

2. 责任限制

协议第十六条明确了版权持有者不对程序的使用或无法使用承担任何责任，免责主体范围包括版权持有人与修改或分发的主体，前者是程序的著作权人，后者包括根据GPL许可证，合法修改和传播程序的贡献者。责任免除的损害类型包括一般性损害、特殊损害、附带损害、间接或后果性损害。

3. 尊重当地法律

协议第十七条明确责任的免除需要尊重当地法律的要求，如果当地法律强制要求责任不能被完全排除，则免责条款可能不被完全认可。如果免责声明或责任限制无效，GPL v3要求当地法院裁判时适用最接近绝对豁免的本地法律。绝对豁免是指尽可能地免除版权持有人或分发者的全部民事责任，按照该条款约定，法院应寻找尽可能相似的法律条款，最大程度地接近原条款意图。

需要注意的是，GPL协议本身是私人主体之间的约定，仅代表当事方之间的意思表示，难以约束公权力主体的行为，司法机关有权按照当地法律规定独立行使司法裁量权。因此该条款具有参考作用，但是其能否实际执行有待考量。

1. 触发条件

许可证的自动终止：一旦用户违反了许可证中的任何条款（例如未按要求公开修改后的源代码），其依据GPL v3所获得的所有权利，包括但不限于复制、修改、分发以及专利许可等将自动终止。这意味着用户将立即丧失继续使用、修改和分发该软件的合法权利。

2. 恢复权利的途径

（1）暂时恢复

如果用户停止了所有违反GPL条款的行为，则版权持有人对其许可将暂时恢复。这种恢复是暂时的，版权持有人可以终止该许可。这给违反者提供了一个缓冲期，以纠正其行为并重新遵守GPL协议。在此期间，用户可以继续使用软件，但风险在于版权持有人随时可以终止许可。

（2）永久恢复

如果用户在停止违反GPL条款的行为后，版权持有人在60天内未通过合理方式通知用户该违反行为，则该许可将被永久恢复。这种条款保护了用户免于因偶然或不知情的违规行为而受到永久性的惩罚，鼓励版权持有人及时行使其权利。

3. 首次违反的救济

如果版权持有人通知用户其违约行为，并且这是用户首次收到该版权持有人的违规通知，则用户有30天的宽限期来纠正该违约行为。如果用户在此宽限期内成功纠正，许可也将被永久恢复。这为用户提供了一个纠错机会，并鼓励用户在收到通知后迅速采取补救措施。

4. 法律后果

侵权风险：授权终止后，用户不得继续适用软件源代码，包括使用、修改、分发或以任何方式传播该软件。若用户在授权终止后继续进行上述行为，将因丧失权利基础而构成对原著作权人权利的侵犯，带来侵权诉讼风险。

对下游用户的影响：即使某个用户因违反GPL条款而丧失了其权利，并不会影响下游用户的权利。即已经从违规用户那里合法获得软件的第三方用户的许可证将继续有效。这种保护措施确保了下游用户不会因为上游供应商的行为而受到连带影响，从而保持了开源软件分发链条的稳定性。

对未来许可证的限制：如果用户在某一作品上因违反GPL条款而丧失权利，则该用户不能再根据GPL协议继续获得该作品的许可。这是一种“逐出”机制，旨在保护开源社区免受恶意或持续违反GPL条款的行为侵害。

1. 版权持有人

版权持有人是对作品享有版权的个人或实体，具备授权和许可的权利。GPL v3 中提到的“版权”不仅指作品的创作，还包括了相关的修改和派生作品。版权持有人的范围通常包括：

原始作者：最初创作源代码或作品的个人或组织。

衍生作品的作者：对原作品进行修改或扩展的人，形成衍生作品后，他们对衍生作品的部分修改或新增部分享有版权。

2. 被许可人

被许可人（也被称为使用者、用户）指的是根据 GPL v3 协议获得许可使用软件的个人或实体。被许可人可以在遵守 GPL v3 协议的前提下，修改、使用、复制和分发软件。

3. 原始作品

原始作品是指最初由作者创作并拥有版权的作品，包括源代码、文档或其他形式的表达。在开源软件中，原始作品指最初被发布的源代码，它是其他衍生作品的基础，原始作品与衍生作品共同构成了受保护作品。

4. 衍生作品

衍生作品指的是对原始作品进行修改或改编的作品，包括但不限于添加新功能、改动源代码或将其与其他程序进行组合。任何基于原始作品的“修改版”都属于衍生作品。衍生作品必须遵循 GPL 协议的条款来发布，即无论原始作品或衍生作品都必须在 GPL 协议下分发。

5. 贡献与贡献者

贡献通常是指向开源项目提交的任何形式的改进、修改、修复、功能增加或其他内容。贡献不仅限于代码，还包括文档、测试、界面设计、bug修复等任何形式的输入。贡献者向开源项目提供的代码、文档或改进有时会作为项目的一部分被接受并集成。

贡献者是指向开源项目提供贡献的人或组织。贡献者不仅包括开发者（如提交代码的人），还包括文档编写者、bug报告者、测试人员等。在很多开源项目中，贡献者通常通过提交 pull requests、补丁、bug 修复或新功能来参与项目。

如果用户只是修改源代码并发布衍生作品，而没有直接向原项目的管理者提供改进或提交代码，这个用户通常不会被视为对原项目的正式贡献者。贡献者通常是向原项目提交了代码或其他贡献，并且通过原项目的管理者进行合并的用户。

6. 声明

在 GPL v3协议中，声明（Notice）是一种重要的法律和合规要求，通常用于向用户和其他开发者明确告知作品的版权、许可证信息、贡献者信息等。核心目的是确保上述信息清晰透明，便于用户理解其权利和义务。

GPL v3协议中有 7 种需要声明的情形，包括：

7. 具体流程

当开发者创建一个程序后，该程序成为受著作权法保护的作品，开发者成为版权持有人。开发者可以选择是否公开软件源代码，若其选择开源并适用GPL v3协议发布，该程序成为原始作品，是受保护作品的一种。发布时，开发者需要遵守 GPL v3的条款，确保源代码的开放性，并在发布中保留原作者的版权声明。

若其他用户在原始源代码基础上进行修改（或其他方式）并创建衍生作品，他们可以选择将衍生作品发布或提交给原作者合并，若选择提交修改并经过开发者审核并入，则用户成为贡献者，对修改部分拥有版权，但仍需遵守 GPL v3协议，保留原版权声明并在修改部分附带修改说明等。后续的用户可以基于新版本进一步开发或进行商业用途，但必须继续遵循 GPL v3协议，确保源代码公开和可自由修改。具体参见流程图：

对于GPL协议的法律性质，有观点指出，GPL协议实质是权利人将其复制权、发行权、修改权等附条件地许可给不特定公众的著作权许可使用合同^[6]，在范围上与一般著作权许可使用合同不同，其面向的是不特定的主体。在罗盒诉玩友案^[7]中，广州知产法院认为GPL v3协议属于附解除条件的非典型著作权许可使用合同，同时也是一种格式合同。在罗盒诉风灵案^[8]中最高院认为，GPL v3协议的内容具有合同性质，开源软件的发布可视为要约，用户使用即为承诺，在用户使用开源软件时合同成立。由此可见，GPL v3协议是版权持有人与使用者之间的著作权许可使用合同，授权使用者在特定条件下享有对软件的使用、修改、再分发等权利。

GPL v3的一个核心特点是其明确规定了自动终止授权条款。根据协议第八条，若用户未按照协议条款进行使用、修改或分发作品，该用户的许可证将自动终止。在实践中，涉及开源协议的侵权案例通常源于GPL v3终止授权条款的规定，一旦接收者违反了许可证的条款，其依据GPL v3获得的所有权利将立即终止。此时如果接收者在授权终止后即刻停止对软件源代码的所有使用、分发等行为，则通常不会构成侵权。然而，具体的侵权行为往往发生在授权终止后的后续使用行为中。如果接收者在授权终止后继续使用该软件源代码，无论是通过修改还是分发，这些行为均缺乏合法的权利基础。因此，这种未经授权的后续使用行为将构成对原始作者或其他贡献者版权的侵犯。

在罗盒诉玩友案中^[9]，法院认为如果用户违背条款规定，那么许可的前提条件已不复存在，则用户因GPL v3协议获得的授权也将自动终止。玩友公司再使用涉案软件已没有法律和合同依据，故其构成对涉案软件的侵权。同样在未来科技诉云蜻蜓案^[10]中，法院认为GPL协议约定，发布或出版的软件作品（包括程序的全部或一部分，也包括自由程序的全部或部分演绎而成的作品）整体上必须受该许可协议条款的约束。如果被许可人违反许可条件，则协议自动终止全部的授权，被许可人不得对开源软件进行复制、修改、再授权或发布。

第八条不仅确立了违反协议后授权自动终止的机制，同时也详细规定了授权恢复的条件和程序，当被许可人停止违反协议的行为后，其授权是可恢复的。具体来说，若版权持有人在被许可人停止违反协议后60天内未采取行动明确通知并终止授权，则该授权将自动且永久地恢复，允许被许可人继续合法使用、修改和分发受保护的作品。这意味着在60天期限内，被许可人可以在停止违反协议后暂时恢复授权，之所以是暂时的，是因为版权持有人有权基于之前的违约行为，在60天期限内通知被许可人以正式终止授权。如果版权持有人未在此期间指出侵权行为，则默认同意永久恢复授权。该条款通过设立清晰的时间框架来平衡版权持有人的权利与被许可人的权益，确保即使出现违规情况，双方仍有机会通过改正错误而重新建立信任及合作。

同时根据第三款的规定，如果被许可人首次收到版权持有人关于违反协议的通告，并在30天内改正了违约行为，则可以继续享有授权，这是永久恢复授权的情形之一，也是针对首次违反协议而收到通告的特别保护。第三款的规定引发了几个值得探讨的问题：首先，版权持有人是否负有通知被许可人违约行为的义务？其次，版权持有人在未发出通知的情况下直接主张侵权，这种做法能否得到法律的支持？

关于权利人在起诉前是否存在必须履行的前置程序，最高院在罗盒诉风灵案中表明^[11]，第八条主要约定了本协议终止授权的情况，其中第二款与第三款规定了特定情形下可以导致授权恢复的两种情况。但是，就此认为权利人行使诉权之前必须履行“前置程序”是一种误读。权利人有自由选择争议解决方式的权利，协议第八条仅明确了权利人选择发出通知这一方式会导致授权效力的何种变化，但其中涉及的“通知-改正”程序并不构成解决争议的必要条件。因此，本案权利人在起诉前并不存在必须履行的前置程序。从这个角度来看，第八条中关于授权恢复的规定，不会赋予版权持有人通知的义务，在未经通知的情况下可以起诉指控被许可人的侵权行为。

确实GPL协议第八条并没有明确约定“通知-改正”属于前置救济程序，但是结合第八条的内容来看，其终止授权、授权恢复、首次违约救济的约定之间具有一定的关联性，应当作为整体看待，第二款与第三款是针对第一款授权自动终止的必要补充与限定，如果忽视第二款与第三款的规定，直接通过第一款认为授权自动终止，主张被许可人即刻构成侵权，则会导致二三款规定的救济内容失去意义。其次，从维护秩序的角度而言，协议赋予了被许可人停止违反协议后的救济权利，这是开源社区维护自由、平等的开源秩序的一种手段，提倡通过“通知-改正-恢复”的方式修正违约行为，恢复正常的秩序，对于重复、恶意的违约行为则可以通过诉讼制止或维权，以避免社区用户陷入突发性诉讼的恐慌。因此，即使GPL本身并未约定权利人有先行通知的强制义务，也应当鼓励权利人优先通过“通知-改正-恢复”途径进行救济，这样既可以节省诉讼资源，同时也可以更高效的维护开源社区的秩序。

在GPL协议框架下，原告资格的认定主要基于项目管理人在项目中的主导地位及其贡献程度。如果项目管理人不仅上传了初始版本的源代码，还提交了大部分后续代码，并且其他贡献者的代码需经其审核同意才能合并到主分支中，那么可以认为该项目管理人对软件拥有实质性的控制权。此外，考虑到开源项目的特性，要求每一位贡献者都提供明确授权以提起诉讼是不切实际的。因此，在这种背景下，项目管理人有权单独提起侵权诉讼，来维护软件及相关权益。

这一点在罗盒诉风灵案中得到了最高院的支持。在开源软件项目中，项目管理者通常对源代码的发展具有决定性作用。当贡献者主动加入并参与到项目时，可被视为他们默示地授予了项目管理者代表整个项目进行法律维权的权利。因此，除非有特别约定，否则项目管理者无需再寻求每位贡献者的个别同意，即可自行发起相关法律程序，以保护软件不受侵犯。

GPL许可证相比较于MIT、Apache 2.0系列的许可证，其约定更为全面，包括不同类型的转发行为需要遵循的条件，通过传染条款、授权终止和救济条款确保开源秩序的强制执行力。同时GPL许可证也是目前国内诉讼案件中涉及最多的许可证类型，但是目前的诉讼中GPL许可证多为被告针对侵权诉讼提出的免责抗辩，原告主动基于GPL协议提出恢复授权或强制开源的诉讼较为少见，整体处于较为初级的阶段。实际上基于GPL协议的强传染性及可诉性，完全可以设计多元化的诉讼方案，为客户实现其商业需求。下一篇文章我们将深入探讨GPL协议的传染性条款的法律含义及其应用，希望可以为关注此领域的专业人士及研究者提供有价值的参考，共同维护开源社区的良性竞争秩序。