M02 开源合规

● 完整 合规 v0.6 · 更新于 2026-10-29

给谁用

使用开源组件的软件公司——尤其是对外宣称「开源」但商业版为专有许可的公司

解决什么问题

组件来源、许可证义务和闭源分发条件缺少可追溯记录时，发布与尽调难以核验

组件清单

• 判断树
• 表单模板
• 条款库（不适用）
• 落地 SOP
• 适用边界

可下载内容

详细说明

开源合规不是给每个组件贴一个「安全／危险」标签，而是把具体组件、具体许可证版本、具体使用行为对应起来：有没有向其他主体交付副本、有没有修改、有没有远程网络交互、以什么方式组合或链接。同一许可证在不同行为下义务不同；同一产品里，不同模块也可能适用不同许可证。本模块的顺序是：先固定事实，再判断触发条件，最后落实可验证的动作和证据。

判断树（先看行为，再看许可证）

0 固定事实：组件、精确版本/提交、许可证表达式、包内 LICENSE/NOTICE、实际使用方式
│
├─ 1 是否选择了商业许可或其他替代授权路径？
│   ├─ 是 → 记录授权文件、覆盖版本与模块；仍核对实际带入的第三方组件许可
│   └─ 否 → 按开源许可证继续分析
│
├─ 2 是否向其他主体交付副本？
│   （安装包、容器镜像、SDK、设备、源码包、浏览器脚本、WASM 均可能是副本）
│   ├─ 是 → 交付/分发成立：核对许可证副本、声明、NOTICE、源码交付方式
│   └─ 否 → 记录主体边界；关联公司、外包、客户现场部署需单独判断
│
├─ 3 是否修改组件？
│   （补丁、改配置生成代码、把组件代码并入自有代码都可能是修改）
│   ├─ 是 → 记录修改文件、日期、对外说明；再判断修改版是否被交付
│   └─ 否 → 仍要判断组合作品和声明义务
│
├─ 4 是否存在远程网络交互？
│   （用户通过网络使用服务，即使不下载任何副本）
│   ├─ 是 → 检查 AGPLv3 §13、服务条款及浏览器端交付物
│   └─ 否 → 网络交互源码义务不适用
│
└─ 5 组合或链接方式是什么？
    （独立进程、IPC、动态链接、静态链接、源码嵌入、聚合、容器镜像）
    ├─ 记录实际方式、调用关系和依据，不按单一标签直接下结论
    └─ 形成结论：许可证路径＋受约束范围＋履行动作＋证据＋未完成条件

第 2 问和第 4 问可以同时成立：一个产品可以同时向客户交付安装包，又让客户通过网络使用服务。交付、修改、网络交互是三条可以同时成立的事实轴。反之，仅在公司同一法人内部运行、没有对外交付副本，通常不触发 GPL 系许可证的分发条件；但把副本交给关联公司、外包商或客户，就可能构成向其他主体交付。

先分清三个概念

修改本身不当然产生「再许可义务」。 GPLv3 允许在不对外交付副本时运行和修改（§0、§2）；AGPLv3 则在「修改＋远程网络交互」时直接触发 §13 的源码提供义务；LGPL 的义务主要落在分发库或组合作品时。是否公开、公开到什么范围，取决于许可证版本、交付行为和网络交互，而不是「改没改」这一个事实。

同样，「静态链接、动态链接、IPC 是否构成衍生作品」在不同许可证和不同法域下并非一句话可以定论。本模块不把「动态链接＝安全」「IPC＝不传染」写成规则，而要求在审批表和 SBOM 中记录实际组合方式、调用关系、许可证版本和分析依据；结论不明确时升级法务审查，不用标签替代分析。

许可证义务矩阵

许可证类别只说明许可证的典型机制，不等于使用场景的风险等级。GPL 系组件可以用于商业产品，关键在是否满足对应版本的条件；Apache-2.0、MIT 也不是「只留版权声明」这么简单。下表按许可证逐行列出触发条件与动作，详细条款以来源记录中的官方文本为准。

宽松许可（MIT／BSD／Apache-2.0）

Apache-2.0 分发要逐项核对 §4(a)—(d)：

1. §4(a) 许可证副本：每个接收 Work 或 Derivative Works 的主体都要拿到 Apache-2.0 文本，目标码分发也一样。
2. §4(b) 修改标识：修改过的文件要有显著通知，说明你改过；不要只改代码不留言。
3. §4(c) 声明保留：在分发的源码形式中保留版权、专利、商标和署名声明，剔除与衍生作品无关的部分。
4. §4(d) NOTICE：上游分发中包含 NOTICE 时，衍生产品要在 NOTICE 文件、源码或文档、或产品展示中放入其中相关的署名；可以追加自己的署名，但不得改动许可证。
5. §3 专利与 §6 商标：不要把专利授权当成无条件永久安全；也不要用上游商标做产品背书。

Copyleft（GPL／LGPL／AGPL）

GPLv2 与 GPLv3 不能混用

不要用 GPLv3 的「网络交互不构成 conveying」去解释 GPLv2，也不要把 GPLv3 的 Installation Information 要求套到 GPLv2。 版本不同，条款和履行方式不同。

Qt／PySide6 的三条路径

Qt 的商业许可与开源许可并行。开源侧的主许可证是 LGPLv3，但不是整个 Qt 都只有 LGPL：部分模块只提供 GPL，LGPL 部分通常也可按 GPL 使用；商业路径须按实际所购产品的模块授权范围核对。判断时必须落到具体 Qt 版本、具体模块和实际包来源，不能把「Qt」当成一个许可证。

Qt 官方明确：LGPL 路径下可以保持应用源码闭源，前提是满足 LGPLv3 的全部要求；部分模块只提供 GPL，使用这些模块会要求应用整体按 GPL 处理。Qt 还说明，分发 LGPL 库时源码即使未修改也要提供，用户应能修改并重链接库（包括反向工程），LGPLv3 §4(e) 在 GPLv3 §6 所定情形要求安装信息，需按 User Product 交易、修改版安装能力及例外逐项判断，封闭设备尤其需要审查。第三方组件仍按各自许可证处理，Qt 6.8 起还提供 SPDX 2.3 格式的第三方组件 SBOM。

Qt 核对顺序：

1. 以产品实际使用的 Qt／PySide6 版本为准，列出模块清单，而不是只看安装包名称。
2. 逐模块查 Qt Licensing 页面和对应版本文档，确认该模块是 LGPL、GPL 还是仅商业。
3. 区分社区包与商业包来源：商业用户不应通过 pip install pyside6 安装社区版；商业 wheel 的获取方式、LTS 版本和模块覆盖要写进审批表。
4. 核对 Qt for Python 第三方许可页面及包内 NOTICE，确认实际带入的组件及其独立义务。
5. 购买商业许可后，不再机械套用未触发的 LGPL 条件，但仍要检查商业授权覆盖的版本、模块、包来源和第三方许可。

表单、台账与发布清单如何关联

三份材料分工不同，不能互相替代：

建议的编号规则（内部管理建议，可按公司习惯调整）：

• 组件 ID：CMP-<产品简称>-<四位序号>，同一组件换版本时保留 ID，在版本列记录新版本；同一产品并存多版本时分别登记，每行以组件 ID＋组件版本／提交＋产品版本识别。
• 审批单 ID：APR-<产品简称>-<产品版本>-<两位序号>；一个审批单可以覆盖同一使用方式下的一组组件，但必须列明组件 ID。
• SBOM 版本：SBOM-<产品简称>-<产品版本>-<修订号>；发布时冻结，不原地覆盖。
• 发布清单：REL-<产品简称>-<产品版本>；附条件通过的条件必须在清单中逐条关闭。

最小追溯链：产品版本 → SBOM 行（组件 ID）→ 审批单（APR ID）→ 发布清单证据位置 → 实际发布产物。任何一环缺失，都不能以「SBOM 已标已审批」代替发布产物核验。

落地 SOP

以下审批层级、复查频率和工具选择是内部管理建议，不是许可证义务；公司可以按依赖变动和实际使用场景简化，但不能省略对触发事实和证据的记录。

内部审批分层建议（不是许可证义务，按公司授权体系调整）：

工具可以辅助生成依赖清单（如 Syft、Trivy），但工具输出只是底账，不替代许可证文本核对和使用事实判断。本模块不要求在 CI 中建设自动法律门禁。

许可义务与沟通话术

本模块的约束来自许可证条款本身，不是另行谈判出来的标准合同条款，因此不另造一套通用合同条款库；需要合同文本时用 M01，需要商业软件许可条款时用 M03。下面三组话术用于把许可证义务落成可核对的事实和动作，属于内部管理建议，不是法律意见；对外承诺前仍由法务复核。

向研发收集事实（首次登记或变更时）

请按组件逐个确认：①名称、精确版本或提交号、下载来源和校验值；②包内 LICENSE／NOTICE 和上游仓库地址；③是否改过文件、打过补丁，或把组件代码并入自有代码；④交付形态（安装包、镜像、SDK、设备、浏览器脚本、WASM）；⑤是否存在远程网络交互；⑥与自有代码的组合方式（独立进程、动态链接、静态链接、源码嵌入、聚合）。不确定的写“待查”并注明下一步，不要直接写“没有”。

附条件审批（不能直接写“通过”时）

结论为附条件通过：条件【…】、责任人【…】、完成日期【…】、证据位置【…】。条件关闭前不发布；条件无法完成的，回到审批表重新选择路径（商业许可、替换组件、隔离架构或停止使用），不得用“先发布后补”替代。

发布前补证（发布清单发现缺口时）

发布目录缺少【许可证副本／NOTICE／修改标识／对应源码／重链接或安装信息】，请于【日期】前补齐，并给出实际文件路径和校验值；无法补齐的，暂停该版本发布并评估回退。仅把 SBOM 标成“已审批”不算证据，验收看的是实际发布产物。

四个模拟案例（EX-01—EX-04）

以下四例均为模拟，不对应任何真实公司、产品、客户或交易；事实、结论和证据要求与审批表附录、SBOM「四例示范」、发布清单逐项对应。业务主体、产品和使用事实为虚构；EX-03 引用真实的 Qt／PySide6 名称和版本作为假设选型，不表示已检查实际安装包或运行过替换库测试。

EX-01 Apache-2.0 组件随闭源安装包分发

• 固定事实：模拟产品「星图桌面端 3.2」包含组件 librender 4.1.0（组件 ID CMP-XT-0001，审批单 APR-XT-3.2-01），许可证 Apache-2.0；研发修改了 2 个源文件；上游分发中含 NOTICE；组件随闭源安装包交付客户；无远程网络交互。
• 判断树：交付副本＝是（安装包）；修改＝是；网络交互＝否；组合方式＝随安装包整体分发（组件与自有代码分离打包）。
• 条款与结论：适用 Apache-2.0 §4(a)—(d)。需要向客户提供许可证副本；修改文件加显著变更标识；在源码形式中保留相关版权、专利、商标和署名声明；在 NOTICE 或随附文档中包含上游 NOTICE 的相关署名。Apache-2.0 不要求公开衍生作品源码，因此「闭源」与「满足 Apache 条件」可以并存；§3 就 Work 或其并入的贡献主张直接或帮助侵害专利而起诉（含反诉）时，该 Work 的专利许可终止；§6 除描述来源和复制 NOTICE 的合理惯常用途外不授予商标权。
• 履行动作：安装包内放置 LICENSES/Apache-2.0.txt；生成 NOTICE 和 THIRD-PARTY-NOTICES，保留上游署名并追加自有署名；修改文件头写明修改事实和日期；产品「关于」页展示第三方声明；不使用上游商标作背书。
• 审批结论：附条件通过，发布目录核验完成后方可发布；本例没有实际发布产物或审批签署。
• 证据与验收：真实使用时检查发布目录中的实际文件内容，而不是只看 SBOM 的审批状态；核对 NOTICE 是否包含上游相关段落、许可证副本是否可读、修改文件是否有标识。
• 变体：若组件只在同一法人内部使用、不向其他主体交付副本，则 §4 的分发条件不触发，但仍应登记组件和修改；一旦随安装包交付客户，重新进入分发分析。
• 附件对应：审批表附录 EX-01；SBOM「四例示范」EX-01；发布清单 3.1、3.2、6.2。

EX-02 GPLv3 工具仅在同一法人内部修改运行

• 固定事实：模拟公司「青禾科技」内部使用 GPLv3 工具 convd 2.4（组件 ID CMP-QH-0007，审批单 APR-QH-2.4-01），修改了配置解析模块，仅在公司同一法人自有服务器上运行；不向客户、关联公司、外包商交付副本；无远程交互（仅本机／批处理运行）。
• 判断树：交付副本＝否；修改＝是；网络交互＝否（假设仅本机／批处理运行，无远程交互）；组合方式＝内部部署。
• 条款与结论：GPLv3 §0 的 conveying 要求使其他主体能够制作或接收副本；同一法人内部运行和修改，没有对外交付副本，通常不构成 conveying，§4—§6 的分发义务不触发。GPLv3 也不要求把内部修改公开给公众。但修改记录、源码归档和主体边界仍要留存，以便交付或审计时快速判断。
• 履行动作：登记组件与修改；记录使用主体范围和部署位置；保留修改后的源码和构建脚本；在审批表中明确「不对外交付」；如后续向客户交付镜像或允许关联公司取用，重新审批。
• 证据与验收：内部部署记录、主体边界说明、修改文件清单、源码归档位置；验收时确认没有对外下载入口或客户副本。
• 变体：向客户交付包含该工具的容器镜像，即构成 conveying，须按 GPLv3 §4—§6 提供 Corresponding Source、许可证和修改标识；若换成 AGPLv3 并允许远程使用，还要检查 §13。若工具本身是 GPLv3 而非 AGPLv3，仅提供 SaaS 服务一般不触发远程源码条款，但不能忽略其他 AGPL 组件。
• 附件对应：审批表附录 EX-02；SBOM「四例示范」EX-02；发布清单 1.2、2.1、4.1。

EX-03 LGPLv3 库随闭源客户端动态链接交付

• 固定事实：模拟产品「北极星客户端 5.0」闭源（组件 ID CMP-BJ-0012，审批单 APR-BJ-5.0-03），随安装包交付 PySide6／Qt 6.8.3，假设仅随包使用 QtCore、QtGui、QtWidgets 及相应绑定、运行库，均选择 LGPLv3 路径（Qt 模块文档见 S14；实际 6.8.3 包和依赖待发布前核验），采用动态链接；未购买 Qt 商业许可；安装包同时带入若干第三方组件；无 AGPL 组件。
• 判断树：交付副本＝是（安装包）；修改＝否（Qt 库未修改）；网络交互＝否；组合方式＝动态链接＋随包分发共享库。
• 条款与结论：适用 LGPLv3 §4 的 Combined Works。应用可以保持闭源，但须同时满足：显著声明使用了库并附 GPLv3、LGPLv3 文本；保留版权声明；按 §4(d)(1) 采用合适的共享库机制，使运行时使用用户系统已有的库、接口兼容的修改版可工作，或按 §4(d)(0) 提供 Minimal Corresponding Source 与可重链接的 Corresponding Application Code；在 GPLv3 §6 要求时提供 Installation Information；不得限制用户修改库和为调试而反向工程；EULA 和应用商店规则不得与 LGPL 冲突。还需按纳入的 GPLv3 §6 提供随包库的完整对应源码（即使未修改）；§4(d)(1) 只解决应用侧的重链接路径。还须逐模块确认没有 GPL-only 模块、第三方组件各自许可已处理。
• 履行动作：安装包以独立共享库形式携带 Qt 库；附 LICENSES/LGPL-3.0.txt、LICENSES/GPL-3.0.txt 和第三方声明；提供 Qt／PySide6／Shiboken 随包库的对应版本源码包及修改（如有）；在「关于」页显著说明；准备替换库后的启动验证；审查 EULA 中禁止反向工程、限制替换的条款；核对每个 Qt 模块的许可。
• 证据与验收：实际执行一次「替换为接口兼容的修改版 Qt 库并启动」的验证；检查安装包内库是否为可替换的共享库、源码包版本是否与运行版本对应、声明是否可见、合同条款是否限制 LGPL 权利。不能只写「动态链接即合规」。
• 变体（静态链接）：改为静态链接后，组合作品仍按 LGPLv3 §0、§4 分析，通常需要按 §4(d)(0) 提供库的 Minimal Corresponding Source 和可重链接的应用代码／目标码，并在适用时提供安装信息；此时不能继续套用动态链接的结论。若购买商业许可，则 LGPL 条件对该商业授权覆盖范围不再触发，但仍要核对商业包来源、模块覆盖和第三方许可。
• 附件对应：审批表附录 EX-03（含 LGPL 与商业路径对照）；SBOM「四例示范」EX-03；发布清单 4.1、4.2、5.1—5.3。

EX-04 修改 AGPLv3 网络服务并允许远程使用

• 固定事实：模拟产品「洞察查询服务 3.1」基于 AGPLv3 组件 OpenMetricsHub 3.1（组件 ID CMP-DC-0004，审批单 APR-DC-3.1-02），修改了数据接入和 API 模块，部署为网络服务；客户和内部员工都通过浏览器远程使用；不向用户交付服务端副本。
• 判断树：交付副本＝否（服务端不交付）；修改＝是；网络交互＝是（客户与内部员工均远程使用）；组合方式＝服务端部署＋浏览器访问。
• 条款与结论：AGPLv3 §13 要求，修改程序后，若版本支持远程网络交互，必须向所有远程交互用户显著提供获取对应源码的机会，从网络服务器免费提供，采用标准或惯常的复制方式。该义务不以交付副本为前提；内部远程用户也不能自动排除。对应源码应包含修改版本及依 GPLv3 并入部分的 Corresponding Source，并与实际运行版本对应。
• 履行动作：在登录页、页脚或 API 文档中放置显著源码入口；源码从网络服务器免费下载，无需额外审批或付费；源码包与部署版本、提交号、构建产物对应；保留部署记录和版本标签；服务条款不得削减 AGPL 权利。
• 证据与验收：源码入口显著可访问，所有远程交互用户可免费获取，不附加审批或保密承诺；下载包能对应运行版本；版本号／提交号与部署记录一致；抽查修改文件包含在源码包中。仅内部用户访问时也要保留该入口，因为 §13 的「所有用户」不排除员工。受限服务可以沿用其登录权限，前提是每位远程交互用户均可免费取得源码；本例不把匿名下载或向全世界公开作为法定条件。
• 变体：若运行原样未修改的上游服务，§13 不因本次运行新增修改义务；仍须保留上游已有源码入口且不得削减接收方权利；但仍要分析是否交付副本、是否包含其他 AGPL 组件。若将 AGPLv3 与 GPLv3 代码组合，适用 §13 第二段的组合规则。
• 附件对应：审批表附录 EX-04；SBOM「四例示范」EX-04；发布清单 4.3、6.2。

适用边界

• 本模块不是法律意见。 许可证解释、衍生作品范围、专利和合同冲突需要结合具体事实由律师判断；本模块提供的是事实记录、条款索引和可验证的动作清单。
• 不按公司人数或固定季度简化。 是否简化流程取决于依赖变动频率、交付方式和实际使用场景；「30 人以下只做季度扫描」不是许可证规则，也不应作为省略登记的理由。
• 纯 SaaS 不是「没有开源义务」。 不交付服务端副本通常不触发 GPL 系分发条件，但 AGPLv3 §13、浏览器端脚本／WASM 交付、SDK 和镜像分发仍要分别判断。
• 嵌入式／硬件场景要增加 BOM 维度。 LGPLv3 的安装信息和重链接条件可能影响设备封闭性；签名启动、只读固件、应用商店规则都可能与 LGPL 权利冲突，应优先评估商业许可或调整架构。
• 商业许可不是「自动清零」。 商业许可只覆盖其授权范围和版本；第三方组件、社区包误用、超出模块覆盖仍会产生独立义务。
• SBOM 对外提供范围单独判断。 对客户或监管提供完整内部台账、仅提供第三方声明、或提供 SPDX/CycloneDX 子集，属于披露策略和合同问题，不应写成所有项目一律公开完整 SBOM。
• 来源冲突时升级。 包内 LICENSE、文件头、NOTICE、上游仓库、官网说明或商业合同不一致时，登记差异并交由法务／采购处理，不自行选择最有利的一份。

来源与核对记录

核对方法：执行阶段于 2026-10-29 通过 HTTPS 获取官方页面全文，验收阶段逐条复核条款；未取得全文的条目不登记为「已核对」。Qt 义务说明未标注版本；滚动文档 Qt Licensing 当前显示 Qt 6.12，不能代替 EX-03 所用 Qt 6.8 分支的模块核对。验收时 GNU 官网请求返回 403／超时，已按执行阶段保存的官方全文复核 S02—S06，未将本次请求失败记为重新获取成功。链接和条款可能随官方更新，发布前应重新打开确认。

组件级核对还应查看：具体版本包内 LICENSE／COPYING、源文件头、NOTICE、上游仓库对应 tag、官方版本说明或商业合同。上述材料与官方文本冲突时，登记冲突并升级审查；不采用「只以包内 LICENSE 为准」或「只以官网声明为准」的单一规则。

本版纠正的旧判断

变更日志

• v0.6（2026-10-29）：补充向研发收集事实、附条件审批和发布前补证三组沟通话术；明确本模块不另造通用合同条款库，合同文本分别由 M01/M03 承载。
• v0.5（2026-10-29）：重写判断树和义务矩阵；补充 GPLv2／GPLv3、LGPLv2.1／LGPLv3、AGPLv3 §13 的区分；补充 Qt／PySide6 三条路径和模块核对；验收修正收费、交付方式、动态链接库源码、AGPL 获取对象及模拟事实边界；新增发布核对清单；审批表和 SBOM 升级至 v0.2 并加入四例模拟；逐条登记官方来源及核对日期；删除旧版的绝对化和无依据表述。
• v0.4（2026-10-27）：附件升级为正式模板（审批表 docx＋SBOM 台账 xlsx），替换示例文件。
• v0.3（2026-10-27）：补充 AGPL 在 SaaS 场景下的说明。
• v0.2：将动态链接判断从「安全」改为「需评估」。
• v0.1：初版。