回顾：

上篇系统梳理了开源许可的制度基础与AI 时代的变局，从自由软件运动到商业开源的历史演进，解析了开源协议的法律性质、版权与专利边界，并探讨了大模型时代权重､ 数据与输出的法律属性差异，以及各类主流AI 模型许可的实践差异｡

第三部分：许可证谱系——从组件引入到产品发布，风险如何被触发

企业真正困惑的，往往不是某个许可证名称，而是同一产品链条中的具体行为：复制还是调用，修改还是原样使用，分发软件副本还是仅提供云服务，组件之间是独立组合还是形成紧密整体。GPL、AGPL、LGPL、MIT、Apache 2.0、SSPL和Elastic License，正是在这些不同触发点上给出不同答案。

GPL：什么时候会从使用组件走向开放衍生作品

点击可查看大图

先设定一个贯穿本部分的共同场景：一家企业正在开发商业产品或SaaS服务，前端使用 MIT/BSD库，后端调用LGPL库，核心模块可能嵌入GPL框架，数据库或搜索组件可能采用 SSPL/Elastic License，AI功能又依赖开放权重模型。企业真正困惑的往往不是某个许可证名称，而是同一条技术链上的哪些行为会触发义务：只是下载和内部测试，还是复制、修改、打包分发；只是远程API调用，还是把组件嵌入核心功能；只是组合多个独立程序，还是形成一个衍生作品或紧密整体。

在这个场景中，GPL是最适合作为起点的许可证。它的核心机制是Copyleft机制：如果使用者基于GPL程序形成衍生作品并进行分发，通常需要按GPL发布整个衍生作品，并提供对应源代码。

企业真正需要理解的是，GPL的Copyleft效力不是道德标签，而是法律和技术判断。关键问题包括：是否复制了GPL代码、是否修改了GPL程序、是否形成衍生作品、是否进行了分发、是否仅为内部使用、是否构成聚合体、是否通过独立进程或网络服务交互、是否存在静态链接或动态链接，以及许可证版本是否兼容。

中国法院已经在几类不同事实中触及这些问题。为避免把案例结论抽象成一句“GPL Copyleft效力是否会扩张”，可以先把案件本身说清楚，再看其对应的裁判重心。

“数字天堂诉柚子案”，即数字天堂（北京）网络技术有限公司诉柚子（北京）科技有限公司、柚子（北京）移动技术有限公司计算机软件著作权侵权案。该案中，被告以GPL提出抗辩，主张涉案HBuilder软件或相关部分应受GPL约束。法院更多从涉案插件的文件夹位置、许可文本位置和插件独立性判断其是否受GPL约束，认为涉案三个插件并不当然因其他目录中存在GPL文本而被纳入GPL范围。该案的意义在于确认GPL抗辩可以进入司法审查，但其对Copyleft效力边界的分析较偏形式化，不能被扩大理解为所有项目结构问题都只看文件夹。

“不乱买案”，即北京闪亮时尚信息技术有限公司诉不乱买电子商务（北京）有限公司侵害计算机软件著作权纠纷案，案号为（2019）最高法知民终663号。该案更重视软件结构本身。最高人民法院认为，涉案网站前端代码与后端代码在展示方式、所用技术、功能分工等方面明显不同，属于相互独立又相互联合的独立程序；即便前端代码使用GPL协议项下开源代码，后端代码也不因前端代码而当然受GPL约束。该案说明，GPL边界需要结合程序之间的技术关系判断，而不是只要发生交互就推定整体开源。

“罗盒诉玩友案”，即广州知识产权法院审理的罗盒公司诉玩友公司等VirtualApp/GPLv3案，案号为（2019）粤73知民初207号。该案显示的是另一种场景：如果商业软件在核心功能或基础框架上实质依赖GPL程序，并与GPL框架形成紧密整体，就可能被要求履行GPL义务。法院对VirtualApp框架与被诉软件之间的技术关系作了较深入分析，认为被告未按GPLv3提供源代码，可能导致授权终止和侵权责任。该案不能简单概括为“所有商业使用GPL都侵权”，但提示企业不能把GPL框架嵌入核心功能后，仅以产品另有其他功能为由排除GPL义务。

因此，GPL风险不能被夸大为“用了就全开源”，也不能被低估为“只要包装成模块就没事”。企业应结合技术架构和法域规则做具体分析。

AGPL与LGPL：网络服务和库调用为什么会改变义务

共同场景向前推进，就会出现两个经常被混在一起的问题：一是企业不分发软件副本，只把修改后的程序部署成在线服务；二是商业主程序只是调用一个开源库，而不是把库本身改造成产品核心。AGPL和LGPL分别回应这两个问题。

GNU Affero通用公共许可证（GNU Affero General Public License，简称“AGPL”）是GPL在网络服务场景下的延伸。传统GPL义务主要在分发软件副本时触发。软件即服务（Software as a Service，简称“SaaS”）模式下，用户通过浏览器或API使用服务，通常并不取得软件副本，因此可能不触发GPL的分发义务。AGPL第13条则要求，如果修改后的程序通过网络与用户交互，应向用户提供对应源代码访问方式。

这就是AGPL对SaaS企业敏感的原因。若服务端程序包含AGPL组件并与用户交互，企业可能需要向用户提供相关源代码。很多企业因此在开源合规制度中将AGPL列为高风险许可证，要求特别审批或采用服务隔离。

GNU宽通用公共许可证（GNU Lesser General Public License，简称“LGPL”）则采用弱Copyleft 机制，主要面向库文件。其基本思想是：对LGPL库本身的修改需要开放，但调用该库的主程序可以采用其他许可证，包括专有许可证。它在开源库与商业软件之间提供折中路径。

然而LGPL的边界也并非完全清楚。静态链接是否要求提供可重新链接机制、动态链接是否一定安全、头文件中包含大量实现代码时如何判断、库与主程序之间是否形成衍生作品，这些问题仍需结合许可证版本和具体架构判断。

MIT、BSD与Apache 2.0：低摩擦许可仍有合规底线

如果共同场景中的组件只是通用工具库、前端框架、示例代码或基础设施模块，企业通常希望降低集成成本、减少向下游传递复杂义务。MIT、BSD和Apache 2.0正是在这个意义上被称为“宽松许可证”。但“宽松”只意味着义务较少，并不意味着没有版权声明、专利和文件传递等合规要求。

MIT许可证极为简洁，允许使用、复制、修改、合并、发布、分发、再许可和销售软件副本，主要义务是保留版权声明和许可证声明。它非常适合工具库、前端框架、示例代码、原型项目和希望最大化采用范围的基础组件。

BSD许可证与MIT类似，BSD-3-Clause增加了非背书条款，要求未经许可不得使用原作者名称推广衍生产品。其法律风险与MIT接近，但在学术和系统软件社区中更常见。

Apache 2.0则在宽松授权基础上增加了更完整的专利授权、专利反诉终止和NOTICE文件要求。它通常更适合企业级基础设施、标准化平台、AI框架和存在专利风险的项目。Apache 2.0与GPLv3单向兼容，即Apache 2.0代码可被纳入GPLv3项目并整体按GPLv3发布，但GPLv3代码不能反向纳入Apache 2.0项目并保持Apache 2.0发布。

宽松许可证的优点是低摩擦，缺点是回流机制弱。下游可以将MIT或BSD代码纳入闭源产品，未必向社区贡献修改。企业如果追求生态扩张和商业采用，通常会选择宽松许可证；如果追求衍生作品持续开放，则可能选择GPL或AGPL。

SSPL与Elastic License：云服务商业模式下的再控制

当共同场景从“企业自己集成组件”进一步变成“云厂商把开源数据库、搜索引擎或中间件包装成托管服务”，问题又会发生变化：软件副本未必被分发给终端用户，但开源项目的商业价值却可能被服务化地捕获。MongoDB、Elastic等厂商对传统开源许可证的反思，正是在这一背景下发生的。

MongoDB推出服务器端公共许可证（Server Side Public License，简称“SSPL”），其核心是如果将软件功能作为服务提供给第三方，就需要开放服务源代码。问题在于，“服务源代码”定义非常宽泛，可能包括管理界面、监控工具、备份系统、存储系统等整个服务运行所需组件。这使云服务商几乎无法接受。OSI未批准SSPL，认为其与不得歧视使用领域、不得限制其他软件等开源定义存在冲突。

Elastic则将Elasticsearch和Kibana从Apache 2.0转向SSPL/Elastic License双许可，直接限制第三方提供与Elastic商业产品竞争的托管服务。Amazon Web Services（简称“AWS”）随即分叉OpenSearch，社区产生分裂。

这些事件说明，一些厂商会试图用许可证同时实现两个目标：保持源代码可见和社区参与，同时限制第三方将项目直接包装成竞争性托管服务。这样的安排可能有商业上的合理性，但代价也很明显：它可能偏离传统开源定义，损害社区信任，引发项目分叉，并使“开源”标签本身受到质疑。

AI 模型许可也在重复这一过程。开放权重但限制商业规模、限制用途或限制竞争模型训练，可能有商业合理性，但未必符合传统开源定义。企业在宣传中应避免把“可下载”“开放权重”“源代码可见”简单等同于“开源”。

兼容性与链接方式：架构决定义务边界

回到共同场景，许可证文本只有落到具体架构中才会变成实际风险。企业可能同时使用宽松组件、GPL组件、LGPL 、AGPL服务端程序和自定义许可证项目。问题不只是“每个组件能不能用”，还包括这些组件放在同一个产品、同一个仓库、同一个可执行文件或同一个云服务中以后，义务是否会彼此冲突。

开源合规中，许可证兼容性因此成为高频风险。不同许可证的义务可能冲突。例如，一个项目如果同时包含GPL代码和专有代码，并形成一个整体，整体可能需要按GPL发布；如果企业无法接受这一点，就可能发生许可证冲突。

宽松许可证通常具有较强兼容性。MIT、BSD、Apache 2.0代码可以被纳入GPL项目，但纳入后整体需遵守GPL。采用强Copyleft机制的代码，则通常不能被简单纳入专有软件或宽松许可证项目。

链接方式常被用于判断风险。静态链接将库代码编入可执行文件，更容易被认为形成一个整体；动态链接在运行时加载库，物理分离更强，但并非绝对安全；进程隔离、容器隔离、API调用和网络协议交互通常更有利于证明组件独立性，但也要看功能依赖和数据交互强度。

企业应将技术架构视为合规证据。架构图、接口文档、模块边界、代码仓库分离、构建脚本、依赖清单、运行日志、服务调用方式，都可能在未来争议中影响法院或审查方对“衍生作品”“聚合体”“独立程序”的判断。

回到同一产品链条：许可证比较不能只看“宽松”或“严格”

把上述讨论放回同一个产品链条中，可以看到许可证比较并不是给许可证贴上“能用”或“不能用”的标签。企业真正需要做的，是把每一个组件放到具体使用方式中判断：它是否进入核心模块、是否被修改、是否随产品分发、是否只在云端提供服务、是否与其他许可证发生冲突，以及是否涉及专利授权、NOTICE文件、SaaS义务或模型用途限制。只有完成这一层映射，所谓“宽松”或“严格”才有实务意义。

因此，真正有意义的比较至少应包括授权范围、义务内容、专利安排、兼容性、商业友好度、对SaaS的影响、对衍生作品的控制力及跨境使用时的可解释性。

MIT的优势是简单、清楚、低成本。只要保留版权声明和许可证文本，使用者通常可以自由复制、修改、分发、再许可和商业化。对创业公司、工具库、前端组件、示例代码来说，MIT的交易成本极低。但它的短板也清楚：没有明确专利授权，没有NOTICE机制，对下游闭源吸收几乎没有约束。如果项目涉及关键专利或希望控制衍生作品，MIT可能过于宽松。

BSD与MIT非常接近。BSD-2-Clause和BSD-3-Clause在合规义务上都较轻，BSD-3-Clause的非背书条款可以避免下游未经授权使用原作者名称推广产品。BSD常见于学术、系统软件和基础设施项目。对企业来说，BSD的主要合规动作仍是保留声明和避免不当背书。

Apache 2.0是企业友好型宽松许可证。它不仅允许商业使用、修改和分发，还通过第3条提供贡献者专利授权，并设置专利反诉终止机制。同时，它还要求保留NOTICE文件中的归属声明。对企业级开源项目、AI框架、云原生基础设施和存在专利风险的技术，Apache 2.0通常比MIT/BSD更稳健。其代价是合规文件管理略复杂，尤其在多组件分发场景中要确保NOTICE信息完整传递。

GPLv2和GPLv3的核心是强Copyleft机制。企业真正需要关注的是“分发”和“衍生作品”。如果仅在内部使用GPL软件，通常不会触发向外部公开源代码的义务；如果对外分发包含GPL代码的衍生作品，则需要提供对应源代码并按GPL传递许可。GPLv3相比GPLv2增加了更完整的专利、反规避和反Tivo化安排，适应了硬件锁定和专利诉讼等新问题。但GPLv3与某些旧许可证并不兼容，企业需要特别关注版本条款。

LGPL是弱Copyleft许可证，适合库文件。企业可以在专有程序中调用LGPL库，但对库本身的修改要开放，并且在特定条件下需要允许用户替换或重新链接库。它的合规重点不只是“动态链接还是静态链接”，还包括是否修改了库、是否提供足够信息让用户行使权利、头文件是否包含大量实现代码等。

AGPL面向网络服务。它回应的是SaaS模式下的“应用服务提供商漏洞”（ASP loophole）：如果服务提供者修改GPL程序但不分发软件副本，只通过网络提供服务，传统GPL义务可能不触发。AGPL要求通过网络与修改版程序交互的用户也能获得源代码。因此，对云服务、在线平台、API服务和内部平台外部化的企业来说，AGPL是高敏感许可证。

Mozilla公共许可证（Mozilla Public License，简称“MPL”）处于宽松许可证与Copyleft许可证之间。它通常要求对MPL覆盖文件本身的修改继续开放，但允许与专有文件组合。其边界以文件为单位，比GPL的整体Copyleft效力更温和。对于希望保护核心文件开放、同时允许商业集成的项目，MPL是可考虑选项。

SSPL、Elastic License、Business Source License 等则需要单独分类。它们可能开放源代码，但加入托管服务限制、商业用途限制或时间转换机制，未必符合OSI开源定义。企业若使用这类许可证下的软件，不能套用传统开源合规流程，而应按商业合同或自定义许可逐条审查。

AI模型许可证还要再增加一层维度：权重是否开放、训练数据是否开放、输出是否受限制、是否允许蒸馏、是否允许用于训练竞争模型、是否限制高风险用途、是否要求模型命名或标识、是否设置规模门槛。传统开源许可证矩阵不足以覆盖这些问题。

第四部分：以案例视角，理解开源边界

许可证文本本身不能回答所有问题。先看美国案例，可以看到软件接口和AI训练如何把版权边界推到前台；再回到中国案例，则能看到法院如何判断GPL效力、模块独立性、权利主体和二次开发权利基础。

美国科技巨头API版权纠纷案美国科技巨头API版权纠纷案是软件版权领域绕不开的案件。G公司在开发Android时没有复制Java SE API中承担具体任务的实现代码，而是复制了37个API包中约11,500行声明代码及相应组织结构，使Java程序员可以在Android平台上使用熟悉的调用方式。原告起诉Google，主张版权和专利侵权。

案件历经多年，在地区法院、联邦巡回上诉法院、陪审团和最高法院之间多次往返。2021年，美国最高法院最终认定，在假定Java API声明代码可受版权保护的前提下，G公司的使用构成合理使用。法院强调，G公司自行编写了Android的任务实现代码，复制的声明代码主要用于让开发者在新的移动平台上调用其已经熟悉的任务；结合使用目的的转换性、声明代码的功能性、复制范围与目的之间的关系及市场影响，G公司不承担版权侵权责任。

该案对开源文章的意义在于，它展现了软件版权保护边界。接口、声明代码、结构、顺序和组织等元素既可能包含表达，也具有强功能性。版权法在保护表达时，需要避免过度封锁技术互操作。对于开源项目而言，这意味着许可证和版权并不能垄断所有技术接口；对于商业企业而言，也不意味着接口复用永远安全，仍需结合具体复制内容和法域规则分析。

美国AI代码诉讼

美国AI代码诉讼是AI训练代码版权争议的代表。原告匿名开发者主张，其公开在代码平台上的代码被用于训练Codex和Copilot，而模型输出没有保留版权管理信息和开源许可证要求，涉嫌违反DMCA第1202条、开源许可证合同义务和其他法律规则。

该案的重要性不在于它已经给出最终答案，而在于它揭示了AI时代开源维权的证据难题。传统软件侵权案件中，权利人可以通过代码比对证明被告复制了源代码。AI训练案件中，模型可能接触过海量代码，但输出并不必然逐字复制。若原告不能证明具体输出与其代码之间存在足够相似性或直接联系，主张就会面临困难。

法院在不同阶段驳回了原告若干请求，同时对DMCA第1202条关于“相同或近似输出是否必要”的问题进行处理。该案仍体现一个趋势：AI训练数据争议可能不会以抽象原则一刀切解决，而会逐步落到训练数据获取方式、许可证条款、输出重复率、相似性证据、版权管理信息删除意图和市场影响等具体事实。

对企业来说，使用AI代码生成工具不能完全忽视开源风险。尤其在生成结果较长、与公开代码高度相似、缺少许可证提示或用于核心商业产品时，应当建立输出检测和人工审查机制。

数字天堂诉柚子案

数字天堂诉柚子案通常被称为中国早期GPL典型案件。数字天堂公司开发HBuilder软件，包含代码输入法、真机运行、边改边看等插件。柚子公司开发APICloud软件，被指复制相关插件源代码。柚子公司抗辩称，HBuilder使用GPL代码，相关插件也应受GPL约束，因此其使用不构成侵权。

法院没有采纳该抗辩。公开报道显示，法院认为涉案三个插件属于相对独立的软件作品，其所在文件夹及软件根目录未见GPL许可证文本，尽管其他文件夹中存在GPL协议文件，但该协议对涉案插件不当然具有拘束力。柚子公司复制、修改相关插件源代码，构成侵害复制权、改编权和信息网络传播权。

该案的价值在于确认GPL在中国司法语境中的可执行性，也提示企业不能简单以“对方软件中某些部分使用GPL”为由否定其全部著作权。但该案的局限也明显：其对GPL Copyleft效力边界的判断较多依赖文件夹和许可证文本位置，未充分展开技术依赖关系。后续不乱买案和罗盒案对GPL边界的分析更为细化。

不乱买案

不乱买案处理的是网站前后端分离场景。涉案网站前端代码使用GPL代码，后端代码由不乱买公司自主开发。被告主张前后端存在交互，GPL Copyleft效力应扩张至整体，后端代码不应再由原告专有主张。

最高人民法院认为，前端代码与后端代码在展示方式、所用技术、功能分工等方面存在明显不同，属于既相互独立又互相联合的独立程序。即使前端代码使用GPL协议项下开源代码，后端代码也不当然受GPL约束。未经许可复制后端代码，仍构成侵害软件著作权。

该案的重要意义在于引入更实质的独立性判断。它并不是说前后端分离永远不会触发GPL风险，而是强调GPL的Copyleft效力要看具体软件之间的关系。若前后端在技术、功能、表达和运行上具有足够独立性，可以构成GPL语境中的聚合体或独立程序。

对企业来说，该案提供了架构设计启示：对高风险开源组件，应尽量通过独立服务、清晰接口、分层架构和仓库隔离降低混同风险。但技术隔离不能只是形式，必须反映真实的功能独立性。

罗盒系列案件

罗盒系列案件围绕VirtualApp插件化框架展开。罗盒公司开发VirtualApp框架，并曾以 LGPLv3、GPLv3等方式开源。被告在商业APP中使用相关框架，却未按GPLv3提供源代码。

广州知识产权法院在罗盒诉玩友案中较系统地分析了GPLv3的法律性质和Copyleft效力边界。法院认为GPLv3协议具有合同性质，是授权方和用户订立的格式化著作权协议。使用者可以在GPLv3条件下自由使用、复制、修改、分发，但必须履行相应义务。若违反协议条件，授权可能终止，后续使用行为可能构成侵权。

该案中，法院特别关注被诉软件与VirtualApp框架之间的技术关系。若商业APP的沙盒分身等功能依赖VirtualApp框架，且框架作为被诉软件的重要组成部分存在，则不能仅以商业APP另有视频美颜等功能为由排除GPL约束。功能主次并非唯一标准，技术依赖和作品整体关系更为关键。

最高人民法院在（2021）最高法知民终2063号案中则围绕罗盒公司是否为开源软件著作权人、是否需要全部代码贡献者授权、诉讼是否符合GPL争议解决安排等问题作了进一步说明。该案使开源软件权利人维权的主体资格问题更加清晰。

罗盒系列案件的警示在于：企业不能只把GPL误解为“不能商用”的许可协议。GPL并不禁止商用或收费，但要求在满足触发条件时保持相同开放义务。真正的风险不是收费本身，而是使用GPL程序后不履行源代码提供和许可传递义务。

最高法51号案

最高人民法院（2021）最高法知民终51号案处理了一个很现实的问题：如果原告的软件基于GPLv2开源项目OpenWRT二次开发，但原告没有按照GPLv2开源，是否因此不能对第三方复制行为主张侵权？

这类抗辩需要先分清三方关系。第一层关系，是OpenWRT等上游开源项目权利人与二次开发者之间的关系：如果二次开发者使用GPLv2项目后未履行源代码提供、许可传递等义务，上游权利人可以主张其违反GPLv2条件。第二层关系，是二次开发者与后手复制者之间的关系：如果二次开发者在原有开源项目基础上形成了具有独创性的新增代码、结构或表达，后手复制者未经许可复制这些新增部分，仍可能构成对二次开发者软件著作权的侵害。

被告的抗辩逻辑，实质上是试图把第一层关系中的GPL合规瑕疵，直接转化为第二层关系中的不侵权抗辩：既然原告可能违反GPLv2，就应当公开源代码，被告复制其软件也不应承担责任。问题在于，GPLv2即使要求二次开发者向下游提供源代码，也不意味着任何第三方都可以无条件复制二次开发者的新增独创表达，更不当然免除后手复制者的侵权责任。

因此，如果这一抗辩被完全采纳，后果会相当严重：大量基于开源项目进行二次开发的企业，只要自身GPL合规存在争议，就可能无法阻止他人抄袭其新增代码，也难以请求停止侵权、赔偿损失、删除侵权复制件等救济。这里所谓“救济能力”，指的是二次开发者作为新增代码权利人，对后手复制者未经许可复制其独创性贡献所能主张的著作权救济，而不是其对上游开源项目权利人的责任。

最高人民法院没有采纳该抗辩。法院认为，在软件尚未被开源、软件著作权人认为其软件不受GPLv2协议约束、被诉侵权人依据GPLv2提出不侵权抗辩的场景中，软件开发者自身是否违反GPLv2协议，与其是否享有软件著作权，是相对独立的两个法律问题。即使原告可能因违反GPLv2导致权利存在瑕疵，也不当然影响其针对被诉复制行为寻求侵权救济。

该案不是给违反GPL的二次开发者“免责”。其真正逻辑是：前手开源权利人与二次开发者之间的GPL违约或侵权问题，应由前手权利人主张；后手复制者不能仅因二次开发者可能未履行GPL，即自由复制其独创性贡献。否则会形成“一个不当行为人以他人不当行为为由否定自身责任”的不合理结果。

这个裁判思路对企业有双重影响。一方面，即使自身开源合规存在瑕疵，仍有权对第三方抄袭其独创代码主张权利；另一方面，前手开源权利人的维权门槛也相应降低，企业仍可能因未履行GPL义务被上游追责。换言之，51 号案并不削弱开源合规必要性，而是把不同法律关系分开处理。

对中国开源许可证典型判例的理解

综合上述中国案例可以看出，不能把相关裁判简单压缩成某一项单一规则。更准确的理解是，中国司法实践正在形成一组相互补充的规则。

第一组规则是“开源协议可执行”。数字天堂诉柚子案和罗盒诉玩友案都说明，GPL等开源协议不是单纯的项目协作规则或技术声明。法院可以将其作为著作权许可协议或合同安排来解释。使用者以开源方式取得权利，也应遵守相应条件。

第二组规则是“Copyleft效力有边界”。不乱买案说明，GPL Copyleft效力并不是简单的“同一项目中出现GPL代码即全部GPL”。法院会关注前端与后端、模块与模块之间的展示方式、技术实现、功能分工和独立性。若不同程序只是相互联合而非形成衍生作品，GPL不必然扩张到全部代码。

第三组规则是“技术依赖可能触发义务”。罗盒案说明，企业不能把GPL组件嵌入商业软件的基础框架后，再以商业软件另有其他功能为由规避GPL。若GPL框架对被诉软件具有实质性支撑，且形成紧密整体，法院可能要求履行GPL义务。

第四组规则是“权利基础与开源违约相对独立”。最高法51号案说明，二次开发者是否违反 GPL，与其是否对新增独创性部分享有著作权，不能直接画等号。后手侵权人不能仅以原告可能未履行开源义务为由，自由复制原告的独创性代码。

第五组规则是“上游仍可追责”。51号案并不意味着二次开发者可以无视GPL。相反，如果其确实基于GPL软件开发并分发却不履行义务，上游权利人仍可能另行主张权利。该案只是拒绝让后手复制者借上游开源义务瑕疵逃避自身侵权责任。

第六组规则是“主体资格不能机械判断”。开源项目常有多名贡献者，代码平台页面也可能显示不同维护者、提交者和组织。如果机械要求每一位历史贡献者都逐一出具授权，很多长期维护的开源项目几乎无法维权；但如果完全不审查权利来源，又可能让并非真正权利人的主体代表项目主张权利。罗盒系列案件的启示在于，法院需要结合项目创建、代码提交记录、主要维护者身份、贡献者协议或授权安排、项目迁移和商业化承继关系等事实，判断起诉主体是否对涉案开源软件享有足以维权的权利基础。这对开源项目商业化主体尤其重要：企业不仅要维护代码仓库，也要保存贡献记录、授权文件、权利承继文件和版本发布证据。

这六组规则共同形成一个较平衡的框架：既承认开源协议的法律效力，也防止GPL Copyleft效力被无限扩大；既保护开源社区规则，也不让侵权人利用开源规则逃避复制责任。

下篇预告：

在下篇中，我们将聚焦开源的商业策略与跨境合规维度，分析开源与闭源的商业模式选择､企业许可证决策框架、出口管制与技术博弈、中欧AI 监管下的开源例外与治理要求，最终提供从识别、分类、审批到隔离、履约、留痕的全流程开源合规治理方案｡