目次

一、GPL许可证：开放以著作权为基础

二、多人协作中的诉权：项目管理者能否独立主张权利

三、违反许可条件后的责任：从授权终止到侵权认定

四、权利人未履行开源义务时的抗辩：权利基础与被告责任的分别审查

五、结语

开源软件已经深度进入商业软件、移动应用、云服务和智能终端的开发过程。代码的公开扩大了协作范围，也使著作权、许可条件与商业利用之间的关系更加复杂。在GPL许可证引发的纠纷中，真正进入裁判的通常是三个更具体的问题：多人持续贡献代码时，谁有权代表项目主张权利；使用者违反许可条件后，授权状态如何与著作权侵权相衔接；权利人自身未履行开源义务时，被告能否据此排除侵权责任。近年来的典型案件，已经围绕这三个问题形成了较为清晰的司法展开。

一GPL许可证：开放以著作权为基础

GPL的全称为GNU通用公共许可证，由自由软件基金会为GNU项目制定并持续修订。GPL允许使用者运行、复制、修改和传播受许可约束的程序；当使用者向他人传播原程序、修改后的程序或者相应目标代码时，还需按照具体版本履行保留版权及许可声明、提供对应源代码以及继续适用GPL等条件。因此，开源并未使软件进入公有领域。著作权仍然构成许可证得以设定使用边界、约束后续传播的法律基础。[1]

实践中常以“传染性”概括GPL的持续开放要求。这个说法能够说明GPL与MIT、Apache等宽松许可证之间的差异，但不足以直接解决具体案件。GPL义务是否触发，仍需结合许可证版本、被诉行为是否属于传播、争议代码是否构成受GPL约束的作品，以及相关代码与软件其他部分之间的关系判断。仅因软件中出现GPL组件，便推导整个项目当然负有公开全部源代码的义务，容易超出许可证文本与案件事实。

由此，GPL纠纷的裁判通常沿着一条具体路径展开：先查明代码来源与权利主体，再判断被诉软件是否实际使用相关代码，继而审查被诉行为是否取得许可、许可条件是否履行，最后才进入著作权侵权及责任承担的判断。下面三个案件问题，正是这一权利结构在诉讼中的具体呈现。

二多人协作中的诉权：项目管理者能否独立主张权利

开源项目往往由发起人、项目管理者和大量外部贡献者共同完成。贡献者可以持续提交代码，项目管理者则通过审核、合并和版本发布形成主分支。这种协作方式使传统的权利证明面临一个现实问题：当主分支代码被侵害时，项目管理者是否必须逐一取得所有贡献者的授权，才能提起诉讼。

在福建风灵创景科技有限公司等与济宁市罗盒网络科技有限公司侵害计算机软件著作权纠纷案[2]中，罗盒公司创建并管理VirtualApp项目，将初始源代码发布于GitHub。用户提交的修改首先存在于个人分支，只有经过项目管理者审核并合并后，相关内容才进入主分支并形成新的版本。法院据此区分了个人分支与主分支的权利状态：尚未合并的贡献内容不影响主分支代码的权利主体；贡献内容进入主分支后，贡献者依GPLv3作出的许可，也使项目管理者能够继续管理和使用相关代码。结合贡献者数量众多、持续变化等事实，法院认可罗盒公司就主分支源代码独立主张权利，无须逐一取得全部贡献者的授权。

该案的意义并不在于赋予所有开源项目管理者当然的诉权。法院确认的是：在项目治理结构清晰、主分支由特定主体持续控制、贡献代码依既定规则合并的情况下，代码仓库中的形成与管理事实可以成为判断权利主体的重要依据。项目发起记录、Git提交与合并记录、版本标签、许可证文件及贡献者协议，共同构成了开源项目诉权证明的证据链。开源协作没有消解权利主体，只是使权利证明从单一登记材料延伸至代码形成和项目治理的全过程。

三违反许可条件后的责任：从授权终止到侵权认定

GPL许可为使用者复制、修改和传播代码提供授权，同时以相应条件限定授权范围。使用者对外传播受GPL约束的软件却未履行源代码提供等义务时，许可证能否继续为其行为提供合法基础，成为侵权判断的前置问题。

在前述VirtualApp案[3]中，被诉软件“点心桌面”使用了VirtualApp源代码，但未按照GPLv3向公众提供相应源代码。法院结合GPLv3第8条关于许可终止的约定，认定相关许可权利已经终止。与此同时，鉴定意见显示，被诉软件与VirtualApp在目录结构、代码文件和关键目录命名等方面存在大量相同或者高度近似内容，足以排除独立开发的可能。法院在确认许可基础已经丧失后，进一步依据软件代码比对结果认定著作权侵权成立。

这一裁判过程表明，违反GPL条件与著作权侵权之间存在衔接关系，却不能省略中间环节。法院仍需查明被诉软件是否实际使用权利代码、被诉行为是否属于需要著作权人许可的复制、修改或传播，以及违反的具体条款是否足以影响授权状态。GPLv3第8条同时规定了停止违规后的恢复机制，授权状态也会因整改、通知时间和首次违规等事实发生变化。案件办理中，许可版本、传播方式、源代码提供情况与整改记录都应进入证据审查。

此外，涉案代码在被诉软件中所占比例较小，并不会当然排除侵权。比例可以影响损害后果和赔偿范围，侵权定性仍取决于被复制部分是否具有独创性、是否属于受保护表达，以及其与被诉软件之间的实质关系。许可证条款解决授权边界，代码比对则回答受保护表达是否被实际使用，二者共同完成侵权判断。

四权利人未履行开源义务时的抗辩：权利基础与被告责任的分别审查

更具争议的情形是：权利软件自身使用了GPL代码，权利人却未按照GPL公开相应源代码；被告在被诉侵权后，据此主张权利人的软件不应受到保护。现有案件呈现出不同处理结果，但这些结果并非简单相互否定，其审查对象和裁判重心存在差异。

（一）南京案：从权利人自身的许可基础审查保护范围

在南京未某高新技术有限公司、江苏云某信息科技有限公司等侵害计算机软件著作权纠纷案[4]中，涉案软件由主程序和预览程序组成。法院认定主程序属于基于GPL代码形成的衍生作品，权利人未履行持续开源义务，其依据GPL取得的许可已经终止，因而未支持其针对主程序提出的著作权主张；对于不受GPL影响、能够独立区分的预览程序，法院仍给予著作权保护。

该案直接审查的是原告针对特定程序提出权利主张的基础。主程序与GPL代码之间的关系、权利人是否负有并违反开源义务、主程序与预览程序能否区分，共同决定了保护范围。由此产生的结论只能作用于与GPL许可状态相关的具体部分，不能被概括为权利人一旦存在开源违规，其全部软件权益当然失去保护。

（二）最高法案件：他人的开源违规不能当然转化为被告的许可

在浙江亿某通信科技公司等与网某科技（苏州）公司侵害计算机软件著作权纠纷案[5]中，被诉侵权人以权利人未遵守GPLv2为由提出不侵权抗辩。最高人民法院认为，软件开发者是否违反GPLv2，与其是否就独创性贡献享有著作权，属于需要分别评价的问题。权利人可能因违反开源协议向相关权利人承担责任，但被诉侵权人不能仅凭权利人的开源合规问题，当然取得复制、修改或者传播涉案软件的授权。

在《全国法院知识产权案件法律适用问题年度报告（2025）摘要》第25项所载的开源协议抗辩案[6]中，法院进一步指出，被诉侵权人仅以权利人未依照开源协议公开源代码为由主张不构成侵权的，人民法院一般不予支持；权利人未遵守开源协议的情形，可以作为确定赔偿数额的考量因素。

因此，被告提出GPL抗辩时，仅提交开源项目页面或证明权利软件包含开源代码，通常还不够。其至少需要说明适用的许可证版本、权利人承担的具体义务、该义务与原告主张保护部分之间的关系，以及相关违规对权利基础、责任承担或者赔偿数额产生何种影响。权利人的违规可能成为案件中的重要事实，却不会自动成为被告使用涉案软件的许可证。

五结语

开源软件的开放、许可与权利保护共同构成一套完整的法律结构。现有裁判已经分别从项目治理、许可履行和侵权抗辩三个方向展开判断：诉权认定回到代码的形成、合并与控制过程；许可审查回到具体版本、传播行为与履行状态；开源抗辩则需要区分权利人的许可瑕疵与被告自身是否获得授权。

对开源软件案件而言，“传染性”等概念只是分析的起点。最终进入裁判的，仍然是具体代码来自何处、如何进入主分支、以何种方式传播、相关主体履行了哪些许可条件，以及被诉软件实际复制了哪些受保护表达。将这些技术事实与许可证条款准确对应，才能在开放共享与著作权保护之间划定清晰的权利边界。

注释（上下滑动阅览）

【1】参见 GNU General Public License, Version 3, 29 June 2007, Preamble and Sections 2、4—6、8—10，https://www.gnu.org/licenses/gpl-3.0.en.html，访问日期：2026年7月15日。

【2】最高人民法院民事判决书，（2021）最高法知民终2063号。

【3】最高人民法院民事判决书，（2021）最高法知民终2063号。

【4】南京市中级人民法院民事判决书，（2021）苏01民初3229号。

【5】最高人民法院民事判决书，（2021）最高法知民终51号。

【6】江苏省高级人民法院民事判决书，（2024）苏民终581号；参见《全国法院知识产权案件法律适用问题年度报告（2025）摘要》第25项。

作者：朱玮洁

编辑：Sharon