一、探究问题聚焦与研究缘起
（一）开源商业化下的混合许可问题
开源软件已经成为企业软件开发中很难绕开的基础设施。企业使用开源组件，通常并不是因为其“免费”，而是因为它能够节约重复开发成本、缩短产品迭代周期，并借助社区生态解决通用技术问题。但开源软件并非无条件使用。许可证文本会对复制、修改、分发、网络服务、声明保留和源代码提供等行为设定义务。企业一旦把多个开源组件放进同一产品或服务中，问题就不再是某一个许可证能否接受，而是这些许可证义务能否在同一技术架构和交付方式下同时履行。
近年来，Redis、Elastic等基础软件项目调整许可策略，进一步放大了这一问题。Redis官方许可文件显示，自Redis 8起，新版本代码贡献采用RSALv2、SSPLv1、AGPLv3三许可模式，而Redis 7.2及此前版本仍保留BSD-3-Clause许可结构。Elastic也曾在Apache-2.0之后引入Elastic License v2与SSPL，后又宣布为部分产品增加AGPLv3作为许可选项。这些变化说明，项目方正在开源协作、云服务竞争和商业回报之间重新分配权利和义务。[1][2]
需要区分的是，项目方提供多重许可，与企业产品中形成混合许可依赖，并不是同一个概念。多重许可通常是权利人主动设计的授权路径，使用者可以在不同许可条件之间做出选择；企业依赖树[3]中的混合许可，则多半是在研发过程中逐步形成的结果。企业直接或间接引入了不同来源、不同版本、不同许可证约束的组件，并在编译、链接、部署或交付时将其放入同一产品或服务之中。本文所称“开源混合许可”，主要讨论后一种企业实际使用场景。
（二）混合许可的法律后果
在工业级软件中，一个面向客户交付的系统往往同时包含操作系统组件、前端框架、后端库、数据库客户端、容器镜像、压缩工具、测试脚本和部署工具。部分组件只在内部研发环节使用，部分组件会进入最终交付包；部分以源代码方式引入，部分以动态库、静态库、镜像或者服务接口方式存在；部分未经修改，部分已经被企业二次开发。许可证义务通常正是在这些具体行为中被触发。
从司法实践看，开源协议已经被法院作为具有法律效果的许可安排进行评价。最高人民法院在（2021）最高法知民终2063号案中认定，GPLv3协议属于附解除条件的著作权许可合同。被许可人未按照协议开放源代码，可能导致后续使用行为失去授权基础，并构成对软件著作权的侵害。与此同时，最高人民法院在（2021）最高法知民终51号案中又区分了一个关键问题：软件开发者是否违反GPLv2协议，与其是否基于独创性贡献享有软件著作权，并不必然相关。前者关系到其是否需向上游权利人承担违约或侵权责任，后者则关系到其新增表达能否受到著作权法保护。[4][5]
除民事责任外，软件供应链监管也在强化企业对组件来源和依赖关系的记录义务。欧盟《网络弹性法案》（Regulation (EU) 2024/2847）要求相关数字产品制造商识别并记录产品组件，形成软件物料清单（Software Bill of Materials，简称“SBOM”）。该法规主体规则将于2027年12月11日起适用，部分漏洞报告义务则自2026年9月11日起适用。对面向欧盟市场的企业而言，SBOM不只是安全合规文件，也会倒逼企业在研发前端建立开源组件和许可证台账。[6]
因此，开源混合许可的审查需要真正需要回答的是：企业是否复制、修改或分发了上游代码；相关组件是否随产品一并交付给客户；GPL、AGPL、LGPL、MPL等许可证的义务是否已被触发；多个许可证之间是否存在无法同时履行的冲突；企业能否通过架构隔离、版本替换、商业授权或者源代码提供等方式补足合规义务。
二、混合许可审查的前提：回到许可证义务本身
评估开源混合许可风险，首先要回到许可证义务。实践中常把开源许可证划分为宽松型、弱著佐权型和强著佐权型。这个分类有助于初步判断风险，但不能替代具体文本审查。即使同属宽松型许可证，MIT、BSD、Apache-2.0之间在专利授权、NOTICE文件、商标背书等方面也存在差异；同属弱著佐权许可证，LGPL与MPL的义务边界也并不相同。至于SSPL、RSAL、Elastic License等许可证，虽然可能允许查看或使用源码，但并不当然属于OSI意义上的开源许可证，更适合在企业制度中单独列为“源码可用”或限制性商业许可。[7]
表格：常见许可证类型及主要审查重点
需要注意的是，许可证兼容性不是简单的“从严适用”。较准确的判断方法是：多个许可证共同作用于同一软件或同一分发对象时，使用者能否同时履行这些许可证要求。如果可以同时履行，企业应分别完成声明保留、源代码提供、修改标注、重新链接、安装信息等义务；如果不能同时履行，则不能通过选择其中“更严格”的许可证当然消除冲突，而应停止组合分发，或者通过替换组件、调整架构、取得商业授权等方式处理。
GPL版本兼容问题最能说明这一点。GPLv2-only与GPLv3并不兼容；如果上游软件标注为GPLv2 or later，使用者才可能选择GPLv3路径解决组合问题。Apache-2.0通常可与GPLv3兼容，但由于Apache-2.0包含GPLv2未涵盖的专利终止等条款，通常不能直接与GPLv2-only代码组合分发。MIT、BSD-2-Clause、BSD-3-Clause一般被认为与GPL兼容，但并不意味着可以忽略版权声明、免责声明和不得背书等义务。MPL-2.0第3.3条为与GPL、LGPL、AGPLv3等次级许可证的组合提供了路径，但如果上游代码明确标注“Incompatible With Secondary Licenses”，则不能适用该机制。[8]
企业进行开源审查时，不宜只在表格中写明“GPL”“MIT”或“Apache”。更有意义的审查应当具体到使用方式：该组件是否被修改，是否随产品分发，是否以静态或动态链接方式进入主程序，是否通过网络向外提供功能，是否作为客户本地部署包的一部分交付。许可证名称只是审查起点，真正决定风险的是许可证义务与企业使用行为之间的对应关系。
三、常见混合使用场景中的风险边界
（一）源码复制、改写与同一模块混编
风险最直接的情形，是开发人员将开源代码片段复制、改写后放入企业自有代码仓库，或者将不同许可证约束的代码混编到同一源文件、同一模块中。此时，许可证义务通常会随着代码本身进入企业项目。如果该代码适用GPL、AGPLv3等强著作权许可证，企业可能需要面对源代码开放、修改声明、许可证文本提供以及整体兼容性审查等问题。若代码来源本身不清楚，还可能同时产生权属和侵权风险。
这一问题在AI辅助编程环境下会更隐蔽。开发人员可能从开源仓库、技术博客、问答网站或大模型输出中取得代码片段，但未记录原始来源和许可证。企业后续即使发现问题，也难以判断该代码是否属于可自由使用的示例，是否来自GPL项目，是否存在第三方著作权限制。我们认为，对于核心产品代码，企业至少应要求开发人员保留外部代码来源说明，对来源不明或许可证不明的代码进行替换或重写，而不宜在发布前再集中补救。
（二）库链接、组件调用与整体发布
库链接是混合许可中最常见、也最容易被低估的场景。对于LGPL库，许可证文本本身提供了相对明确的合规路径，例如通过共享库机制使用该库，并确保用户能够使用修改后的库与应用程序重新交互；或者提供最小对应源码以及允许重新链接的应用程序目标代码或源代码。对于GPL库，则需要进一步判断主程序与该库是否形成基于GPL程序的作品，或者是否仅属于可以相互独立存在的聚合关系。[9]
实践中，企业常把“动态链接”理解为当然安全，但这一理解可能存在潜在风险。动态链接可以作为技术隔离的事实之一，却不能作为单一判定条件。如果某GPL库承担产品不可或缺的核心功能，主程序与该库之间存在紧密的内部调用关系，并随产品整体发布，仍可能被认定为一个整体程序的组成部分。相反，如果相关组件通过公开、通用接口通信，能够独立安装、独立替换，且功能上并非主程序不可分割的一部分，企业会有更充分的理由主张其未被强著佐权许可证传染。
（三）插件、API、微服务与SaaS部署
插件、API调用和微服务架构为企业控制开源风险提供了现实空间，但其效果仍取决于技术独立性是否真实存在。若插件只是形式上单独命名，实质上随主程序不可分割地编译、安装和运行，且承担核心功能，则难以仅凭“插件”二字排除传染性。反之，如果插件可以由用户单独安装或卸载，通过公开接口与主程序通信，并不与主程序共同构成一个不可分割的二进制整体，其独立性就更容易被证明。
SaaS场景还需要单独审查。传统GPL许可证通常以复制、修改和分发为主要触发场景，企业仅在服务器端内部运行GPL程序并对外提供服务，并不当然触发源代码提供义务。AGPLv3正是针对网络服务器场景作出补充，要求修改版程序通过网络与用户交互时，向用户提供对应源代码获取方式。SSPL在服务场景下要求更进一步，可能涉及使服务运行所需的周边软件源代码公开，因此未获OSI认可。对云服务企业而言，SaaS部署并不是天然安全港，尤其在AGPLv3、SSPL、RSAL等许可证并存时，更应结合服务对象、修改范围和商业使用方式作专项审查。[10]
四、传染性边界和开源抗辩的司法处理
从已有裁判看，法院在判断GPL传染范围时，并不会机械适用某一种技术标签，而是结合代码关系和功能关系作实质审查。在“不乱买诉闪亮时尚案”（（2019）最高法知民终663号）中，前端代码与后端代码在展示方式、所用技术和功能分工上存在明显不同，法院并未因二者存在交互配合就认定后端代码当然受GPL约束。而在部分涉及内部调用、函数调用或者整体发布的案件中，法院则会重点关注被调用GPL组件是否实现了被诉软件不可或缺的功能，二者是否已经高度结合为一个整体。[11]
具体到内部调用、函数调用等场景，法院审查的重点通常不是连接方式本身，而是开源组件在软件整体中的功能位置、调用强度以及是否随产品一并发布。例如，在（2023）苏02民初482号案中，法院关注涉案软件与GPL库之间的直接调用关系，并认为软件其他部分实际与该库形成连接，应当采用GPL许可证发布。在（2021）苏01民初3229号案中，法院亦结合函数调用关系和相关压缩功能是否不可或缺，对GPL传染范围作出判断。这些案件的共同启示是：技术隔离措施应当在软件设计和交付阶段真实存在，并能够通过架构图、编译脚本、分发包结构、接口说明和用户使用方式加以证明。事后仅以“动态链接”“模块化”“微服务”等概括性表述进行抗辩，证明力有限。[12][13]
开源抗辩也需要把握边界。若被控侵权人能够证明其基于GPL等开源协议取得授权，并且自身已经履行开放源代码、保留声明、提供许可证文本等义务，其使用行为可能因存在合法授权而不构成侵权。相反，如果被控侵权人只是主张权利人自身未履行开源义务，进而要求否定权利人对新增独创性表达享有著作权，通常难以得到支持。最高人民法院在（2021）最高法知民终51号案中的立场，正是将软件开发者是否违反GPL义务，与其新增表达是否受著作权法保护区分开来。
这一规则对企业争议处理具有现实意义。企业不能寄希望于“对方也用了开源代码”来当然抗辩侵权，也不能因为自身软件包含开源组件就放弃对新增代码主张权利。更稳妥的做法，是在争议发生前即固定组件来源、许可证文本、版本记录、修改范围、源码开放记录和分发材料；在争议发生后，再围绕授权链是否成立、许可证义务是否履行、被控代码是否实质相似、开源代码与自研代码边界何在等问题展开抗辩或主张权利。
五、企业管理策略：把开源审查嵌入研发流程
开源混合许可风险并不适合完全依赖产品发布前的一次性扫描解决。扫描工具可以发现大量组件和许可证信息，但无法替代对使用方式、交付形态和法律义务的判断。从企业管理角度看，至少需要在组件准入、研发留痕和产品发布三个环节建立机制。
在组件准入阶段，企业可以按照业务目标和交付方式，将许可证区分为常规准入、条件准入和高风险准入。MIT、BSD、Apache-2.0等宽松型许可证通常可作为常规准入对象，但仍需完成声明和NOTICE义务；LGPL、MPL等弱著佐权许可证可作为条件准入对象，要求研发团队说明链接方式、文件边界和重新链接机制；GPL、AGPLv3等强著佐权许可证应进入高风险审批，原则上只在内部工具、独立服务、可开放模块或经专项论证的场景使用；SSPL、RSAL等限制性许可则应由法务、研发和商业团队共同判断是否会影响产品商业模式。
在研发阶段，企业应形成可证明的技术隔离和版本留痕。对于希望闭源交付的核心产品，企业应尽量避免将强著佐权组件静态链接或深度嵌入核心模块。若确需使用相关组件，应优先考虑独立进程、标准协议、公开API、共享库机制等方式，并保存架构设计、接口说明、编译脚本和分发包结构。与此同时，企业应建立SBOM和依赖清单，记录组件名称、版本、来源、许可证、修改情况和使用场景。对于发生许可变更的项目，应区分历史版本授权是否继续有效，以及升级后是否引入新的限制性条款。
在产品发布阶段，审查对象应当是最终交付物，而不是研发仓库。企业需要确认客户安装包、容器镜像、移动端应用、私有化部署包和SaaS运行环境中实际包含哪些组件；对于需要提供源代码的组件，应准备对应源代码、许可证文本、修改说明和安装信息；对于仅需保留声明的组件，应确保产品文档、About页面或随附材料中包含必要声明。不同交付模式下的义务可能不同，同一产品在内部使用、客户本地部署和公有云SaaS场景下，不能当然适用同一个合规结论。
一旦发生开源合规争议，企业也应先固定事实，再选择补救路径。常见补救措施包括补充版权声明和许可证文本、公开对应源代码、停止分发争议版本、替换组件、取得商业授权或者与权利人达成和解。对于已经建立SBOM、版本留痕和发布审查记录的企业而言，争议处理会更接近事实核查和义务补足；对于缺少前期记录的企业，则往往会陷入“组件来源不清、修改范围不清、交付版本不清”的被动局面。
六、结论
开源混合许可的难点，不在于某一个许可证条款本身多么复杂，而在于企业使用开源软件的方式已经高度碎片化。一个产品可能同时包含宽松型许可证、弱著佐权许可证、强著佐权许可证和源码可用许可；同一组件在内部测试中风险较低，在客户交付时可能触发分发义务，在SaaS部署中又可能进入AGPLv3或SSPL的特殊审查范围。因此，企业不能只用“是否开源”“是否免费”“是否动态链接”这样的标签判断风险。
较为稳妥的路径，是把开源许可证治理作为研发和交付流程的一部分：在组件准入阶段识别许可证，在架构设计阶段控制耦合关系，在版本发布阶段核对交付对象，在争议发生时以留痕材料证明授权来源和义务履行。开源软件可以继续作为企业创新的重要基础，但前提是企业能够清楚说明自己用了什么、如何使用、向谁交付、履行了哪些义务。只有在这个基础上，开源生态带来的技术便利才不至于转化为企业商业化过程中的法律不确定性。
【注释】：
[1]Elastic: “Elasticsearch is Open Source, Again”, https://www.elastic.co/blog/elasticsearch-is-open-source-again.
[2]Redis: https://raw.githubusercontent.com/redis/redis/unstable/LICENSE.txt.
[3]依赖树（Dependency Tree）是软件工程中用于表示软件项目及其组成组件之间依赖关系的层级结构模型。
[4]最高人民法院（2021）最高法知民终51号民事判决。
[5]最高人民法院（2021）最高法知民终2063号民事判决。
[6]Regulation (EU) 2024/2847 of the European Parliament and of the Council, Official Journal of the European Union.
[7]Open Source Initiative: “The SSPL is Not an Open Source License”, https://opensource.org/blog/the-sspl-is-not-an-open-source-license.
[8]GNU GPLv3第12条、第13条；FSF许可证清单关于GPLv2、GPLv3、Apache-2.0兼容性的说明；MPL-2.0第3.3条。
[9]GNU LGPLv3第4条。
[10]GNU AGPLv3第13条。
[11]最高人民法院（2019）最高法知民终663号民事判决。
[12]江苏省高级人民法院（2024）苏民终581号民事判决。
[13]江苏省南京市中级人民法院（2021）苏01民初3229号民事判决。
