Vibe Coding 时代的 OSS Compliance Engineering：从许可证识别到 AI-Native 软件供应链治理

日期：2026-10-06 主题：当 AI 辅助/代码生成（Vibe Coding）流水线被用于生产商业软件时，开源依赖的合规风险如何被放大、变形、以及如何被工程化地识别与处置。本文主线从 License 扫描走到 AI-Native 软件供应链治理，对应到 事实等级分层（L1~L5） 、三轨合规模型（OSS / IP / Contract） 、Risk-adaptive Compliance Matrix 三套骨架。 贯穿案例 ：以一款名为 X-SoftAI 的衍生产品（上游基线为某开源项目，类比 Octop/Docker Sandbox 类衍生镜像）为研究对象，演示从"改个名就能商用"到"必须按 PyMuPDF 案例把 AGPL 阻塞项处置掉"的真实落差。

本文定位 ：Vibe Coding 场景下的开源软件合规工程治理指南，不是严格意义上的"Vibe Coding 利用开源软件生成商业软件的法律分析"。本文不构成法律意见；涉及商标、合同、对客条款、跨境许可的部分，请在正式发布前由专业法务复核。

风格守则：术语下沉到正文，表格融入论述。涉及的许可缩写（MIT / LGPL / MPL / AGPL / BSD-3-Clause / Apache-2.0）均按行业惯例使用，正文给出首次出现时的简要界定。

事实等级约定 （贯穿全文使用）：本文将每一处涉及合规义务的论述标注为 L1 Normative Text / L2 Judicial / Regulatory Authority / L3 Authoritative Interpretation / L4 Industry Practice / L5 Engineering Control / L6 Legal Uncertainty，避免把"工程上的保守做法"写成"许可证的法律强制义务"。详见 §2.3。

一、Vibe Coding 与开源依赖的交叉地带
二、商业闭源场景下的开源许可证义务光谱
三、案例剖析：X-SoftAI 的合规盲区
四、强 copyleft 高风险项：以 PyMuPDF 双许可为镜
五、弱 copyleft 的"声明义务"陷阱
六、商标与品牌：MIT 不授权商标
七、源码可得性：从理论声明到工程闭环
八、AI 生成代码的额外不确定性
九、可直接复用的合规清单与声明草案
十、面向商业化的工程治理建议
结论
附录：本文使用的工具 / 仓库 / 资源集

一、Vibe Coding 与开源依赖的交叉地带

Vibe Coding 这个词的边界在业内仍在漂移。本文采用一个相对收敛的工程定义：以自然语言意图驱动、由 LLM 在编辑器或 IDE 代理中生成、改写或重组源码，开发者在"心智放权"状态下接受其产出并形成软件制品 的实践方式。它与传统"AI 补全"的差别在于：意图的颗粒度被显著上推，开发者很少逐行审阅，注意力集中在"跑得通 / 看起来对 / 看起来好"上。

这种工作方式在效率维度是真实的------我本人在多个项目里已经验证，"先让代理出一版、再人工校正"的回合一圈能缩减 3--5 倍。但它在合规维度带来了两个过去不显著的新问题：

依赖引入门槛被压平 。以往"加一个第三方库"要写依赖声明、要查版本、要读 license；现在可能是一句"用 AGPL 包处理 PDF"就让代理引入了一个含 AGPL 许可的依赖，且包被写进交付物，但开发者本人从未读过它的许可证。
代码来源谱系被稀释 。一段 LLM 生成的代码可能训练自某个 GPL 项目、某个 Apache 项目、某个完全私有仓库。它字面上是新代码 ，但是否可能因具体输出与受保护作品之间的复制、实质性相似或其他法律关系而产生第三方权利风险，目前仍属 L6 Legal Uncertainty。本文第八章会以 US Copyright Office 2025 Part 2 与 Doe v. GitHub 第九巡回 2026-09-16 判决为锚点，把这个不确定性问题拆成五件事分别讨论（详见 §8.0）。

这两条叠加之后，传统合规工作里"我读过每个依赖的 LICENSE"这种个人勤勉已经不足以覆盖------风险点从"知情引入"漂移到了"无意继承"。

本文要回答的工程问题是：在这条新工作流里，怎么把"许可风险"从"事后救火"变成"前置拦截"。同时必须区分：

规范性文本（L1 Normative Text）：许可证原文、法规、合同条款明确规定的义务；
司法 / 监管权威（L2 Judicial / Regulatory Authority）：法院判决、政府机构指导、监管规定；
权威解释（L3 Authoritative Interpretation）：FSF / Mozilla / SPDX 等权威机构的官方解读；
行业实践（L4 Industry Practice）：企业通常采用的工程做法；
工程控制（L5 Engineering Control）：为降低风险而采用的额外控制；
未明确定性（L6 Legal Uncertainty）：司法实践尚未明确的问题。

整篇文章会沿用这套事实等级分层展开。这是本轮评议修订后的一个核心提升点------避免把"工程上的保守做法"写成"许可证的法律强制义务"。

本文给出贯穿全文的真实案例场景锚定X-SoftAI（衍生自某上游 MIT 项目），用来演示从"改个名就能商用"到"必须按 PyMuPDF 案例把 AGPL 阻塞项处置掉"的真实落差。本文不构成法律意见。

二、商业闭源场景下的开源许可证义务光谱

为了后面讨论方便，我先把开源许可证按**"商业闭源分发场景下产生的具体义务"**排成一条光谱。这不是一条法律意义上的强弱排序或"传染性"排序------许可证法理上 MPL 的 file-level 机制与 LGPL 的 combined-work 机制在结构上是不同的，不是一条简单的传染程度轴线。本光谱的目标是"工程化的指导对企业的关注点"，请勿把它当法律严格度序列读。

2.1 光谱分类

类型	典型许可	主要企业关注点
Permissive（宽松型）	MIT / BSD-2-Clause / BSD-3-Clause / ISC / Unlicense	Attribution / Notice
Permissive + Patent	Apache-2.0	Attribution / Notice / Patent Grant
File-level Copyleft	MPL-2.0	Modified Covered Files 的 source 发布
Library Copyleft	LGPL-2.1 / LGPL-3.0	Relinking / Replacement / Notices / Source
Strong Copyleft	GPL-2.0 / GPL-3.0	Covered Work / Corresponding Source
Network Copyleft	AGPL-3.0	GPL obligations + Remote Network Interaction 触发的额外源码提供义务
Commercial Dual License	PyMuPDF（AGPL 或商业付费二选一）、MariaDB 等	二选一：付费购买商用许可，或遵守 copyleft 条款

把这张分类背下来，是 Vibe Coding 工程实践里每次引入新依赖都要过的一道安检门 。需要强调的是：这张表里的每一格都不是单一义务，第六章、第七章、第八章会分别回到对应类别展开。

2.2 一条易踩的误区：把"光谱"读成"传染程度"

业内在科普时常把"许可光谱"画成：

Permissive → 弱 copyleft → 强 copyleft → 网络型强 copyleft → 越往右"传染越强"

这个比喻对企业理解有引导价值，但对法务理解是有害的。原因有三：

传染单元不同 。MPL 的传染单元是"被修改的文件"；LGPL 的传染单元是"与库组成的 combined work 的特定要求"；GPL 的传染单元是"基于本程序的 covered work"；它们不是同一种机制的强弱版本。
触发条件不同 。LGPL 的 relink/replacement 要求只在 combined work 情形下触发；GPL 的对应源码义务只在分发 covered work 时触发；AGPL §13 的额外义务只在"通过网络提供对修改后程序的交互"时触发。它们不是"传染程度"，而是"不同维度的义务"。
aggregate 与 independent works 的差异。GPL 自身明确区分 covered work 与 aggregate（聚合作品）。把"Docker 镜像里所有内容"自动视为一个 GPL covered work 是过度简化------第六章会展开"作品边界 + 组合关系 + 分发方式"的分层判断。

因此后续章节在讨论每个具体许可时，我会严格按该许可证自己的法理结构展开，而不是沿用"传染程度"这一比喻。

2.3 事实等级约定（贯穿全文使用）

为了避免把"工程保守做法"写成"许可证法律强制义务"，本文在每一处涉及合规义务的论述前，标注以下事实等级。等级按法律权威度从高到低排列，数字越大不等于越不重要，而是代表从"规范文本"到"工程实践"到"未决问题"的不同性质：

等级	含义	示例
L1 Normative Text	规范性文本：许可证原文、法规、合同条款	GPL §6 的 Corresponding Source 提供义务；MIT 许可证文本
L2 Judicial / Regulatory Authority	司法 / 监管权威：法院判决、政府机构指导、监管规定	Doe v. GitHub 第九巡回判决；美国版权局 2025 Part 2
L3 Authoritative Interpretation	权威解释：FSF / Mozilla / SPDX 等官方解读	MPL 是 file-level copyleft（Mozilla FAQ）；GNU GPL FAQ
L4 Industry Practice	行业实践：企业通常采用的做法	随分发物附第三方源码 tarball；SBOM 作为交付物
L5 Engineering Control	工程控制：为降低风险而采用的额外控制	CI 阻断 AGPL 包；Provenance 扫描；预提交钩子
L6 Legal Uncertainty	未明确定性：司法实践尚未明确的问题	LLM 训练 GPL → 输出是否构成衍生作品；AI 输出可版权性边界

读者在引用本文结论时，请按事实等级区分使用：L1/L2/L3 可作为合规底线与论证依据；L4/L5 是行业可借鉴的工程做法；L6 不可作为确定性结论。

术语下沉：

copyleft：与版权（copyright）相对的概念，要求衍生作品以相同条款发布，但具体传染范围依许可证而定。

SaaS：Software as a Service，即通过网络提供软件能力而非交付本地二进制的形态。

Aggregate：聚合作品，即把独立作品并置而不形成基于原作的 combined work。

SPDX License Expression ：SPDX 标准定义的许可证表达式，支持复合许可（如 MPL-2.0 AND Apache-2.0）。

PURL：Package URL，用于唯一标识一个软件包及其版本、来源的标准化 URI 格式。

三、案例剖析：X-SoftAI 的合规盲区

为了把抽象的许可理论变成可触发的工程问题，我以一款命名为 X-SoftAI 的衍生产品为研究对象，沿用一份真实的合规指南（"X-SoftAI 商业分发合规指南"）中的梳理方式，但所有产品名替换为 X-SoftAI、上游基线名替换为"某上游项目"，避免与任何在售产品产生混淆。

3.1 X-SoftAI 的产品定位与依赖图

X-SoftAI 是一款以"知识库 + 远程协助 + 多 Agent 编排"为内核的闭源商业产品。它衍生自一个上游开源项目（基线为某上游项目，类比 Octop 类的 MIT 项目），包含一个 kbpython-buddy 镜像容器（类比 octop:docker-sandbox 衍生版 MimirBuddy）。其交付物特征：

一个 Docker 镜像，内含完整应用运行时
一个前端 Dashboard（dashboard/assets/*.js），含若干 npm 依赖
一个 Python 后端，含约 200+ 第三方包
一个镜像自带的 PostgreSQL / Redis / ClickHouse / RustFS / MinIO 等数据面组件

技术上的"改名是否导致业务不能做"是次要的；真正阻塞业务的是 PyMuPDF 的 AGPL------这一点在第四章展开。

3.2 第一道盲区：把"MIT 自带免责"等同于"商业免责"

很多团队的认知停在"MIT 是最宽松的许可"------这是对的，但常被误读成"MIT 让你做任何事"。MIT 给你的是对代码的处置自由，但：

它不授权商标。上游项目的 logo、品牌名、商业外观仍受商标法约束。
"AS IS "免责是许可方（上游版权人）对被许可方的免责 ，即上游不因代码缺陷承担责任；但这并不免除你对自己客户的责任------你的客户对你的索赔，需要你自己的 EULA 和责任限制条款来处理。
它不替代你对第三方的义务。哪怕你的代码是 MIT，你的依赖里可能藏 AGPL。

X-SoftAI 改名后对外品牌独立，这一策略本身是对的------保留上游品牌对外服务反而有商标风险。但仅"改名"是不够的，第六章会专门讨论改名与商标的边界。

3.3 第二道盲区：把"打包进容器"当成"内部分发"

很多团队以为"只在我们自己服务器跑"就不触发开源许可条款。这对纯 AGPL-3.0 的"网络服务"条款而言确实不直接触发（AGPL §13 触发条件是"通过网络向用户提供本作品"------纯内部用不触发），但：

一旦你把这个镜像作为 SaaS 提供给外部付费客户，且你修改了 AGPL 程序并提供远程交互，则 AGPL §13 的额外源码提供义务触发------需要向远程交互用户提供修改版的 Corresponding Source。
一旦你把这个镜像作为二进制/容器镜像分发给客户 ，GPL/AGPL 系的 "conveying" 条款可能触发------但需要注意：Docker image 是分发载体/封装形式，不等于一个统一的版权作品。镜像中的各个组件是否构成 GPL covered work 还是 aggregate，需要按作品边界 + 组合关系 + 分发方式逐项判断，不能仅凭"装在同一个镜像里"就自动推出整个镜像受 GPL 约束。

X-SoftAI 的商业形态是"对客 SaaS + 可选镜像交付"，因此两条路径都需要进行合规评估，而不是简单地"都触发"。

3.4 第三道盲区：把"动态链接"等同于"无传染"

LGPL 的核心精神是"允许动态链接而不把整个应用变成 LGPL"，但其要求有四件套：

声明该库的存在与许可
提供库本身源码或书面获取要约
允许用户替换该库（动态链接 + 完整加载路径可见）
不得限制反向工程的便利性（LGPL-3.0 明确条款）

X-SoftAI 的 Python 后端在合规上处理得尚可：使用 psycopg、python-telegram-bot、pynput、python-xlib 这些 LGPL 包时没有静态合并源码 ，并以标准 pip 包管理方式安装。但需要明确：对于解释型语言及其包管理生态，不能仅依据 pip install 或 import 就简单认定其属于 LGPL 意义上的"动态链接" ，应根据 LGPL 对 Library、Combined Work、Minimal Corresponding Source、Application Code 等定义，结合具体实现方式判断。目前 X-SoftAI 仍有许可证声明 + 对应源码获取机制两项发行物控制不完整------合规清单中尚无独立的"配套第三方源码获取通道"声明页。第五章会展开完整清单。

3.5 第四道盲区：把"未修改"等同于"无义务"

MPL-2.0 的传染单元是"被修改过的文件"，未修改的文件理论上仅声明即可。但工程上：

"未修改 "需要可验证：你得能证明某个 npm 包的某个文件在你交付时与上游发布的该版本字节一致（哈希比对），否则下游无法核验。
当 LLM 在你不知情的情况下生成了一段看起来是原创 但实质来自 MPL 包训练语料的代码，"未修改"就不再适用------这是 MPL 条款里对"实质性贡献"的归属判定模糊带。

这是 Vibe Coding 引入的新合规灰区 ：传统合规视角假设"我的代码 = 我手写的代码 + 我引用的库"，Vibe Coding 视角必须承认"我的代码 = 我手写的代码 + 我引用的库 + LLM 隐性带进来的训练语料"。这一点是第八章的重点。

四、强 copyleft 高风险项：以 PyMuPDF 双许可为镜

本章事实等级 ：AGPL §13 的核心义务属 L1 Normative Text ；"Corresponding Source 边界"与"SaaS 触发条件"的精确表述属 L3 Authoritative Interpretation ；"镜像交付触发 Conveying"的工程理解属 L4 Industry Practice ；具体 GPL covered work / aggregate / separate works 判断属 L6 Legal Uncertainty，需结合 FSF 官方 FAQ 与具体技术证据。

X-SoftAI 的依赖图里有一个对企业闭源商业分发构成显著风险 的包：PyMuPDF 1.28.2 。其许可证为 GNU AGPL-3.0 或 Artifex 商业许可 的双许可结构。它承担了一类编码角色的功能------例如在 infra/kb/ocr.py 中（X-SoftAI 的内部路径，类比知识库 PDF OCR 管线）把 PDF 渲染为图像后送入 ONNX 类推理引擎。

4.1 AGPL-3.0 的法理结构

AGPL-3.0 是 GPL-3.0 的"网络条款强化版"。§13 在 GPL-3.0 的基础上增加了一项仅当特定条件满足时才触发的额外义务，其完整要件可拆解为四个：

对象：你修改了 AGPL 覆盖的程序（modify the Program）；
交互对象 ：通过计算机网络与你修改后的版本远程交互的用户（users interacting with it remotely through a computer network）；
提供对象 ：向这些远程用户提供 Corresponding Source（GPL §1 定义的"生成、安装、运行和修改相应 object code 所需的源代码集合"，并扣除 System Libraries 等条款明列的例外）；
形式：可采用"通过网络服务器提供下载"或"书面要约"等方式（AGPL §13 与 GPL §6 均有具体规定）。

把这一要件概括为"AGPL = SaaS = 必须开源"是过度简化------AGPL §13 的触发条件不是"存在 SaaS 形态" ，而是"修改了 AGPL 程序并通过网络向用户提供远程交互"。同理，把 AGPL 笼统地概括为"网络使用即传染"也是不准确的。

4.2 Corresponding Source 的边界

GPL/AGPL 所要求的"源码"不是"整个商业系统的全部源码"。GPL §1 对 Corresponding Source 的定义要点是：

the source code needed to generate, install, and (for an executable object code) run, and to modify the code to perform its functions, in each case ... 减去 System Libraries 等条款明列的例外。

落到 X-SoftAI 这种"对客 SaaS + 镜像交付"的复合形态：

SaaS 路径 ：如果 X-SoftAI 修改了 PyMuPDF 并通过 SaaS 向客户提供远程交互，则 X-SoftAI 须向与该修改远程交互的用户 提供 PyMuPDF 修改版的 Corresponding Source（即修改后的 PyMuPDF 源码 + 其生成/安装/运行所需的脚本），而不是 X-SoftAI 自身的闭源代码。这与"闭源商业授权给客户"仍存在显著冲突，但冲突的具体边界是"PyMuPDF 修改版对应源码"，不是"整个商业系统源码"。
镜像路径 ：如果 X-SoftAI 将含 PyMuPDF 修改版的镜像作为 object code 分发，则 GPL §6 的 Conveying 触发，须在镜像中提供 PyMuPDF 修改版的 Corresponding Source。但镜像中其他未与 PyMuPDF 形成 GPL covered work 的组件 是否必须 GPL，仍需按 GPL 的 covered work / aggregate / separate works 概念逐项判断------不能因为镜像里某个组件是 GPL，就把整个镜像自动视为 GPL 作品。

4.3 关于"Docker 镜像 = 一个 GPL 作品"

这是工程社区常见的简化。GNU 官方 FAQ 与 GPL 文本明确区分 covered work 与 aggregate。一个典型的镜像可能构成这样：

复制代码

Docker Image
├── your-app proprietary
├── nginx BSD
├── python runtime PSF
├── libfoo LGPL
├── libbar MIT
└── libbaz GPL (modified)

判断的要点是：libbaz 是不是被 your-app 以"基于本程序"的 modified / linked 的方式组合 ？进程边界、API 边界等架构事实可以作为分析是否构成 aggregate / independent works 的技术证据之一，但不能自动得出法律结论。这种论证需要技术性证据------不能仅凭"它们装在同一个镜像里"，也不能仅凭"它们在不同进程里"。

X-SoftAI 在 PyMuPDF 这件事上的具体判断应当是：X-SoftAI 主动修改了 PyMuPDF（用于适配其 OCR 管线），并在应用代码中调用了 PyMuPDF 的 API------这很可能构成 covered work，而非 aggregate。因此 X-SoftAI 必须按 PyMuPDF 修改版的 Corresponding Source 范围承担义务，而不是整个镜像的源码义务。

4.4 PyMuPDF 的商业决策与三种处置路径

PyMuPDF 这类"AGPL 或商业付费二选一"的包，工程上有三条处置路径，我按"对工程的侵入度 / 商业形态的保护度"做对比：

路径	具体做法	对商业形态的保护	对工程的侵入度	推荐度
A. 替换依赖	选用 Apache-2.0 / BSD-3-Clause 的同类功能包，X-SoftAI 中替换 `infra/kb/ocr.py` 的渲染调用（约 3--5 处），OCR 部分（ONNX 类推理）不变	完整保留闭源商业形态	中等（需回归验证 PDF 知识库效果）	推荐
B. 购买商业许可	向权利方申请商用授权	完整保留商业形态	极低	当 A 方案在功能/性能上不可替代时
C. 拆服务化	将 PDF→图像这部分完全外移到外部服务或远端处理进程	重新划定传染边界	高（架构改动大）	当 A、B 都不适用时的兜底

X-SoftAI 的情况，路径 A 是相对最干净的工程选择------候选替代包 pypdfium2 的项目本身采用 Apache-2.0 / BSD-3-Clause ，功能覆盖度足以替代 PyMuPDF 的渲染部分。但有一个常被忽视的细节：pypdfium2 的 wheel 与构建产物包含 PDFium（其上游 PDFium 项目采用 Apache-2.0）以及若干第三方依赖。

核心原则：Dependency Replacement ≠ Compliance Closure。替换一个高风险依赖不等于合规工作结束------新依赖的传递依赖闭包、运行时依赖、构建产物中的 bundled components 都需要重新审查。PyMuPDF 这类"AGPL + 商业双许可"包不是简单地把名字替换就能"变干净"------它的下游交付物仍须完整合规审查。
复制代码
PyMuPDF (remove)
      ↓
pypdfium2 (add)
      ↓
PDFium
      ↓
PDFium dependencies
      ↓
runtime dependencies (libgcc etc.)
      ↓
SBOM closure (must re-verify)

4.5 路径 A 的工程实施清单

若按路径 A 推进，需要的工程动作是：

依赖替换 ：在 pyproject.toml / requirements.txt 中将 PyMuPDF 替换为 pypdfium2；
调用迁移 ：ocr.py 中约 3--5 处的 API 适配（fitz.open → pypdfium2.PdfDocument，page.get_pixmap → page.render(...).to_pil() 等）；
依赖传递闭包审查 ：用 pip-licenses 或 pipdeptree 拉出 pypdfium2 的传递依赖，审查其许可证（特别是 wheel 内置的 PDFium 与构建产物）；
回归验证：用 X-SoftAI 知识库中的真实 PDF 样本（不同页数、不同编码、不同字体嵌入）做端到端验证；
清单复检 ：重新扫描 THIRD-PARTY-NOTICES，确认 AGPL 条目归零；
构建验证：CI 中加入"AGPL 准入校验"（详见 9.5 节），阻止任何 AGPL 包再次被引入。

第 6 步是 X-SoftAI 合规工程里最具长期价值 的一步------它把"事后清理"变成"前置拦截"。具体实现上，应使用SBOM + License Policy（详见第十章）而非简单的许可扫描命令。

4.6 一个常被忽视的"历史版本"问题

即使 X-SoftAI 移除了 PyMuPDF，PyMuPDF 在历史 build 中的痕迹也可能构成遗留风险：

已交付的旧版本镜像里仍含 pymupdf 1.28.2------这些版本仍在客户侧运行；
旧版本的源码如果已经基于 AGPL 衍生（即使你不打算公开），你在新版本里删了并不回溯已经分发的版本。

工程上的处置是版本归档 + 按适用许可证要求持续维护源码获取通道：在 X-SoftAI 官网建立"配套第三方源码获取通道"声明页（详见 9.4），把"可应要求提供对应版本 PyMuPDF 修改版 Corresponding Source"作为长期兜底义务，而不是版本回溯替换。

需要明确的是："30 天内响应"是 X-SoftAI 自定的服务承诺 SLA，不是 GPL/AGPL 的统一法定期限 。GPLv3 §6 对"physical product"提供的书面要约明确要求"至少三年内有效 "；AGPL §13 对网络提供源码的方式另有规定。X-SoftAI 选择 30 天只是企业内部 SLA，可以根据风险偏好设为更长，但不能写成"GPL/AGPL 要求 30 天"。

五、弱 copyleft 的"声明义务"陷阱

本章事实等级 ：LGPL 与 MPL 的文件级 / combined work 机制属 L1 Normative Text ；FSF / Mozilla 官方解释属 L3 Authoritative Interpretation ；哈希一致 = "未修改"为 L5 Engineering Control 范畴的工程证据，不是法律判定。

移除了强 copyleft 阻塞项之后，剩下的"弱 copyleft"包构成了 X-SoftAI 的次级合规清单。这一类不会导致你的作品整体开源，但每一条都有具体动作义务，漏一条就构成对许可条款的违反。

5.1 LGPL 系包：动态链接不是唯一合规路径

X-SoftAI 的 Python 后端包含以下 LGPL 包：

psycopg / psycopg-binary / psycopg-pool（LGPL-3.0）：PostgreSQL 客户端驱动；
python-telegram-bot（LGPL-3.0）：Telegram Bot 集成；
pynput（LGPLv3）：远程控制输入模拟；
python-xlib（LGPLv2+）：X11 协议绑定。

一个常见的技术误解是"LGPL = 必须动态链接才合规"。这一点不准确。LGPL 体系下，静态链接也是可能合规的，只是需要满足额外条件。LGPL-3.0 §4 对 Combined Work 提供了多条合规路径。下面从工程场景角度区分四类典型情形，其中 1、2 是主要 linking scenarios，3 是特殊部署情形，4 是作品边界分析场景：

场景 1：共享库 / 运行时加载（Shared / Runtime Library）

应用通过共享库 / 动态加载机制使用 LGPL 库，确保：

用户有能力修改 LGPL Library 并重新链接 / 替换（relink / replace the LGPL-covered library）后仍能与应用组合运行；
随分发物提供 LGPL 库的 Library Corresponding Source（即 LGPL §1 定义的 "Library Corresponding Source"，包含生成/安装/运行 Library 本身所需的源码）；
如应用做了对 Library 的修改并静态合并，则需按 LGPL §4 另行处理。

注意：对于解释型语言（如 Python）及其包管理生态，不能仅依据 pip install 或 import 就简单认定其属于 LGPL 意义上的"动态链接"。应根据 LGPL 对 Library、Combined Work、Minimal Corresponding Source、Application Code 等定义，并结合具体实现方式判断。

场景 2：静态链接（Static Linking）

如果选择静态链接 LGPL 库，LGPL-3.0 §4 要求提供：

Minimal Corresponding Source：仅 LGPL 库的修改部分源码；
Corresponding Application Code：被静态链接的应用代码中能与库交互的部分源码；
用户重新链接 / 替换库的能力：用户可以重新编译并替换库版本；
充足的通知与材料：例如以"X-SoftAI 使用 LGPL 库，下文描述重新链接步骤"的形式告知用户。

在企业实践中，静态链接 LGPL 库是高负担路径 。X-SoftAI 的 Python 后端使用 pip 包管理方式安装 LGPL 包，没有对库源码进行静态合并；但具体法律关系仍需结合 Library、Combined Work 等定义逐项判断，不能仅凭包管理方式自动归类为"动态链接"路径。

场景 3：系统级动态库（System Library）

/usr/lib/x86_64-linux-gnu/libfoo.so 是系统包管理器提供的动态库。这种情况相当于场景 1 的部署特例，且库的"源码获取"义务由系统包提供者承担------但你的应用仍需履行 LGPL 的声明与著作权保留义务。

场景 4：独立进程 / IPC

将 LGPL 库作为一个独立进程运行，通过 socket / IPC / HTTP 与主应用通信。这种情况可能被论证为"两个独立作品"------但这条路径的论证强度依赖具体技术边界（独立进程不足以独立，仍需有清晰的 API 边界与数据流分离）。

重要结论 ：进程边界是工程架构事实，不是许可证自动产生的法律边界。IPC 不是 LGPL 的安全港（safe harbor）。判断是否构成独立作品，需要综合考虑 API 边界、数据交换方式、功能依赖程度、是否针对特定库设计、是否实际上形成一个统一程序等因素。

5.2 LGPL-3.0 §4 的反向工程条款

LGPL-3.0 确实要求包含一个反向工程条款，但不是"全面禁止任何反向工程" ，而是要求不得通过额外条款限制 LGPL Library 部分的修改与为调试这些修改所必要的反向工程。GNU LGPL-3.0 原文表达是：

reverse engineering for debugging such modifications

因此 EULA 中需要遵循的不是"删除禁止反向工程条款"这样笼统的表述，而是"在必要修改 / 重新链接 / 调试修改的范围内，不得以合同限制 LGPL Library 部分的反向工程"。这是一个范围限定的免责，不是全面免责。

X-SoftAI 在客户 EULA 中需要做的调整是：

删除任何"禁止对全部交付物进行反向工程"的笼统条款；
改为"在适用开源许可证所允许的范围内，反向工程不受本协议禁止"的限定性条款；
该条款首先针对 LGPL-3.0 §4 中对 Library 修改及调试所涉及的反向工程限制。对于 MPL、GPL、AGPL，应分别依据其自身条款及适用法律判断，不得将 LGPL 的特定反向工程要求机械推广到其他许可证。

5.3 MPL-2.0 的文件级机制与 SPDX 表达式

X-SoftAI 中包含以下 MPL-2.0 许可证表达的包：

包	SPDX License Expression	主要备注
`bidict`	MPL-2.0	纯 MPL-2.0
`certifi`	MPL-2.0	纯 MPL-2.0
`tqdm`	MPL-2.0	纯 MPL-2.0
`orjson`	MPL-2.0 AND (Apache-2.0 OR MIT)	复合表达：包含 MPL-2.0 代码同时包含 Apache-2.0 / MIT 代码

这个 orjson 的许可证表达式是一个重要的点------它提醒许可证扫描不能只看 package-level license 名称 ，而应当尽可能解析 SPDX license expression 与文件级许可证。MPL-2.0 AND (Apache-2.0 OR MIT) 的含义是：包内某些文件是 MPL-2.0、某些是 Apache-2.0 / MIT。使用 SPDX 表达式能避免错误地"全包都是 MPL-2.0"这样的一刀切表达。

MPL-2.0 的传染单元是被修改过的 Covered File。MPL §3 的具体义务是：

你在分发 Modified Version 时，被修改的 Covered File 须以 MPL-2.0 发布；
同一 Medium 中其他未修改的 Covered File保留原有许可证；
其他独立作品（你的应用代码）不受传染。

Vibe Coding 特别注意 ：MPL 的"file-level"不能机械理解成"Git 文件名级别"；关键在于该文件是否包含 MPL Covered Software 的 Modification。新建文件如果复制了 MPL 代码，也可能进入 MPL 的覆盖范围------Mozilla FAQ 明确将 "new files into which MPL-licensed code has been copied" 纳入 Modification 范畴。这与 Vibe Coding 高度相关：AI Agent 很可能将上游 MPL 文件的代码重构到新文件中，此时该新文件仍可能受 MPL 约束。

工程上的关键问题 ：判断一个 MPL 文件"是否被修改过"依赖许可证对 Covered Software、Modification、Larger Work 的定义，而不是简单的 Git diff 或 SHA256。SHA256 一致只是"未修改"的一个工程证据 ，它不是许可证上的法律判定------但它是一个非常好的工程证据，X-SoftAI 在 THIRD-PARTY-NOTICES 中应当对每个 MPL 包附"该包在交付时与上游 X.Y.Z 版本哈希一致"的声明页。任何包管理器都能给出 lock 文件，从 lock 文件提取哈希就能算。

5.4 一个 Vibe Coding 专属的新增面

Vibe Coding 流水线里可能出现一个新场景：LLM 在生成代码时"参考"了某个 MPL 文件的源代码，生成了"看起来不一样但实质相似"的代码。这种情况的判断应按风险等级分档（这是 L4 推出的企业级处理思路，不是 L1 许可证事实）：

Risk Level	触发条件	处置动作
R0	普通 AI 生成代码，与已知 OSS 不存在明显相似	正常 code review
R1	生成代码与已知 OSS 项目高度相似	Provenance Review（人工来源调查）
R2	发现特定 OSS 项目来源（Permissive / MPL / LGPL）	License Review（按该项目许可证处理）
R3	检测到 GPL/AGPL/商业限制代码来源	Compliance Gate（合规闸门拦截）

这一档位设计与第十章的 Risk-adaptive Compliance Matrix 一脉相承。其法律性质需要明确：这是一个企业工程控制 ，是为了在不收敛的 LLM 输出版权判断下降低未来争议成本而采取的预防性投资，不是许可证的强制义务。

与第八章的关联：MPL 的 file-level copyleft 与 AI 生成代码的 provenance 问题高度相关------判断"新文件是否包含 MPL Covered Software 的 Modification"与判断"AI 生成代码是否来自受保护作品"是同一类法律问题（实质相似性 + 来源追溯）。详见 §8.3 对训练语料继承问题的拆解。

六、商标与品牌：MIT 不授权商标

本章事实等级 ：商标独立性原则属 L3 Authoritative Interpretation ；"truthful attribution 是关键"属 L4 Industry Practice。

X-SoftAI 与上游项目的关系中，"改名"只是合规动作的一部分，不是全部。第六章专门处理商标与品牌问题。

6.1 MIT License 的授权范围

MIT License 主要授予版权相关权利，不构成对上游商标、品牌标识或其他独立知识产权的普遍授权。具体地说：

MIT 授权覆盖的：源代码、文档、配置文件等版权作品；
MIT 不授权的：上游项目的商标（logo、产品名、商业外观）；
MIT 的标准文本没有像 Apache-2.0 那样提供明确的专利授权条款（X-SoftAI 如果下游依赖 Apache-2.0 代码，应注意其明确的专利授权机制）；
MIT 不当然授权的其他独立知识产权（例如商标及不属于代码版权范围的 UI / 设计资产）。

需要注意："商誉"（goodwill）不是与商标、版权、专利平行的独立 IP 权利类型，它是商业标识领域中的一个概念，不应在本节作为独立项列出来。

X-SoftAI 改名后对外品牌独立 ，这规避了对外使用上游品牌的商标风险。但仍有两个细节需要工程化处理：

不要在 README、EULA、文档中暗示与上游的官方关联------例如不要写"X-SoftAI 是某上游项目的官方商业版"，可以写"基于上游项目开发"或"contains code from <上游项目>"；
不要复用上游 logo、配色、商业外观------这是商标侵权的常见触发点。

6.2 NOTICE 中的措辞：Truthful Attribution 是关键

NOTICE 文件中关于"基于上游开发"的措辞需要谨慎，但不要把"模糊化来源"作为合规策略 ------法律合规文件最重要的是真实、准切的归属（truthful attribution），而不是"找一个看起来更模糊的措辞"。原文中使用的措辞应反映事实关系。

推荐 X-SoftAI 按事实情况选择以下表达之一（在第九章给出完整草案）：

复制代码

This product is based on <Project>
This product incorporates code from <Project>
This product is derived from <Project>
This product is a modified version of <Project>

选择哪个取决于实际的关系：

如果 X-SoftAI 主要是基于上游项目改写："This product is based on / incorporates code from <Project>"；
如果 X-SoftAI 是上游项目的 hard fork："This product is derived from <Project>"；
如果 X-SoftAI 是包含修改的衍生品："This product contains modifications to <Project>"。

需要保留的元素是 MIT §(b) 明确要求的两点：

"Copyright (c) <年份> <上游版权人>"------上条版权声明；
"licensed under the MIT License"------许可证措辞。

把"developed as part of"理解为"比 forked from 更安全"是个误导------合规文档的价值是事实准确 ，不是表达含混。

6.3 商标与"上游项目未来行动"的关系

如果 X-SoftAI 商业化到一定规模，上游项目可能会：

给 X-SoftAI 发函要求停止使用其品牌（即使你声明了"非官方"）；
或反过来要求你停止暗示关联；
甚至变更自己的项目名称/logo（这种变动在上游项目中并不罕见）。

工程上的长期对策是：让自己的商标、产品名、文档、UI 都完全自主。X-SoftAI 这个名字、其 logo、其 UI 文案都不应复用上游任何标识。这不是在说"你不要提上游"，而是在说**"你只能提到上游代码，不能提到上游品牌"**。这是在规模化之后救你的唯一保险。

七、源码可得性：从理论声明到工程闭环

本章事实等级 ：GPL §1 对 Corresponding Source 的定义属 L1 Normative Text ；GPL §6 对书面要约"至少三年有效"的规定属 L1 Normative Text ；30 天响应属 L5 Engineering Control（X-SoftAI 选择的 SLA）。

GPL/AGPL/LGPL 体系下的"提供源码"义务，并不是一句"可应要求提供"就完成。第七章把这条义务拆解到工程闭环。

7.1 Corresponding Source 的边界（按 GPL §1 原文定义）

GPL §1 对 Corresponding Source 的定义要点是：

the source code needed to generate, install, and (for an executable object code) run, and to modify the code to perform its functions, in each case ...

中文表达：它是"生成、安装、运行（及可执行的修改）相应 object code 所需的源代码集合"，并扣除 System Libraries 等条款明列的例外。

这一表述有一个常见的工程误解："文档"不是一个自动无条件的 Corresponding Source 成员。GPL-3.0 在 §6 中另有 "Installation Information"（安装信息）的概念，但这是用户在另起所要求的"能够在该环境中安装与运行修改后的作品"的信息，不是版权。

落到 X-SoftAI 中，不同许可证体系对"源码"的术语与范围各不相同，不能统一用"Corresponding Source"一词概括：

GPL / AGPL ：使用 Corresponding Source 术语，指生成、安装、运行和修改相应 object code 所需的源代码及脚本，并扣除 System Libraries 等例外（GPL §1 / AGPL §1 引用 GPL §1）。
LGPL ：使用 Library Corresponding Source 术语，指 Library 本身的对应源码；在 Combined Work 场景下还可能涉及 Corresponding Application Code（应用代码中与重新链接相关的部分）。
MPL ：使用 Source Code of the Modifications / Source Code of Covered Software 术语，指 MPL 覆盖文件及其修改版的源码（MPL §3.2）。

术语原则：不同许可证有不同的源码定义与提供机制，应使用各许可证自身的术语，不要把"Corresponding Source"机械套用于所有 copyleft 许可证。

X-SoftAI 的工程做法是：对每个 LGPL / MPL / GPL / AGPL 包，随交付物附其上游 release tarball 哈希 （SHA256 / SHA512）------这样下游审计者可以核验"我拿到的源码和上游 release 一致"。哈希不是许可的法律判定依据 ，它是标识"未修改"的工程证据。制品身份一致性 ≠ 法律关系认定（Artifact identity ≠ Legal characterization）。

7.2 "提供源码"的工程形态与许可证差异

不同许可证的源码提供机制各不相同，不能把 GPL 的 "written offer" 机制机械套用于所有许可证。以下按许可证分别说明：

GPL / AGPL（Corresponding Source）

GPL §6 对 conveying object code 提供了多种合规方式，AGPL §13 针对远程网络交互另有专门的源码提供条款。

形态	工程做法	适用场景	事实等级
A. 随分发物附带源码	把对应源码打包进交付物（如 `/app/third_party_sources/`）	适用所有 conveying 场景	L1
B. 公开可获取的精确版本源码	给出能够实际取得该版本对应 Corresponding Source 的有效获取方式（GitHub tag / release / source archive / 公司镜像等）	网络分发 / SaaS 场景	L1
C. 书面要约（Written Offer）	"可应要求提供对应源码" + 联系方式 + GPL §6 要求的期限（至少三年有效）	仅在 GPL §6 允许的 conveying 方式下适用	L1

AGPL 特别注意：AGPL §13 的源码提供义务针对"远程交互用户"，其提供方式可以是"通过网络服务器提供下载"等，不等同于 GPL §6 的书面要约机制。

LGPL（Library Corresponding Source + Relinking Materials）

LGPL 的源码提供义务涉及 Library Corresponding Source，在 Combined Work / 静态链接场景下还可能涉及 Corresponding Application Code 及重新链接材料。其提供方式参照 GPL 条款适用，但需额外满足 relinking / replacement 相关要求。

MPL（Source Code of Modifications）

MPL §3.2 要求分发可执行版本时，必须告知接收者如何获得 MPL 覆盖部分的 Source Code。Mozilla FAQ 明确说明，分发 executable 时必须让接收者知道在哪里取得 MPL 部分的 source。

形态	工程做法	说明
随分发物附源码	将 MPL 覆盖文件的源码与修改记录打包	最直接的合规方式
告知获取方式	在 NOTICE / 文档中给出能够实际取得该版本对应 Source Code 的有效获取方式	必须是对应版本、可实际获得

关键原则 ：MPL 的源码提供义务针对"被修改的 Covered Files"，不是整个项目。Source 获取方式的核心是可获得性 + 对应版本，不限于 GitHub。

X-SoftAI 推荐的工程组合：

Permissive（MIT/BSD/Apache）：随分发物附 LICENSE 文本与版权声明；
MPL：随分发物附 MPL 包源码 + 版本哈希，或给出有效 source 获取方式；
LGPL：随分发物附 Library Corresponding Source + 重新链接说明；
GPL / AGPL：精确版本对应的 Corresponding Source 公开归档 + 书面要约作为兜底；

重要提醒 ：书面要约仅在相应许可证及分发方式允许/要求该方式时使用，不得把 GPL 的书面要约机制机械套用于 MPL 或所有 AGPL/LGPL 场景。

7.3 几个常见的工程误解

误解 1："给一个仓库 URL 就能满足源码义务"

不完全准确。关键判断要点是：

该 URL / 获取方式是否提供的是精确版本对应的源码（不可指向 master 或 moving branch）；
该获取方式是否满足许可证规定的可获得性要求（长期有效、可重复获得）。

X-SoftAI 应该：

复制代码

X-SoftAI v5.3.0
  ↓
OSS manifest
  ↓
component version
  ↓
source artifact
  ↓
SHA256
  ↓
per-version archive

每一环都不可省略：包必须能映射到精确版本，精确版本必须能映射到精确 source artifact，artifact 必须有哈希可验证。

误解 2："30 天内提供源码"是 GPL/AGPL 的法律要求

不准确。GPLv3 §6 对"physical product"的书面要约明确要求"至少三年内有效 "；AGPL §13 对网络提供源码的方式另有规定。X-SoftAI 选择 30 天只是企业内部 SLA，可以根据风险偏好设为更长，但不能写成"GPL/AGPL 要求 30 天"。

误解 3："随分发物附源码"等于"开源 X-SoftAI"

不准确。它只随附源补代码与 LGPL / MPL / GPL / AGPL 库的源码（详见 7.1 边界），不包含 X-SoftAI 自身的闭源代码。X-SoftAI 的闭源权利受 LICENSE 的保护（虽然该 LICENSE 仅授予源码层面的权利）。

7.4 镜像交付物里的"源码获取通道"声明页

X-SoftAI 需要一个独立的、可被搜索引擎索引到的"配套第三方源码获取通道"声明页。该页面应至少包含：

X-SoftAI 当前版本号；
X-SoftAI 已知的 LGPL / MPL / GPL / AGPL 依赖清单（指向 THIRD-PARTY-NOTICES）；
每个 LGPL / MPL / GPL / AGPL 包的对应源码获取方式及机制（bundled source / source availability notice / written offer 等，以适用许可证为准）；
联系方式与响应时效承诺（如 30 天内通过邮件回复）；

这一页面不需要公开 X-SoftAI 自己的全部源码 ；它承担的是各适用许可证项下相应的源码获取 / 通知义务，具体范围必须按组件的许可证、修改状态和分发方式逐项确定。页面本身可以设计成动态生成的（从 THIRD-PARTY-NOTICES 生成 HTML 页面），以避免手动维护与代码脱节。

八、AI 生成代码的额外不确定性

本章事实等级 ：US Copyright Office 2025-01-29 Copyright and Artificial Intelligence, Part 2: Copyrightability 结论属 L2 Judicial / Regulatory Authority （政府监管机构指导）；Doe v. GitHub 第九巡回 2026-09-16 判决属 L2 Judicial / Regulatory Authority （司法判决）；LLM 训练语料 → GPL 继承目前仍属 L6 Legal Uncertainty。

Vibe Coding 的"额外风险"集中在 LLM 生成代码的法律地位上。本章必须先把几个完全不同的法律问题拆开，它们不能压缩为一条：

Copyrightability（可版权性）：这个代码是否产生可保护的版权？
Copyright Infringement（版权侵权）：这个代码是否侵犯第三方版权？
License Obligation（许可义务）：你是否有权按照某许可证使用第三方代码？
Contract（合同）：你与模型供应商 / 客户之间有没有额外合同限制？
Patent Risk（专利风险）：代码是否涉及第三方专利权利要求？

这五件事在法理上是独立的，不能被压缩成"AI 生成代码 → 是否受版权保护"这样一个问题。原文最大的问题就是在这个拆解上没拆开。

8.1 Copyrightability：US Copyright Office 2025 Part 2

US Copyright Office 于 2025-01-29 发布了 Copyright and Artificial Intelligence, Part 2: Copyrightability （L2 Judicial / Regulatory Authority，政府监管机构指导）。该报告比 2023 年指导意见更加准确：

AI 生成的内容是否可以受到版权保护，不取决于"是否是 AI 写的"，而取决于人类是否对最终表达作出了足够的原创性决定、选择、安排或修改。

实操要点：

仅仅使用 prompt 不足够 。US Copyright Office 反复表达："a prompt that provides specific instructions for generative AI output"不足以提供署名前人署作者性。
人类编辑 / 选择 / 安排可提供作者性。从多个 AI 生成变体中选出一个、重组、修改、从头与 AI 合作，这些都可能提供作者性。
AI 生成内容在经过足够的人类创作控制后，可以在相应范围内获得版权保护------前提是人类提供了足够的创作控制。

X-SoftAI 在实践中的处理是：保留"人工审阅 + 实质性修改"环节。这里有两个点需要区分：

来源版权 ：AI 生成代码本身可能没有可主张的版权（如果仅靠 prompt）。但这不等于你不能使用------你可以使用没有版权的作品，反之你也不能主张对其本身他人侵权。
使用后的产品权利 ：你使用后产出的 X-SoftAI 代码、其价值不是来自"该代码是否被人类写出来的"，而是来自你对其采取的选择、安排、修改。X-SoftAI 团队可以在法律允许的范围内主张其人类创作贡献所产生的版权权益；具体权利归属仍取决于作者身份、雇佣关系、合同安排以及适用法。

注意：版权保护能力问题 ≠ 代码使用许可问题。这两者需要明确区分。后者在第八章后续主线具体拆开。

8.2 Copyright Infringement：Doe v. GitHub 最新进展

以 2026-10-06 为时间点，原文中"Doe v. GitHub，结论尚未收敛"这句表达已经过时。第九巡回上诉法院 在 2026-09-16 对 Doe v. GitHub 作出了判决（L2 Judicial / Regulatory Authority，司法判决）。需要明确：

法院维持了 DMCA §1202(b) 相关请求的驳回，核心理由之一是：Copilot / Codex 生成新的作品，并不是从既有作品的复制件中 "remove or alter" copyright management information。
该判决不意味着：AI 生成代码不会侵犯版权。该判决不意味着：AI 输出的开源许可义务为零。该判决只意味着：本案的 DMCA §1202(b) 主张未能成立。
本判决不解决：AI 输出是否可能构成版权侵权、开源许可义务是否因特定输出而产生、训练语料是否合理使用等其他问题。

这一项划界很重要：不能用"Doe v. GitHub 驳回 DMCA §1202(b) 主张"推出"AI 生成代码不受开源许可约束"的结论。后者是一个完全未被本次判决覆盖的问题。

进一步澄清 ：Doe v. GitHub 解决的是特定 DMCA §1202(b) "remove or alter CMI" 理论，不是 AI 代码版权侵权、开源许可证义务或训练行为合法性的总判决。该判决的适用范围有限，不能外推到所有 AI 版权问题。

8.3 License Obligation：训练语料继承问题

原文的逻辑是：

复制代码

LLM 训练了 GPL
  ↓
AI 生成代码
  ↓
GPL 衍生作品

这个推导不能作为确定性的法律分析。这里混合了三个完全不同的问题：

A. 模型训练是否侵权------这是问题 A。
B. 模型输出是否构成原作品的复制 / 衍生作品------这是问题 B。
C. 如果输出构成复制 / 衍生作品，原开源许可证是否随之产生义务------这是问题 C。

三者不能被压缩为"训练过 GPL → AI 生成 → GPL 衍生作品"这一条逻辑链。这条逻辑链目前在多数法域下未能被多数司法实践明确证实 。更合理的状态应是 L6 Legal Uncertainty。

8.4 工程上的风险治理动作

在法律状态未明确收敛的背景下，X-SoftAI 采取的是工程上的风险控制 （L5 Engineering Control ），不是为了"避免某一个具体法律行为"（那个具体法律行为超出了当前可证实范围），而是为了减少未来争议成本。

按风险等级划分：

Risk Level	触发条件	处置动作
R0	普通 AI 生成代码，与已知 OSS 不存在明显相似	正常 code review
R1	生成代码与已知 OSS 项目高度相似	Provenance Review（人工来源调查）
R2	发现特定 OSS 项目来源（Permissive / MPL / LGPL）	License Review（按该项目许可证处理）
R3	检测到 GPL / AGPL / 商业限制代码来源	Compliance Gate（合规闸门拦截）

这个设计是基于上述五类法律问题拆开后得出的；从任何一个风险等级出发，都应能够追溯到对应的事实、证据、许可证条款或其他法律依据。

X-SoftAI 在工程上的对策包括：

建立"Provenance Review" 。对 LLM 生成的代码做与已知 OSS 项目的相似度扫描，对超过阉值的代码段进行人工来源调查。必须明确：相似度扫描不是 Legal Determination------它只是为企业提供一个 Risk Level 评估输入。
优先使用经合规训练的模型 。部分商业模型提供"训练语料排除 GPL"之类的承诺，这可以作为但不一定为：这个承诺本身不是可践行的法律证据，供应商自己也不能保证这个承诺完全成立。
保持人类审阅作为最后一道闸门。不接受"100% LLM 代码 + 原生修改"作为交付物。
明确相似度扫描工具的定位。原文提出"工具如 scc、codeql"是不准确的：
- scc 是源代码计数器 / 代码统计工具，不是 OSS 相似度检测器。
- CodeQL 是语义代码分析 / 代码安全扫描工具，不是 OSS 相似度检测器。
- Software Heritage 是源代码归档与来源基础设施（source code archival / provenance infrastructure），用于保存和追溯软件源代码的历史版本，不是专门的 AI 生成代码相似度检测器。
- OSS provenance / code similarity detection 是一类独立工具能力，包括代码指纹、克隆检测（clone detection）等专门技术。

X-SoftAI 应当选择明确可用于 provenance 检测的工具，而不是依赖 scc / codeql 这类不针对该场景的工具。

8.5 Patent Risk：AI 生成代码与第三方专利权利要求

原文"AI 专利贡献者"这个表达不准确。更准确的问题是：AI 辅助开发的代码是否实施了第三方专利权利要求？

这个问题与"模型训练时是否看过该专利"不是同一个法律问题。专利侵权判断的核心是：实施的技术方案是否落入有效专利的权利要求范围，与生成过程的训练来源无直接必要联系。

展开来讲：

专利侵权需要"实施该专利"（make / use / sell / offer to sell / import）；
是否训练过该专利 与是否实施该专利是两个独立的法律问题------即使模型从未见过某专利，AI 生成的代码也可能因巧合或技术趋同而落入该专利的权利要求范围；反之，即使模型训练时见过某专利，生成的代码也不一定构成侵权。
X-SoftAI 输出的代码本身是否落入某些公司的专利权利要求，这个判断与生成过程无关，只与输出代码的技术实现有关。

关键原则 ：AI 生成代码可能实施第三方专利权利要求，这是独立于模型训练来源的专利风险。 不能用"模型训练时没有看过某专利"来论证"生成的代码不侵犯该专利"。

X-SoftAI 在 EULA / 产品文档中应包含专利风险提示 ，例如"使用 AI 生成代码应自行评估专利风险"这类免责表达。这是一个 L4 Industry Practice，X-SoftAI 应当与"版权提示 / 技术服务提示"一起作为合规文档的组成部分。

8.6 小结：三个拆开的点

对于 Vibe Coding 这个场景下的开源许可问题，读者需要明确：

"AI 代码不能受版权保护 "这是个不准确表达，准确表达是"AI 输出是否受版权保护取决于人类是否提供了足够的作者性选择权"（US Copyright Office 2025 Part 2）。
"训练过 GPL → 输出是 GPL 衍生作品 "这是个不能作为确定结论的逻辑链，目前属 L6 Legal Uncertainty。
"GitHub master 在某些案件中获胜" 个个表达仅在 Doe v. GitHub 的特定 DMCA §1202(b) 主张中成立，不能推出"AI 输出零许可证风险"的结论。

后续各节为讨论 X-SoftAI 面临的具体开源代码问题时，应明确其事实等级，不应将 L5 Engineering Control 错误表达为 L1 Normative Text。

九、可直接复用的合规清单与声明草案

为了便于工程团队落地，我把 X-SoftAI 在合规工作里沉淀出来的清单与草案整理在本章。本章从"许可证清单"升级为 SBOM + License Decision Record------这是企业级 OSS Compliance 与传统许可证清单的主要区别。

9.1 X-SoftAI 合规三件套（最低配置）

#	文件	内容要点	事实等级
1	`LICENSE`	保留上游 MIT 原文，不得删除或误改上游要求保留的 copyright notice 和 permission notice	MIT 许可证要求（L1 Normative Text）
2	`NOTICE`	声明基于上游开发 + 第三方依赖入口 + "AS IS" 免责	L4 Industry Practice
3	`THIRD-PARTY-NOTICES`	全部依赖许可证清单 + 对应源码获取方式	LGPL / GPL / AGPL / MPL 各许可证条款（L1 Normative Text）

9.2 `NOTICE` 草案（X-SoftAI 适用）

复制代码

X-SoftAI
Copyright (c) 2026 <X-SoftAI 版权主体>

This product is based on <上游项目名>
(<上游仓库 URL>), Copyright (c) <年份> <上游版权人>,
licensed under the MIT License. The full text of the MIT License
is distributed with this software in the file LICENSE.

This product bundles third-party software; see THIRD-PARTY-NOTICES
for the complete list of components and their licenses.

This software is provided "AS IS", without warranty of any kind.

需要明确："is based on"反映事实关系 ，不是"模糊化表达"策略。法律合规文档的价值是真实、准确的归属（truthful attribution）。

关于 AS IS 声明 ：NOTICE 中的 "AS IS" 仅属于示例性的免责声明文本，其法律效力取决于适用法、合同结构及具体产品责任安排。NOTICE 文件中的免责声明不构成对客户的完整责任限制------完整的免责与责任限制需要通过专门的 EULA / 服务条款来实现。

9.3 `THIRD-PARTY-NOTICES` 升级为 SBOM + License Decision Record / Compliance Decision Record

传统 THIRD-PARTY-NOTICES 是许可证列表 + 源码 URL 的简单映射。企业级做法是升级为 SBOM + License Decision Record，字段集应包含：

字段	说明
Component	包名（与 package manager 一致）
Version	精确版本（不是 version range）
Package URL (PURL)	唯一 URI 标识（pkg:pypi/xxx@1.2.3）
SPDX License Expression	如 `MPL-2.0 AND (Apache-2.0 OR MIT)`
Copyright	上游版权声明
Source URL	精确版本对应的 source archive URL
Binary Artifact Hash	wheel / deb 的 SHA256
Source Artifact Hash	source tarball 的 SHA256
Modification Status	Unmodified / Modified / Vendor
Modification Evidence	如修改，提供 patch 或 commit URL
Notice Required	是否需要随分发物附 LICENSE 文本
Source Obligation	源码义务类型与机制（如 source_availability_notice / written_offer / bundled_source）
Patent Notice	是否需要专利提示（如 Apache-2.0）
Trademark Notice	是否需要商标提示
Compliance Decision	Approved / Conditional / Blocked
Reviewer	审阅人
Approval Date	审阅日期

示例片段：

复制代码

component: psycopg
version: 3.2.3
purl: pkg:pypi/psycopg@3.2.3
spdx_expression: LGPL-3.0
copyright: "Copyright (C) 2020--2024 The Psycopg Team"
source_url: https://github.com/psycopg/psycopg/archive/refs/tags/3.2.3.tar.gz
binary_hash: <SHA256>
source_hash: <SHA256>
modification_status: Unmodified
modification_evidence: null
notice_required: true
source_obligation:
  required: true
  mechanism: library_corresponding_source
  source_scope: library
  relinking_materials: required_if_applicable
patent_notice: false
trademark_notice: false
compliance_decision: Approved
reviewer: <name>
approval_date: 2026-10-06

component: orjson
version: 3.10.7
purl: pkg:pypi/orjson@3.10.7
spdx_expression: MPL-2.0 AND (Apache-2.0 OR MIT)
copyright: "Copyright (c) ijl (2016--2024)"
source_url: https://github.com/ijl/orjson/archive/refs/tags/3.10.7.tar.gz
binary_hash: <SHA256>
source_hash: <SHA256>
modification_status: Unmodified
modification_evidence: null
notice_required: true
source_obligation:
  required: true
  mechanism: source_availability_notice
  note: "MPL §3.2 要求告知接收者如何获得 MPL 覆盖文件的 Source Code；orjson 源码可通过 PyPI / GitHub 获取"
patent_notice: false
trademark_notice: false
compliance_decision: Approved
reviewer: <name>
approval_date: 2026-10-06

特别注意 orjson 的 SPDX 表达式 ：MPL-2.0 AND (Apache-2.0 OR MIT)。这是复合表达------包内某些文件是 MPL-2.0、某些是 Apache-2.0 / MIT。不能错误地表达为单一 MPL-2.0。这是许可证扫描不能只看 package-level license 名称的一个典型例子。

高风险依赖决策示例（PyMuPDF）：

以下是一个完整的 License Decision Record (LDR) 示例，展示了对高风险依赖的完整决策过程。这是企业级 OSS Compliance 与"许可证清单"的核心区别。

复制代码

component: pymupdf
version: 1.28.2
purl: pkg:pypi/pymupdf@1.28.2

license:
  spdx_expression: AGPL-3.0-only
  licensing_model: dual-license
  commercial_option:
    available: true
    vendor: Artifex
    acquired: false
  source: upstream-COPYING

usage:
  mode: runtime-library
  modified: true  # X-SoftAI 修改了 PyMuPDF 以适配 OCR 管线
  distributed: true  # 镜像交付
  saas: true  # 对客 SaaS 提供远程交互
  customer_receives_copy: true
  linkage: imported_and_called_in_app  # 在应用代码中直接调用 API

risk:
  category: commercial-dual-license
  license_risk: R4     # AGPL + 修改 + SaaS + 分发
  provenance_risk: R1  # 来源清晰（PyMuPDF 官方）
  patent_assessment:
    status: not_assessed
    note: "本文示例不进行具体专利权利要求比对，因此不预设 Patent Risk 等级"
  contract_risk: R2    # 商业许可取得与合同范围需要进一步确认
  overall_severity: R4
  uncertainty: U1
  reason: |
    PyMuPDF 采用 AGPL-3.0 / 商业双许可结构。
    X-SoftAI 修改了 PyMuPDF 并通过 SaaS 提供远程交互，
    触发 AGPL §13 额外源码提供义务；
    同时镜像分发触发 GPL §6 conveying 义务。
    由于 X-SoftAI 为闭源商业产品，
    直接使用 AGPL 版存在显著合规风险。

decision:
  action: replace
  replacement: pypdfium2
  replacement_license: Apache-2.0 / BSD-3-Clause
  replacement_review_note: |
    pypdfium2 自身采用宽松许可，但其 wheel 与构建产物
    包含 PDFium 及其他第三方依赖，需单独审查传递依赖闭包。

evidence:
  sbom_sha256: <SHA256 of SBOM entry>
  source_url: https://github.com/pymupdf/PyMuPDF/archive/refs/tags/1.28.2.tar.gz
  scan_report: <ScanCode report reference>
  modification_evidence: <patch file / commit reference>
  reviewer: <name / title>
  approval_date: 2026-10-06

LDR 的价值：它记录的不只是"这个包是什么许可证"，而是"我们为什么这样决策、基于哪些事实、由谁批准"。这是企业级合规审计的核心文档。

9.3.1 从 LDR 扩展到 Compliance Decision Record（CDR）

LDR 主要记录许可证层面的事实与判断 。当企业同时评估 Provenance、Patent、Contract、Jurisdiction 等因素时，建议在 LDR 之上形成统一的 Compliance Decision Record（CDR）。

复制代码

component: pymupdf
version: 1.28.2
purl: pkg:pypi/pymupdf@1.28.2

license_decision:
  spdx_expression: AGPL-3.0-only
  licensing_model: dual-license
  commercial_option:
    available: true
    vendor: Artifex
    acquired: false

risk:
  license: R4
  provenance: R1
  patent: not_assessed
  contract: R2

uncertainty:
  level: U1
  reason: "商业许可范围与具体专利风险尚未完成专项审查"

decision:
  action: replace
  replacement: pypdfium2

evidence:
  sbom: <SBOM reference>
  license_scan: <ScanCode / ORT reference>
  source_artifact: <SHA256>
  modification_evidence: <patch / commit reference>

review:
  reviewer: <name>
  date: 2026-10-06

这里应明确区分：LDR 是许可证决策记录；CDR 是跨 OSS / IP / Contract 的最终合规决策记录。两者都属于企业治理证据，不等同于法律意见。

9.4 配套源码获取通道声明页（独立网页）

复制代码

page_id: X-SoftAI-third-party-source-access
effective_version: X-SoftAI v<版本号>
last_updated: 2026-10-06
product: X-SoftAI
sla_days: 30  # X-SoftAI 企业响应 SLA，不是 GPL/AGPL 统一法定期限

content:
  description: |
    X-SoftAI 在分发时附带的 LGPL / MPL / GPL / AGPL 依赖，
    按各许可证及具体分发方式分别记录其源码获取机制。可能包括：

    1. 随 X-SoftAI 镜像一同打包的 /app/third_party_sources/ 目录；
    2. 上游开源仓库或公司镜像（见 THIRD-PARTY-NOTICES 中的 Source URL 字段，
       指向精确版本，不指向 master）；
    3. 在相应许可证及 conveying 方式允许/要求时，提供书面要约及指定联系方式。

    具体机制以每个组件的 Compliance Decision Record 为准。

    本声明对应 X-SoftAI v<版本号>及后续版本。
    历史版本的对应源码可应要求提供。

retention_policy:
  notice: |
    本页面按照企业产品生命周期政策长期归档，并在适用许可证要求的期限内持续保留相应版本的源码获取信息；企业保留政策不得替代许可证本身规定的期限与方式。

需要明确："30 天"是 X-SoftAI 自定的企业 SLA ，不是 GPL/AGPL 的法定期限。GPLv3 §6 对"physical product"的书面要约明确要求"至少三年内有效"；AGPL §13 对网络提供源码的方式另有规定。X-SoftAI 选择 30 天可根据风险偏好延长，但不能表述为"GPL/AGPL 要求 30 天"。

9.5 CI 准入卡口：从单命令升级到 Policy Engine

原文给出的 CI 示例使用 pip-licenses --ignore-packages="^"。需要明确两个问题：

--ignore-packages="^" 中的正则 ^ 匹配字符串开头，可能导致所有包名都被该正则匹配而跳过，与"扫描全部依赖"的初衷冲突。
企业级 OSS Compliance 不应只依赖一个简单的 license scanner 。pip-licenses 适合作为 Python package license inventory，不能作为独立防线。

推荐的工程做法：

复制代码

Developer / AI Agent
  │
  ▼
Code / Dependency Change
  │
  ▼
SBOM Generation
(Syft / CycloneDX)
  │
  ▼
License Analysis
(ScanCode / ORT)
  │
  ▼
Policy Evaluation
- AGPL/GPL → Blocked
- LGPL/MPL → Notice
- Permit → Auto-pass
  │
  ▼
Compliance DB (Record)
  │
  ▼
Release Gate

可选择的工具：

工具	类别	适用场景
ScanCode Toolkit	License + Copyright 扫描	全语言、License 解析与匹配
OSS Review Toolkit (ORT)	依赖 + License + Vulnerability	多语言策略化
FOSSology	License 识别 + 文本扫描	大批量 SPDX 处理
Syft + Grype	SBOM + Vulnerability	与 SBOM 生态深度集成
CycloneDX / SPDX	SBOM 标准	用于交付交换
pip-licenses / license-checker	Python 包 license 快速检索	出口供 L4 交叉验证

L4 工程控制：

预提交钩子：在 commit 时调用 Syft 生成 SBOM，调用 ScanCode 扫描 License，对 Blocked 类（AGPL/GPL）拒绝提交；
CI 卡口：PR 合并前生成完整 SBOM，调用 Policy Engine 验证决策；任何新增组件必须含 Compliance Reviewer 字段；
周期性 audit：每个 release cycle 重新生成 SBOM，与上一周期对比差异，验证所有 Approved 项仍然成立。

原 pip-licenses 示例的修订版本（仅作最小示例，不替代上述架构）：

复制代码

# 明确列出所有依赖的 License
pip-licenses --format=json \
  --with-license-file \
  > licenses.json

# 与 SBOM 生成可交叉验证
syft packages . -X generated SBOM -o json=sbom.json

原文示例中的 --ignore-packages="^" 与 --fail-on= 组合不应该直接使用 ，避免重蹈"^ 匹配了所有包"的覆盖问题。

9.6 pypdfium2 的传递依赖闭包审查

原文所述 pypdfium2 作为 PyMuPDF 的替代方案，需要明确：

pypdfium2 项目本身采用 Apache-2.0 / BSD-3-Clause；
但其 wheel 与构建产物包含 PDFium（上游 PDFium 项目采用 Apache-2.0）以及若干第三方依赖；
这些传递依赖不是简单的"BSD-3-Clause 一句话能说清"。PyMuPDF 这类"AGPL + 商业双许可"包不是简单地把名字替换就能"变干净"------它的下游交付物仍须完整合规审查。

Compliance Record 动作：

拉出 pypdfium2 的传递依赖闭包（pipdeptree / pip-licenses --with-system / Syft）；
对每一个依赖记录到 SBOM 中（不遗漏）；
评估每一个依赖的 License；
对 Apache-2.0、BSD、MIT 这类许可采取声明与署名策略；
对不在该清单内的 License（例如某种商业 / GPL）触发 Compliance Review。

十、面向商业化的工程治理建议

本章事实等级 ：六条治理建议整体属 L5 Engineering Control------它们是为了在 Vibe Coding 场景下降低未来争议成本的预防性投资，不是许可证法定的逐项强制义务。

综合前九章的讨论，我把 X-SoftAI 在面向商业化时沉淀的工程治理建议汇总为六条。本章先在 10.1 给出三轨合规模型的整体骨架，然后逐条治理建议展开。

10.0 三轨合规模型：AI Software Legal Governance

Vibe Coding 商业化下的合规工作应当把"开源许可证合规"与"商业合同合规"分清楚------前者是 OSS License Compliance，后者是 Contract / IP Compliance。下图给出三轨分立的骨架：

复制代码

                AI Software Legal Governance
                       │
       ┌───────────────┼───────────────┐
       │               │               │
   OSS Compliance   IP Compliance   Contract Compliance
       │               │               │
   License          Copyright       EULA
   Attribution      Trademark       SLA
   Notice           Patent          DPA
   SBOM             Trade Secret    TOS
                       │
                       ▼
                 Customer-facing
                  legal surface

OSS Compliance 轨：处理 LGPL / GPL / AGPL / MPL / MIT / Apache-2.0 等许可证的义务；
IP Compliance 轨：处理商标、专利、商业外观等知识产权层面的边界；
Contract Compliance 轨：处理 EULA / 服务条款 / DPA / SLA / TOS 等合同性文件。

说明：三轨是治理责任域的划分，不代表法律问题之间完全没有交叉。例如，商标使用限制既可能来自 IP 法（IP Compliance），也可能通过合同条款体现（Contract Compliance）；版权声明既是 OSS 许可义务，也可能出现在对客合同中。三轨模型的价值在于确保不同类型的合规责任都有对应的治理流程，而不是将法律问题硬性切割。

Vibe Coding 商业化的合规工作 = OSS Compliance × IP Compliance × Contract Compliance，三者不可压缩。原文的问题之一是把 OSS 合规与合同合规混在一起讨论，本节专门拆开。

10.1 把"许可扫描"做成 CI 卡口，不要停留在"手动检查"

手动检查 = grep LICENSE 是不可持续的。X-SoftAI 的实践是：

预提交钩子：在 commit 时调用 Syft 生成 SBOM，调用 ScanCode 扫描 License，对 Blocked 类（AGPL/GPL）拒绝提交；
CI 卡口：PR 合并前生成完整 SBOM，调用 Policy Engine 验证决策；任何新增组件必须含 Compliance Reviewer 字段；
策略化：把"AGPL-3.0 / GPL-3.0 / GPL-2.0"列为"必须 fail"，把 LGPL / MPL 列为"需声明"。

详细工具链与设计见 §9.5。

10.2 把"对应源码可得性"做成长期兜底

LGPL / GPL / AGPL 的"提供对应源码"义务没有时效豁免------历史版本仍在客户侧运行时仍有效。X-SoftAI 的实践是：

配套源码获取通道声明页长期挂网，不随版本下线而撤除；
每个版本的第三方源码 tarball在适用许可证要求的期限内持续保留，并按照企业产品生命周期政策进行长期归档；
邮件 / 工单渠道保留长期监听；
内部合规周期：每年复检一次 THIRD-PARTY-NOTICES 与归档状态。

区分：法律义务的期限（如 GPLv3 书面要约的"至少三年"）与企业内部的归档保留政策是两件事。企业可以选择比法定期限更长的保留策略，但法定期限是底线。

10.3 把"Vibe Coding 输入审计"做成开发规范

Vibe Coding 工作流引入新依赖时，开发者的一句 prompt 就可能让代理引入 AGPL 包。X-SoftAI 的实践是：

任何 "use xxx to do yyy " 类 prompt 在生成代码后立即触发许可扫描；
任何 prompt 引入新第三方包时必须显式声明"已确认其许可"------可以在 PR 模板里加一个 checkbox；
在 AGENTS.md（项目级 AI 协作规范）中明示"代理不得未经人类确认引入任何 AGPL/GPL 包"------这是把"合规规则"嵌入开发规范的一种形式。

注意：这是 L5 Engineering Control ，不是许可证的强制义务------但合理的工程干预性投资。

10.4 把"商标边界"做成文档基线

X-SoftAI 在 README、EULA、官网、UI 文案中不使用任何上游项目标识。工程上的做法是：

在 docs/branding.md 中维护"X-SoftAI 自有标识清单"------logo、配色、产品名、UI 文案；
任何 PR 涉及 README / EULA / 官网文案时必须经过人工 review------这是 Vibe Coding 难以替代的人类判断点；
每年由品牌负责人做一次"上游品牌是否变更"的复检------以应对上游项目改名 / 换 logo 等场景。

10.5 把"AI 生成代码的合规审查"做成审阅规范

LLM 生成代码进入交付物之前，X-SoftAI 的实践是：

相似度扫描：对每个 LLM 生成的代码段做"已知开源项目相似度"扫描；具体工具选择见 §8.4；scc / CodeQL 不是这个场景的工具。
人工 review 不可替代 ：高相似度片段必须进入 Provenance Review：根据证据判断来源；如果无法确认独立来源，不得仅通过声明认定其独立，应按实际来源进行许可证审查、移除或重写；
审阅记录留痕：在 PR 模板中保留"AI 生成代码已人工审阅"的勾选项与审阅者署名。

10.6 把"客户侧合同"与"技术合规"配套

合规不只是技术问题，最终落地需要 EULA 与服务条款。X-SoftAI 在客户侧合同里至少需要明示：

X-SoftAI 配套第三方源码获取通道的访问方式；
条款应采用范围限定的方式："在适用开源许可证所允许的范围内，反向工程不受本协议禁止"，避免全面禁止反向工程与 LGPL / GPL 冲突；
X-SoftAI 的"AS IS"条款及其责任限制范围（其效力仍受适用法律及具体合同约束）；
隐私政策与数据处理条款（与 GDPR / PIPL 等法规对齐）。

10.7 一个新理念：Dependency ≠ License Risk

传统许可证合规思路：

复制代码

Dependency
 ↓
Risk

这是错误的。过简风险模型实际上在企业项目中是个隐含安全错误：许可证风险不是 package 的属性，而是 package + version + usage mode + modification + distribution 的联合函数。

更严谨的判定函数是：

复制代码

Risk = f(
    Jurisdiction,          # 适用法域（US / EU / CN / JP 等）
    Component,             # 包名
    Version,               # 精确版本
    SPDX Expression,       # 许可证表达式（包含 MPL AND Apache 这种复合表达）
    Usage Mode,            # 静态/动态链接、过程边界、API 边界
    Modification,          # 是否修改过包内文件
    Link / Combine,        # 是基于本程序的 covered work 还是 aggregate
    Distribution,          # 是否作为 object code 分发
    SaaS Interaction,      # 是否通过网络提供远程交互
    Customer Receives,     # 客户是否收到复制件
    Trademark,             # 是否涉及上游商标
    Patent,                # 是否涉及上游专利
    Contract,              # 与供应商/客户的合同限制
)

这个函数包含 13 个变量。任何一个变量的变动都可能改变最终的风险等级。例如：

PyMuPDF 在 "interactive use, no modification" 的条件下风险较低；
PyMuPDF 在 "modify + SaaS" 的条件下是高风险；
同一依赖在不同法域（如美国 vs. 中国）下的版权、专利、反向工程、数据合规等义务并不完全相同；
你可以不承担所有变量都不修改，但需要逐项评估。

这与本文反复强调的 事实等级分层是一贯的。

10.8 Risk-adaptive Compliance Matrix

X-SoftAI 实践中的风险自适应矩阵采用多维风险模型 ，而不是"许可证名称 → 单一风险等级"的机械映射。这与 §10.7 提出的 Dependency ≠ License Risk 判定函数一致：风险由 License + Usage Context + Jurisdiction 等多个维度联合决定，不是 package 的固有属性；同时，Risk Severity 与 Legal Uncertainty 不是同一维度。

每个依赖的风险评估按四个维度分别评级：

风险维度	评估内容	典型触发条件
License Risk	开源许可证义务强度	Permissive / MPL / LGPL / GPL / AGPL / Commercial + 修改 + 分发 + SaaS 交互
Provenance Risk	代码来源不确定性	AI 生成代码与已知 OSS 相似性、来源不明、可能的复制
Patent Risk	第三方专利侵权可能性	算法密集型代码、标准必要专利、已知专利持有方依赖
Contract Risk	合同约束与合规成本	EULA 限制、供应商条款、对客责任、跨境许可

各维度分别评级。R0--R4 表示风险严重度，U0--U3 表示法律/事实不确定性；最终处置动作由风险严重度、触发条件和不确定性共同决定：

其中建议采用以下不确定性等级：

Uncertainty	含义	典型状态
U0	已充分确认	许可证、版本、使用方式、来源及相关证据均明确
U1	轻度不确定	个别事实尚待补证，但不影响当前工程处置
U2	重大不确定	关键事实、作品边界、来源或法律解释尚未收敛
U3	高度不确定	新兴法律问题或关键事实无法确认，必须升级法务

复制代码

risk:
  license:    R3   ← 最高维度，决定 Compliance Gate
  provenance: R1
  patent:     R2
  contract:   R1
     ↓
overall_action: Compliance Gate

各风险等级的含义与处置动作：

Risk Level	含义	典型触发条件	处置动作
R0	无实质风险	Permissive + 未修改 + 署名满足 + 来源清晰	Auto Pass（自动通过）
R1	低风险，可自动处理	Attribution / Notice / Patent Notice 义务；来源基本清晰	Notice Required（补充声明与记录）
R2	中风险，需许可审查	MPL 修改覆盖文件 / LGPL Combined Work / 专利可能性中等	License Review + Source Obligation（许可审查与源码义务）
R3	高风险，需合规闸门	GPL Covered Work / AGPL §13 条件满足 / 未取得必要商业许可的双许可场景	Compliance Gate（合规闸门，需人工决策）
R4	严重风险，需阻断或法务	商业-only 许可但未取得授权 / 许可证不兼容 / 高严重度合规缺口	Block / Purchase / Legal Review（阻断或采购或法务审查）

矩阵的使用流程：

复制代码

Dependency detected
      ↓
License Identification  →  License Risk (R0-R4)
Usage Context Analysis  →  调整 License Risk
Modification / Distrib. →  调整 License Risk
      ↓
Provenance Assessment   →  Provenance Risk (R0-R4)
      ↓
Patent Assessment       →  Patent Risk (R0-R4)
      ↓
Contract Assessment     →  Contract Risk (R0-R4)
      ↓
Risk Severity + Uncertainty → Overall Decision
      ↓
Appropriate Action

核心原则：

License Scanner 是证据生成器，不是法律决策器 --- 扫描工具只能告诉你"这个包的许可证表达式是什么"，不能直接告诉你"风险等级是多少"。
SBOM ≠ Compliance Decision --- SBOM 只能告诉你"我有什么"，合规决策还需要知道 "How Used / Modified? / Distributed? / SaaS? / Combined? / Jurisdiction?"。
Artifact Identity ≠ Legal Characterization --- 制品身份一致性（如哈希匹配）是工程证据，不是法律关系认定。
Risk ≠ Legal Uncertainty --- 风险严重度描述潜在影响与处置强度；法律/事实不确定性描述证据或法律状态是否收敛，两者应分开记录。

这个设计与第五章、第八章的风险分级是一致的。后续合规人员阅读本文时，可从任意一个 Risk Severity 或 Uncertainty 状态追溯其背后的事实、触发条件与法律依据。

结论

回到本文开头的问题------Vibe Coding 利用开源软件生成商业软件时，法律与风险的核心是什么？

本文最终定位为：

"Vibe Coding 场景下的开源软件合规工程治理指南"

而不是严格意义上的：

"Vibe Coding 利用开源软件生成商业软件的法律分析"

这两个定位的区别在于：前者是企业工程治理 的视角，后者是严格法律分析 的视角。本文的产出价值在于前者。后面这个定位在几个关键点上仍处于 L6 Legal Uncertainty（例如 "LLM 训练 GPL → 输出 GPL 衍生作品" 的逻辑链），不能作为确定性结论呈现。

三大拆解是本文最重要的理论贡献：

拆开事实等级（L1~L6）：区分许可证原文事实、权威解释、行业实践、工程控制、未明确定性。
拆开三轨合规（OSS / IP / Contract）：把许可证合规与商业合同合规、知识产权合规分轨。
拆开五件事（Copyrightability / Infringement / License / Contract / Patent）：针对 AI 生成代码，把这五件事拆开处理。

Risk-adaptive Compliance Matrix 与 Dependency ≠ License Risk 的判定函数是对原始文章的体系升级------把"许可证风险 = package 属性"的过简模型升级为联合函数。

最终架构

复制代码

            ┌───────────────────────────────────┐
            │  AI Software Legal Governance     │
            └────────────────┬──────────────────┘
                             │
       ┌─────────────────────┼─────────────────────┐
       │                     │                     │
   OSS Compliance        IP Compliance         Contract Compliance
       │                     │                     │
   ┌───┴────┐           ┌────┴────────┐          ┌────┴──────────┐
   │License │           │Copyright     │          │EULA / DPA / TOS│
   │SBOM    │           │Trademark     │          │SLA / Notice    │
   │Source Access│           │Patent        │          │Trademark Notice│
   │        │           │Trade Secret  │          │Privacy         │
   └───┬────┘           └────┬────────┘          └────┬──────────┘
       │                     │                     │
       └─────────────────────┼─────────────────────┘
                             │
            ┌────────────────┴────────────────┐
            │  Vibe Coding Pipeline           │
            │  ┌────────────────────────┐     │
            │  │ Developer / AI Agent  │     │
            │  └───────────┬────────────┘     │
            │              ▼                  │
            │  ┌────────────────────────┐     │
            │  │ Prompt Audit Hook      │     │
            │  └───────────┬────────────┘     │
            │              ▼                  │
            │  ┌────────────────────────┐     │
            │  │ Dependency Scan + SBOM │     │
            │  └───────────┬────────────┘     │
            │              ▼                  │
            │  ┌────────────────────────┐     │
            │  │ License Analysis + SPDX│     │
            │  └───────────┬────────────┘     │
            │              ▼                  │
            │  ┌────────────────────────┐     │
            │  │ Risk Decision    │
            │  │ R0 / R1 / R2 / R3 / R4 │     │
            │  └───────────┬────────────┘     │
            │              ▼                  │
            │  ┌────────────────────────┐     │
            │  │ Release Gate           │     │
            │  └────────────────────────┘     │
            └─────────────────────────────────┘

最后一句话：合规不是法律的胜利，是治理的胜利。但这种治理的价值在于"在区分事实等级 / 区分三轨合规 / 区分五件事"的基础上表达，不是把"工程做法"写成"许可证强制"。

本文不构成法律意见。涉及商标、合同、对客条款、跨境许可的部分，请在正式商业化前由专业法务复核。本文聚焦工程实现视角的合规梳理，所有示例（X-SoftAI / 某上游项目 / PyMuPDF / pypdfium2 等）均为方法论演示，请按你实际产品情况调整。

附录：本文使用的工具 / 仓库 / 资源集

为便于读者在项目中落地，本文提供的工具与资源总表：

类别	名称	用途	说明
SBOM 生成	Syft	生成 CycloneDX / SPDX SBOM	GitHub - anchore/syft: CLI tool and library for generating a Software Bill of Materials from container images and filesystems · GitHub
SBOM 标准	CycloneDX	CycloneDX SBOM 标准	https://cyclonedx.org
SBOM 标准	SPDX	SPDX SBOM 标准	SPDX -- Linux Foundation Projects Site
License 扫描	ScanCode Toolkit	License + Copyright 文本扫描与匹配	GitHub - aboutcode-org/scancode-toolkit: :mag: ScanCode detects licenses, copyrights, dependencies by "scanning code" ... to discover and inventory open source and third-party packages used in your code. Sponsored by NLnet, the Google Summer of Code, Azure credits, nexB and other generous sponsors! · GitHub
License 策略	OSS Review Toolkit (ORT)	多语言依赖分析 + License 策略化	GitHub - oss-review-toolkit/ort: A suite of tools to automate software compliance checks. · GitHub
License 合规系统	FOSSology	大规模许可证识别、分析与合规管理	FOSSology
Python 包 License	pip-licenses	Python 包 License 快速检索	GitHub - raimon49/pip-licenses: Dump the license list of packages installed with pip. · GitHub
npm 包 License	license-checker	npm 包 License 快速检索	GitHub - davglass/license-checker: Check NPM package licenses · GitHub
Dependency tree	pipdeptree	Python 传递依赖分析	GitHub - tox-dev/pipdeptree: A command line utility to display dependency tree of the installed Python packages · GitHub
CVE / 漏洞扫描	Grype	SBOM 漏洞扫描	GitHub - anchore/grype: A vulnerability scanner for container images and filesystems · GitHub
Source Provenance / Archive	Software Heritage	源代码归档与来源基础设施	https://www.softwareheritage.org
SPDX 表达式	SPDX License List	SPDX 许可证列表与表达式查询	https://spdx.org/licenses
法律参考	GNU Licenses	GPL/LGPL/AGPL 文本与 FAQ	https://www.gnu.org/licenses
法律参考	Mozilla MPL-2.0	MPL-2.0 文本与 FAQ	Mozilla Public License, version 2.0
法律参考	Apache-2.0	Apache 许可证文本与 FAQ	https://www.apache.org/licenses/LICENSE-2.0
US Copyright Office	Part 2: Copyrightability	AI 输出可版权性指导	[Copyright and Artificial Intelligence \| U.S. Copyright Office](https://www.copyright.gov/ai/ "Copyright and Artificial Intelligence
司法案例	Doe v. GitHub (9th Cir. 2026)	DMCA §1202(b) 相关判决	Ninth Circuit 2026-09-16 判决

Vibe Coding 时代的 OSS Compliance Engineering：从许可证识别到 AI-Native 软件供应链治理

目录

一、Vibe Coding 与开源依赖的交叉地带

二、商业闭源场景下的开源许可证义务光谱

2.1 光谱分类

2.2 一条易踩的误区：把"光谱"读成"传染程度"

2.3 事实等级约定（贯穿全文使用）

三、案例剖析：X-SoftAI 的合规盲区

3.1 X-SoftAI 的产品定位与依赖图

3.2 第一道盲区：把"MIT 自带免责"等同于"商业免责"

3.3 第二道盲区：把"打包进容器"当成"内部分发"

3.4 第三道盲区：把"动态链接"等同于"无传染"

3.5 第四道盲区：把"未修改"等同于"无义务"

四、强 copyleft 高风险项：以 PyMuPDF 双许可为镜

4.1 AGPL-3.0 的法理结构

4.2 Corresponding Source 的边界

4.3 关于"Docker 镜像 = 一个 GPL 作品"

4.4 PyMuPDF 的商业决策与三种处置路径

4.5 路径 A 的工程实施清单

4.6 一个常被忽视的"历史版本"问题

五、弱 copyleft 的"声明义务"陷阱

5.1 LGPL 系包：动态链接不是唯一合规路径

5.2 LGPL-3.0 §4 的反向工程条款

5.3 MPL-2.0 的文件级机制与 SPDX 表达式

5.4 一个 Vibe Coding 专属的新增面

六、商标与品牌：MIT 不授权商标

6.1 MIT License 的授权范围

6.2 NOTICE 中的措辞：Truthful Attribution 是关键

6.3 商标与"上游项目未来行动"的关系

七、源码可得性：从理论声明到工程闭环

7.1 Corresponding Source 的边界（按 GPL §1 原文定义）

7.2 "提供源码"的工程形态与许可证差异

7.3 几个常见的工程误解

7.4 镜像交付物里的"源码获取通道"声明页

八、AI 生成代码的额外不确定性

8.1 Copyrightability：US Copyright Office 2025 Part 2

8.2 Copyright Infringement：Doe v. GitHub 最新进展

8.3 License Obligation：训练语料继承问题

8.4 工程上的风险治理动作

8.5 Patent Risk：AI 生成代码与第三方专利权利要求

8.6 小结：三个拆开的点

九、可直接复用的合规清单与声明草案

9.1 X-SoftAI 合规三件套（最低配置）

9.2 NOTICE 草案（X-SoftAI 适用）

9.3 THIRD-PARTY-NOTICES 升级为 SBOM + License Decision Record / Compliance Decision Record

9.3.1 从 LDR 扩展到 Compliance Decision Record（CDR）

9.4 配套源码获取通道声明页（独立网页）

9.5 CI 准入卡口：从单命令升级到 Policy Engine

9.6 pypdfium2 的传递依赖闭包审查

十、面向商业化的工程治理建议

10.0 三轨合规模型：AI Software Legal Governance

10.1 把"许可扫描"做成 CI 卡口，不要停留在"手动检查"

10.2 把"对应源码可得性"做成长期兜底

10.3 把"Vibe Coding 输入审计"做成开发规范

10.4 把"商标边界"做成文档基线

10.5 把"AI 生成代码的合规审查"做成审阅规范

10.6 把"客户侧合同"与"技术合规"配套

10.7 一个新理念：Dependency ≠ License Risk

10.8 Risk-adaptive Compliance Matrix

结论

最终架构

附录 ：本文使用的工具 / 仓库 / 资源集

9.2 `NOTICE` 草案（X-SoftAI 适用）

9.3 `THIRD-PARTY-NOTICES` 升级为 SBOM + License Decision Record / Compliance Decision Record

附录：本文使用的工具 / 仓库 / 资源集