（一）GPL协议的特殊性：开源协议中的互惠性典例
在开源协议的多元谱系中，GPL（GNU通用公共许可证）协议因其独特的“传染性”条款而成为互惠性协议的典型代表。与宽松型开源协议（如MIT、Apache）不同，GPL协议要求任何基于其开发的衍生作品也必须遵循GPL协议，确保源代码的持续开放。这一“传染性”要求既体现了开源社区“代码共享、协作创新”的核心理念，也为开发者设定了明确的权利和义务边界。
近期，深度求索（DeepSeek）公司在GitHub社区开源其核心代码的举动，引发了业界对开源协议法律效力的新一轮热议。尽管DeepSeek此次采用宽松许可证（代码库使用MIT许可证、模型采用OpenRAIL修改版）进行开源，但GPL协议在开源领域的广泛应用和重要性依然不可忽视。过往诸多项目借助GPL协议开源，在促进技术创新、推动行业发展方面成效显著，不过，也随之产生了一系列在司法实践中亟待解决的法律难题——例如，如何在著作权法框架下界定GPL协议的约束力，以及如何平衡开发者权益与开源义务。
（二）GPL协议合同效力的司法确认与违约衍生软件作品的权利基础争议
最高人民法院在“GPL3.0协议法律效力国内首案（（2021）最高法知民终2063号）”[1]中明确，GPL协议构成著作权许可合同，其发布与使用行为形成合同关系。然而，实践中部分企业违反GPL协议，将基于GPL协议开发的软件进行闭源处理（即违约衍生软件作品），由此引发被告以“开源抗辩”主张原告权利存在瑕疵，试图援引“不洁之手”（Unclean Hands）原则否定原告著作权的正当性。对此，最高院在“网经诉亿邦案（（2021）最高法知民终51号）”中厘清关键界限：开发者违反GPL协议的行为属于合同义务违反，但独创性作品的著作权仍受法律保护[2]。这一立场揭示了司法逻辑的核心——著作权的合法性根植于独创性表达，而非对开源协议的履约状态。
（三）GPL协议版本迭代与著作权纠纷的司法挑战
从GPLv2到GPLv3，GPL协议的演进始终围绕“互惠性”的强化与适用场景的扩展。例如，GPLv3新增对网络服务（如SaaS）在特定情况下的源代码公开要求[3]，进一步扩大了传染性范围。司法实践中，法院需直面三大核心争议：一是如何界定GPL协议传染性的边界（如聚合作品与衍生作品的区分）；二是如何认定开发者违反开源义务的行为性质（违约抑或侵权）；三是前述违约衍生软件作品自身著作权基础的正当性。当前判例虽已确立GPL协议的合同效力，但对上述问题的解释仍存在技术性与法律性的双重困境。
尽管DeepSeek项目采用的并非GPL协议，而是选择了如MIT等宽松型开源许可证来推动其核心代码的开源进程，但这并不妨碍我们以其开源实践为参照，来深入探讨GPL协议在实际应用中面临的问题。本文将结合典型案例与学理分析，旨在厘清GPL协议下著作权保护的司法逻辑，为开源生态的合规发展提供理论参鉴。
二、GPL协议软件的著作权权利基础确定
开源协议的自由共享属性使其可能涉及多个不同的贡献者，初始开源软件不断形成新的、存在多个贡献者的软件版本。此种情况下，则可能产生进一步确认GPL协议软件在著作权法意义上的作品性质需要。
（一）演绎作品著作权正当性剖析：一般作品与GPL协议软件的比较
1. 侵权演绎作品著作权的正当性解析
我国著作权法第十三条规定，“改编、翻译、注释、整理已有作品而产生的作品，其著作权由改编、翻译、注释、整理人享有，但行使著作权时不得侵犯原作品的著作权。”被许可人基于其演绎创作所享有的著作权，仅限于其演绎部分产生的作品，不因其演绎行为对原作品享有权利。
侵权演绎作品虽因侵犯原作品著作权存在权利瑕疵，但这并不当然否定演绎者在演绎过程中投入的独创性智力劳动成果。著作权法保护的核心是作品的独创性表达，侵权演绎作品中演绎者独立创作的部分，若满足独创性要求，理应受到法律的保护。这一原则在例如（2007）浦民三（知）初字第120号[4]、（2015）民申字第119号[5]、（2019）苏民终1792号[6]等多个司法判例中得到了充分体现。
2. GPL协议软件演绎作品的著作权基础
GPL协议软件作为计算机软件的一种，其作品认定与一般计算机软件遵循相同标准，核心在于是否具有独创性。具有传染性的GPL协议本身不影响软件作品的著作权的认定。该协议鼓励被许可人对开源软件进行使用、修改和发行，赋予被许可人二次开发的自由。在被许可人遵循GPL协议的前提下，其有权对衍生开发的独创性部分行使著作权。
但当被许可人违反GPL协议，如对GPL协议软件进行闭源处理时，其丧失了GPL协议赋予的原开源软件的许可，构成对原开源软件的侵权，但这并不意味着其对演绎开发的独创部分丧失著作权。仍以上述网经诉亿邦案为例，原告网经公司主张的权利软件涉及GPLv2协议且进行了闭源处理。最高院认为，即便假定网经公司因违反GPLv2协议导致涉案软件存在权利瑕疵，该假定瑕疵亦不影响网经公司在本案中针对被诉行为寻求侵权救济。[7]这清晰地表明，GPL协议软件演绎开发者对其演绎独创部分同样享有著作权。
（二）GPL协议软件合作作品的认定与影响
1. GPL协议软件合作作品的属性认定
开源软件在被项目管理者上传到开源社区后，经常出现不同贡献者共同参与开发初始开源软件，并在此基础上形成开源软件的不同版本。以GitHub为例，项目管理者发布开源软件后，其他用户可以将修改内容上传提交给项目管理者，并向其发出请求。若项目管理者接受修改内容，将形成原开源软件外的新分支版本，相应用户成为新分支版本的贡献者。反之，用户提交的修改内容保存在分支版本内，不影响原开源软件的内容。从前述创作人数、软件形成流程等来看，开源软件新版本的形成，形式上融合了多方参与者的合意和创作。
依据我国现行著作权法律体系及相关司法解释，合作作品是指两个或两个以上的主体，基于共同创作的合意，并在客观上实施了共同创作行为，且各自贡献了具有独创性的表达，从而形成的作品。虽然GPL协议软件开发模式独特，但其是否能够依据我国现行著作权法律体系及相关司法解释成为“合作作品”，仍需进行细致入微的分析：
1.从创作合意角度来看，虽然开源软件开发者基于共同促进软件优化与发展的目的参与开发，但这种宽泛的目标并不必然等同于法律意义上明确的共同创作合意。开发者提交修改可能只是基于自身对软件功能的改进需求，而非与项目管理者或其他开发者达成特定的创作共识；
2.在客观创作行为方面，贡献者提交代码的行为是否构成共同创作行为，需要深入考量其对软件整体创作的实质性贡献程度。仅仅提交少量代码或进行简单修改，可能难以被认定为对软件创作具有独创性贡献的行为。
回应于上述问题，“罗盒诉玩友案”[8]与“罗盒诉风灵创景案”[9]等典型案例为GPL协议软件合作作品属性认定提供了重要参考。在“罗盒诉玩友案”中，被告玩友公司虽主张涉案软件为合作作品，但因无法充分证明贡献者提交的代码具备独创性表达，法院最终未认可其合作作品的主张。而在“罗盒诉风灵创景案”里，最高人民法院进一步明确，认定开源软件贡献者与项目管理者的合作创作行为，需综合评估创作合意、共同创作行为、贡献者创作部分的独创性以及认定为合作作品在法律和经济效率上的合理性等多方面因素。该案中，项目管理者在软件源代码形成过程中起到了决定性作用，而贡献者提交内容的实质性影响尚不明确，因此难以认定贡献者为合作作者。
综上所述，GPL协议软件合作作品属性的认定较为复杂，需要在遵循现有法律框架的基础上进行要件分析。
2. GPL协议软件著作权维权中原告主体适格问题
当涉及GPL协议软件著作权维权时，由于存在上述合作作品的认定问题，故而原告主体适格问题是司法实践中的重要关注点。根据《计算机软件保护条例》第10条规定，合作开发软件的著作权归属有明确规则。若软件可分割使用，开发者对各自开发部分单独享有著作权；若不可分割使用，则由合作开发者共同享有，通过协商一致行使权利，在无法协商一致且无正当理由的情况下，任何一方不得阻止他方行使除转让权以外的其他权利，所得收益应合理分配。
在项目管理者与贡献者开发的开源代码融合的情况下，GPL协议软件则可能转变为不可分割的作品。就不可分割的开源软件，根据上述的法律规定，项目管理者与贡献者需要在协商一致的情形下行使权利。但若其未能协商一致的，又无正当理由，项目管理者与贡献者中的任何一方不得阻止其他开发者行使除转让权以外的其他权利。计算机软件保护条例禁止合作作品部分作者单独行使转让权。著作权法禁止合作作品部分作者单独转让、许可他人专有使用、出质合作作品，[10]但并未禁止合作作品中的部分权利人提起诉讼。
实践中，法院通常采取区分权利行使与利益分配的方式进行审查。例如，在“上海灿星诉嘎啦文化案”（福建省高级人民法院（2020）闽民终1277号）中，福建高院认为，在嘎啦公司没有提交相应证据证明共有著作权人有正当理由阻止灿星公司提起诉讼的情况下，灿星公司作为共有著作权人之一有权行使诉权；在“刘占锋诉武汉文得宝案”（河南省高级人民法院（2021）豫知民终245号）中，开封市中级人民法院判定刘占锋虽未提供其他编者授权诉讼证明或无著作权声明，但因其诉讼目的是保护涉案作品信息网络传播权，不涉及著作权转让，所以有权单独提起诉讼，二审维持该判决；在“上海灿星诉赤坎新星光盛会案”（广东省高级人民法院（2021）粤民终2138号）中，湛江市中级人民法院认定灿星公司有权单独行使权利，其与其他主体的利益分配不影响本案审理，二审维持原判。
这些案例表明，若涉及合作作品，部分作者单独提起诉讼进行维权时，被告通常需提供证据证明合作作品其他作者存在正当理由阻止起诉，否则难以以此抗辩原告不适格。特别是在无法联系合作作品作者的情况下，要求部分作者取得其他全部作者同意可能会放任侵权行为，损害合作作品作者的著作权。
针对开源软件管理项目，最高院在上述罗盒诉风灵创景案中，确认了开源软件项目管理者一般无需经过其他贡献者授权的观点，项目管理者可以单独起诉维权。开源软件的项目管理者对软件源代码的形成一般具有决定性作用。贡献者主动参与该开源项目应视为其默示同意项目管理者提起侵权之诉。
然而，我们依然注意到，由于GPL协议软件存在合作作品性质的天然属性，因此可能会影响到项目管理者单方转让软件行为的效力，例如在软件代码混合导致不可分割的情况下，合作作品的转让、许可需要满足相关法律规定，此时受让方作为原告主张权利的基础可能会受到质疑；亦或者随着贡献者对初始开源软件的修改及贡献不断加深，此时项目管理者最初贡献浓度下降致使不再具有对软件源代码形成的决定性作用，则又会使得主体适格问题的答案存在不确定性。
三、GPL协议软件传染性与开源抗辩的司法认定
GPL协议软件的传染性本质，是给GPL协议软件的在后开发者施加了一种传递性义务，需要向他人公开其受到GPL传染的代码，同时也就该部分代码许可他人在开源协议内使用、修改和发布。GPL协议传染程度的认定，影响在后开发者的公开和许可义务。同时，开源协议的许可传染性，使得司法实践中出现一种特别的抗辩手段——开源抗辩（Open Source Defense）。
（一）开源抗辩的法律内涵与适用边界
开源抗辩，指在GPL软件著作权侵权诉讼中，被告以原告未履行开源协议义务（如未公开源代码）为由，主张原告权利存在瑕疵或自身使用行为具有合法性的抗辩策略。其法律依据通常包括两方面：一是基于开源协议的合同授权抗辩（即被告主张已通过GPL协议获得使用授权）；二是基于权利瑕疵抗辩（即原告因违反GPL协议丧失著作权正当性）。
司法实践中，法院对开源抗辩的认定呈现以下特点：
1. 合同授权抗辩的优先性：若被告能证明自身使用行为符合GPL协议要求（如已公开源代码），则直接构成合法授权，无需进入侵权审查。例如，在“罗盒诉风灵创景案”（（2021）最高法知民终2063号）中，最高院明确指出：“被诉侵权软件本应遵循GPL3.0协议向用户开放源代码，其对于涉案权利软件源代码的使用因后续未开源而丧失正当的权利来源基础，因此两科技公司对涉案权利软件源代码的使用属于未经著作权人许可而使用其作品的行为。”
2. 权利瑕疵抗辩的严格限制及“不洁之手”原则的审慎适用：最高人民法院在“网经诉亿邦案（（2021）最高法知民终51号）”中明确，原告违反GPL协议的行为属于合同违约，不影响其著作权的合法性。著作权的保护基础在于作品的独创性，而非权利人对协议的履约状态。因此，虽有被告援引“不洁之手”原则主张原告无权维权，但法院多数观点认为，著作权侵权责任与合同违约责任分属不同法律关系，原告的违约行为不构成对侵权主张的绝对排除。
（二）传染性认定的技术视角与法律审查冲突
GPL协议的“传染性”需进行技术与法律的双重验证。
GPLv3协议第5条规定了传播修改后的源代码的条件，强调了基于该程序的作品或为从该程序制作出此作品而做出的修改（“衍生性使用”），需整体遵循GPLv3协议进行传播，即被诉软件与GPL代码形成“紧密的、功能性的结合”；同时，GPL协议对“衍生性使用”所负担的开源义务的边界进行了限制，例如，GPLv2.0：第2条第4款规定，若独立作品与GPL程序仅以“聚合”（aggregation）形式存在于同一存储或分发媒介中，则独立作品不受GPL协议约束。但并未明确“聚合”的界定标准，导致传染性边界模糊。而GPLv3.0第5条第2款在此基础上进一步细化了“聚合”要件，要求聚合作品需满足：（1）独立性：作品本质上是分开的，且合并目的非为形成更大的程序；（2）无权利限制：聚合行为不得限制用户对各作品原有权利的行使。
从前述GPL协议的规定来看，聚合的认定可以用于排除GPL的传染性。但GPL协议并没有给出一个技术上可操作的方案。GNU官方网站在常见问题的解释中提到，两个独立程序与一个包含两部分的程序之间的界限，是一个由法官决定的法律问题，合理的标准既依赖于通信的机制，也依赖于通信的语义。
由于在技术上没有针对“聚合”进行规范，GNU将这一审查标准交由各国司法实践进行厘清，由此产生了针对“传染性”边界在技术视角与法律审查方面的冲突。在我国的司法实践中，法院通过以下标准界定传染范围：
（三）探讨：一种特殊的开源抗辩——在后使用者的开源抗辩主张
GPL协议的传染性特征，使得受到GPL协议传染的衍生软件开发者也受到协议约束。他人在GPL协议范围内使用前述衍生软件的，因已基于GPL协议获得授权，不会侵犯衍生软件发行者的权利。此类开源抗辩主张基于GPL协议的许可，在各方遵循GPL协议的情况下，存在的争议不大。最高院在罗盒与风灵创景案也明确，“被诉侵权软件本应遵循GPL3.0协议向用户开放源代码，其对于涉案权利软件源代码的使用因后续未开源而丧失正当的权利来源基础，因此两科技公司对涉案权利软件源代码的使用属于未经著作权人许可而使用其作品的行为。”
但是，被控侵权人是否有权要求基于开源软件的在后开发者发布的软件因受到GPL协议传染而对涉诉软件进行开源，并籍此主张不侵权抗辩呢？笔者暂未检索到直接案例，但是下表中的两个案例间接回应了这个问题。
上述未来诉云蜻蜓案中被告主张的开源抗辩，实际上是“不洁之手”原则的运用，借由权利人未按照开源要求进行开源进而否定原告行使权利的正当性。必须指出，此种情况得到法院支持的案例较为少见。与之相反，在网经诉亿邦案中，最高院所澄清的是，侵犯他人在先作品的计算机软件作品，也可以得到著作权法保护。正如最高院所论述，“在侵害计算机软件著作权案件中，涉案软件开发者是否未尽开源义务和是否基于其独创性贡献享有涉案软件著作权并不必然相关。被诉侵权人仅以涉案软件开发者并未依据开源协议开源为由，抗辩其不侵害涉案软件著作权的，人民法院一般不予支持。”通过这两个案例可以看出，被告作为在后使用者，要求权利软件应当开源从而进行不侵权抗辩，被法院支持的难度较高。
四、GPL协议软件使用的合规建议
虽然最高院在网经诉亿邦案中认定，“软件开发者自身是否违反GPLv2协议和是否享有软件著作权，是相对独立的两个法律问题。”软件开发者违反GPL协议开发的软件，在具有独创性的情况下，也可以受到法律保护，但这并不能排除软件开发者对开源软件权利人可能需承担的法律责任。正如最高院所指出，“本案最终认定被诉行为构成侵权并支持网某科技（苏州）公司部分诉请，并不表明网某科技（苏州）公司将来在潜在的违约和/或侵权之诉中可免予承担其依法应当承担的违约和/或侵权责任。”因此，软件开发商在使用GPL协议软件时，仍应注意合规使用GPL协议软件。
（一）建立开源软件使用审核流程
GPL协议软件为企业的软件开发带来便利的同时，也存在导致企业承担删除或更换核心代码的潜藏风险。为减少使用GPL协议软件所带来的商业风险，软件开发企业可以逐步建立开源软件使用审核流程，包括识别开源软件的许可证信息，遵循不同类型许可协议的相应义务。对于GPL此类互惠性许可证，软件开发商作为被许可方的履行义务较强。GPLv3.0第5条规定，将基于该程序的作品或修改过的作品（用于从该程序生成的修改）以源代码形式传达的，还必须显著标明已对其进行了修改，并给出相关的日期。尤其是，GPL协议的传染性可能导致企业开发的衍生软件代码必须开源，产生传染性风险。
除公司层面的开源软件审核流程外，企业应当建立常态化员工培训机制，增强员工对于开源软件使用的合规意识，通过员工自查和企业内部审核等多种方式，减少开源风险。
（二）搭建开源软件合规使用机制
实践中，GPL协议软件的合规使用方式是多元的。除履行许可证义务外，软件开发企业也可以尝试从开源软件项目管理者处获取商业使用许可，或者采取技术隔离措施，增加企业开发代码的独立性，降低GPL协议软件的传染性。我们认为，合规使用GPL协议软件的方法至少包括：（1）代码隔离设计：通过模块化开发、接口封装等技术手段，避免与GPL代码形成衍生性结合；（2）许可证兼容审查：在混合使用多协议代码时，确保GPL与其他协议（如MIT、Apache）的兼容性；（3）开源义务履行留痕：保留代码修改记录、开源声明文件及分发记录，以应对潜在诉讼风险。
此外，企业也可以选择宽松型、弱互惠型等较为宽松的许可协议，以避免企业自有代码与开源代码因关联性过高产生的开源义务。开源软件采用的许可协议也经常产生变化。通过搭建开源软件合规使用机制，增强对于已使用和拟使用开源软件的监控和管理。特别是对于变更采用为更宽松协议的开源软件，企业可以及时替换所使用的软件版本，降低侵权或违约风险。
五、小结
综上所述，GPL等开源协议在贯彻开放、共享、协同理念推动开源社区繁荣的同时，也要求软件开发企业更加注重开源协议的合规使用。软件开发企业在遵循许可证使用开源代码的同时，应合理控制GPL协议的传染范围，从而降低企业发展中的经营风险，保护企业自主开发的创新产品。
【1】（2021）最高法知民终2063号民事判决书。
【2】（2021）最高法知民终51号民事判决书。
【3】GPLv3中与SaaS场景下源代码公开要求相关的内容，主要集中在GNU AGPLv3第13条 “Remote Network Interaction; Use with the GNU Affero General Public License”（远程网络交互；与GNU Affero通用公共许可证的配合使用）。
【4】在该案中，法院认为，即使原告歌词与《死了都要爱》歌词之间存在侵权嫌疑，也是原告与《死了都要爱》歌词作者之间的关系，且这只可能影响到原告利用作品，但并不影响原告在自己作品被侵权时向他人主张权利。
【5】在该案中，法院认为，三民书局是否在《新译史记一一八》中使用中华书局享有著作权的点校本《史记》，以及是否构成权利瑕疵的问题，系另外的法律关系，与本案无关，法院对此不予评述。
【6】在该案中，法院认为，对于著作权领域具有独创性的智力成果应当给予相应必要的保护，而对于改编作品的保护应当同时兼顾在先原作品创作主体的权利保护和改编作品创作主体即改编行为人的权利保护，设易公司作为涉案3D作品的改编人，应当有权禁止望拓公司不经许可即复制、发行其制作的3D模型文件。因此，虽然设易公司未经许可的改编行为构成对原著作权人的侵权，但这并不妨碍其禁止其他主体未经许可复制、发行其改编后的作品。
【7】（2021）最高法知民终51号民事判决书。
【8】（2019）粤73知民初207号，法院认为，判断是否为合作作品应考虑以下因素：作者为两个或两个以上、主观上有共同进行作品创作的合意、客观上有共同创作作品的行为、合作作者贡献了独创性的表达···双方存在共同创作的合意···但是，玩友公司并未举证证明贡献者提交的代码是否属于有独创性表达的创作，仅根据贡献者提交的代码行数无法判断其是否有独创性。因此，就在案证据无法认定涉案软件属合作作品。
【9】（2021）最高法知民终2063号，入库案例，法院认为，这部分贡献者的行为是否可以认定成为与项目管理者的合作创作行为，需从以下几个角度分析：第一，项目管理者是否与贡献者存在创作的合意；第二，项目管理者与贡献者是否存在共同创作的行为：第三，贡献者对软件作品本身起的作用是否具有实质性，换言之，贡献者的创作部分是否具有独创性；第四，将软件认定为合作作品是否具有法律和经济效率上的合理性。
【10】《著作权法》第十四条：“两人以上合作创作的作品，著作权由合作作者共同享有。没有参加创作的人，不能成为合作作者。合作作品的著作权由合作作者通过协商一致行使；不能协商一致，又无正当理由的，任何一方不得阻止他方行使除转让、许可他人专有使用、出质以外的其他权利，但是所得收益应当合理分配给所有合作作者。”