开源许可证合规：先判断分发形态，再谈许可证义务

开源许可证合规最常见的做法，是背一张许可证名单：MIT、Apache、BSD 归为安全，GPL、AGPL 归为危险，SSPL 直接拉黑。这张名单在真实项目里几乎必然出错，因为它漏掉了决定义务的那一层——分发形态。

同一个 GPL 组件，放在公司内部做数据分析，通常不触发任何源代码提供义务；做成 SaaS 对外提供服务，多数情形下仍不触发；改成私有化部署交付给客户，义务立刻产生。许可证没有变，变的是数据与代码到达用户的方式。

一、四步判断顺序

许可证判断不能从许可证名字开始，要从数据流开始。

第一步，是否对外分发。 分发指把软件副本交付给外部主体，包括私有化部署、SDK、命令行工具、硬件预装、镜像交付。SaaS 在多数许可证下不构成分发，因为用户没有取得副本；但 AGPL 与 SSPL 把网络服务纳入触发范围，这两类是例外。

第二步，是否修改。 未修改的组件，义务通常限于署名与许可证全文；修改过的组件，可能触发修改声明、源代码提供，甚至整个衍生作品的许可要求。判断修改要看实质，不看是否改了名字或换了包名。

第三步，链接方式。 动态链接、独立进程、API 调用、插件加载，在不同许可证下的结论不同。LGPL 允许通过动态链接与专有代码结合，前提是用户能够替换该库；GPL 对结合方式的判断更严格，独立进程通常比静态链接更安全，但不是绝对安全。

第四步，许可证类型与附加条款。 前两步确定事实，这一步才轮到查许可证。需要特别留意双许可、附加例外、以及许可证之外的补充条款，例如 Commons Clause 这类在宽松许可证上追加销售限制的安排。

四步走完，结论才成立。直接从第四步开始，得到的只是标签，不是判断。

二、四层许可证谱系

这张表只能用于初筛。真正的结论要回到第一步：强传染许可证在"不分发"的情形下，义务可能根本不发生；宽松许可证在"未保留声明"的情形下，也会构成违约。

三、五项核心义务

其一，署名与版权声明。 保留原作者的版权声明，通常在关于页面、文档或二进制包内的 NOTICE 文件中体现。遗漏是最常见的违约形式，也是最容易被自动化检查发现的。

其二，许可证全文。 随分发物提供完整许可证文本。把许可证放进代码仓库不等于随产品分发，私有化交付时需要在交付包内单独放置。

其三，修改声明。 Apache 2.0 与部分弱传染许可证要求标明修改过的文件。修改声明不是 changelog，要点是"哪些文件被改过"，而不是"改了什么功能"。

其四，源代码提供。 强传染许可证在分发时触发。提供方式包括随附源代码、书面要约、或通过网络地址提供，具体取决于许可证版本。AGPL 的要求覆盖网络服务场景，不能以"没有交付安装包"为由排除。

其五，专利与商标。 Apache 2.0 明确授予专利许可，并含专利终止条款；多数许可证不授予商标使用权。把开源项目的名称与标识用于产品宣传，属于商标问题，不在许可证授权范围内。

四、AI 企业特有的三处

代码扫描工具能覆盖依赖树，覆盖不到下面三处，而这三处恰恰是 AI 企业最容易出问题的地方。

模型权重。 权重的许可证独立于训练代码与推理代码。常见类型包括自定义社区许可证、Apache 2.0、OpenRAIL 类条款，以及带商业使用门槛的许可证。需要逐层核对：基座模型怎么授权，微调产物是否继承限制，蒸馏产物是否构成衍生。只查代码仓库的 LICENSE 文件，得出的结论通常不完整。

训练数据集。 数据集的许可证与代码许可证是两套体系。常见的是 CC 系列、自定义研究许可、以及仅限研究用途的条款。商用模型需要确认数据集的商用授权，以及其中是否包含第三方版权内容。数据来源的授权链断裂，往往在融资尽调或出海审查时才被发现。

推理框架与运行时依赖。 推理框架、CUDA 算子库、量化工具、容器基础镜像，各自有许可证。基础镜像中的系统组件可能包含 GPL 工具，通常在独立进程中使用而不触发传染，但打包方式改变后结论会变。

五、日常落地的四道闸门

合规不是一次审计，而是四次拦截。

第一道，采购准入。 引入新组件、新模型、新数据集前，登记许可证与来源，未经登记不得进入生产环境。这一道决定后续所有工作的成本：源头没有记录，后面只能靠扫描反推。

第二道，持续集成扫描。 在构建流程中生成 SBOM，比对许可证黑名单与灰名单。扫描的价值在于发现传递依赖，直接依赖通常人人知道，传递五层的组件才是风险所在。

第三道，发布检查。 每次改变交付形态时重新判断：从 SaaS 改为私有化，从私有化改为 SDK，从 SDK 改为硬件预装，每一种变化都可能让原本安全的组件变成义务主体。

第四道，对外交付。 交付包内的 NOTICE、许可证全文、修改声明、源代码提供方式，按清单核对。融资、并购、出海时的尽调材料，直接取自这一道留下的记录。

六、五个常见误判

其一，SaaS 就一定安全。 对 GPL 多数情形成立，对 AGPL 与 SSPL 不成立。做 API 服务的企业如果用了 AGPL 组件，用户通过网络使用即可能触发源代码提供义务。

其二，内部使用永远安全。 内部使用不触发分发义务，但"内部"的边界会变。私有化交付、客户现场部署、集团内跨主体提供，都可能被认定为分发。

其三，没有许可证就是公共领域。 恰恰相反，没有许可证意味着默认保留所有权利。GitHub 上大量无许可证仓库属于此类，不能因为"公开可见"就推定可用。

其四，改了名或换了包就不用开源。 衍生作品的判断看代码关系与结合方式，不看名称。重命名、混淆、拆包，都不改变许可证义务。

其五，用了 Apache 就什么都能做。 Apache 2.0 授权专利但不授权商标，也不承诺专利无风险。项目名称、Logo、以及第三方专利池的许可，需要单独处理。

七、与尽调审计的关系

日常合规与交易尽调是两件事，但材料同源。日常留下的 SBOM、许可证矩阵与分发形态判断，构成尽调时的底稿；尽调阶段需要额外补上的，是风险分级、替代方案与可被引用的审计意见。

融资、并购与出海三个时点对材料的要求，以及合格交付物的五个部分，站内《开源合规审计：融资尽调时，投资人要的不是清单，是结论》已作展开。本篇补的是日常判断方法，两篇合起来才构成完整链路。

开源生态的行业共识与政策动向，可参见《人工智能开源生态共识在广州发布》与《上海开源体系建设方案》。知识产权布局的整体框架，见知识产权保护服务页。

本文依据公开许可证文本与通行实践编写，仅供参考，不构成法律意见。具体组件的许可证义务应以其原文条款为准，涉及核心代码或交易安排时应单独评估。