构建已经通过，却冒出一个 AGPL 依赖：什么时候该立合规项目？
先确认 AGPL 软件包、许可证表达式、产品用法和被卡住的发布决定，再区分依赖盘点、策略例外、法律判断与技术整改。
重点监测信号
- 具名软件包与版本已有准确 SPDX 许可证表达式和依赖路径
- 产品团队能分别说明修改、传递软件副本与远程网络交互
- 发布、收购或供应商审查决定有明确负责人和日期
构建能通过，说明这组软件至少完成了编译或打包，不代表团队已经知道 AGPL 许可证对产品意味着什么。**一条 AGPL 发现只有同时指向具名软件包与版本、准确许可证表达式、真实产品用法，以及一个有负责人和日期的发布或采购决定，才具备合规项目范围。**在此之前，更可能需要修依赖清单，而不是立即换组件或下法律结论。
软件成分分析厂商的业务拓展负责人，会在自己有权访问的开发、安全、采购和开源项目群里看到这类讨论。“扫描出 AGPL”值得查看，但晚一天是否造成损失，取决于发布例外、收购审查或供应商答复是否已经排期。如果只凭三个字母就报价，最容易把盘点问题卖成法律服务，或把法律问题误写成扫描器自动能解决的事。
一条示意性片段可能是：
“构建绿了，后端服务里有个 AGPL 包被法务标出来。发布评审前要答案。”
这是复合示例，不是真实客户消息。它没有软件包、版本、依赖路径、许可证表达式、修改情况、部署功能、分发方式、用户范围、内部策略和审核人。
AGPL 是许可证名称，不是统一的架构结论
**GNU Affero 通用公共许可证第 3 版（AGPLv3）**以 GNU GPLv3 为基础。最常被讨论的是第 13 条。GNU 官方文本写明：如果被许可人修改了程序，修改版应当向通过计算机网络远程交互的用户明显提供取得对应源代码的机会。
这句话里至少有五个扫描结果不会自动给出的对象：哪个程序、哪个修改版、谁在远程交互、交互发生在哪里，以及该修改版的对应源代码是什么。许可证其他条款还处理复制、修改和传递受许可作品。外围应用是否属于同一受约束作品，需要结合架构事实和法律判断，销售不能从“发现 AGPL”直接推导。
先保留准确标识。**软件包数据交换（SPDX）**的AGPL-3.0-only 页面指向仅限第 3 版的许可证；AGPL-3.0-or-later 是另一个标识。SPDX 2.3 许可证表达式规范规定，OR 表示可选许可证，AND 表示同时适用，WITH 用于连接例外。把完整表达式缩成“AGPL”，可能正好删掉审核人最需要的选择或例外。
构建成功回答的不是合规问题
**软件成分分析（SCA）**用于识别源代码、构建过程或制品中的组件及其证据。构建成功只能证明某组组件能被构建系统处理，不能证明：
- 发布制品里实际包含哪个版本；
- 该版本对应哪些许可证文件与通知；
- 团队是否修改了受许可程序；
- 程序怎样与用户和外围组件交互；
- 组织接受了什么法律判断与内部策略。
第一步是找依赖路径。直接运行依赖、只在构建阶段使用的工具、测试包，以及通过协议调用的独立服务，技术位置并不相同。记录包管理器、清单、锁文件、解析版本、交付制品与扫描依据。依赖锁文件究竟能证明什么解释了为什么仓库里的依赖树不等于实际交付制品。
还要分清软件物料清单（SBOM）与漏洞可利用性交换（VEX）。前者盘点组件，后者传递漏洞状态，两者都不是许可证法律结论。SBOM 与 VEX 所回答的问题可以避免把安全交付物错当成许可证证据。
同一行扫描结果可能对应四种项目
真正能帮助销售的不是再加一层红黄绿，而是看哪个决定对象失败了。
| 失败对象 | 实际缺少什么 | 可能的项目 |
|---|---|---|
| 组件记录 | 软件包、版本、依赖路径或许可证文件无法确认 | 依赖盘点与证据修复 |
| 内部发布规则 | 组件和用法已知，但策略没有批准的处理方式 | 策略例外或治理审查 |
| 许可证结论 | 技术事实已记录，但修改、组合、传递或网络交互的影响有争议 | 合格法律解释 |
| 发布架构 | 已审核义务或策略无法由现有设计满足 | 技术整改、替换或隔离 |
盘点修复不能包装成法律意见；法律解释也不能包装成扫描器功能。技术整改更不能在团队还不知道要满足哪条审核结论时先开工。
每一类问题的第一问也不同。组件记录不清，就要解析包与制品；策略被卡，就问是哪条规则阻止发布；需要法律判断，就给律师稳定的架构事实，而不是一张群聊截图；需要整改，就确认哪个接口或交付路径必须改变，以及怎样验收。
远程网络问题必须落到架构记录
第 13 条让远程交互成为关键事实，但“我们是软件即服务”仍然太宽。可审核的记录需要写明：哪个 AGPL 程序、是否修改、运行在哪里、哪些用户与该程序远程交互、它怎样连接外围组件、是否向客户传递软件副本，以及现有源代码提供方式。
下面两句话都不够：
“它只是镜像里的命令行工具。”
“客户不下载，只用我们的网页。”
第一句没有说明工具是否被修改、是否进入交付制品；第二句没有说明用户是否在远程使用修改版 AGPL 程序。架构负责人提供事实，合格法律人员解释具体许可证，发布负责人接受决定。三种责任不能由一次扫描替代。
最强的反对意见是：这样会把一个普通依赖放大成大项目。这个担心成立。如果软件包证据可靠、用法已经被策略批准，它可能只需例行登记。项目门槛不是“许可证听起来严重”，而是某个有日期的决定正缺少明确交付物。
回到那条发布评审消息
示例里目前只知道构建通过，以及有人要求复核。要成为合格项目，还需四个答案：
- **到底是什么软件？**保留软件包、版本、制品、依赖路径与 SPDX 表达式。
- **实际怎样使用？**分别记录修改、远程交互、代码组合与软件副本传递。
- **哪个决定被卡住？**写明发布、收购或供应商回复的负责人和日期。
- **什么交付物能解除阻塞？**依赖证据、策略例外、法律意见与技术变更是四份不同工作。
如果群里只有“AGPL”三个字，可以继续等待包含软件包或发布决定的后续片段。TOP Prospect 只会合并和排序用户主动连接且有权访问的 Telegram 群消息，并保留来源、时间和原文供人查看；它不能检查私有仓库、判断许可证义务、提供法律意见、联系发言者或批准发布。如何找回被转发内容的官方对象适合处理已经丢失软件包信息的扫描截图；定价页说明产品负责的发现范围。
发布评审不需要一句泛泛的“AGPL 风险很高”。它需要一条准确组件记录、一种真实用法、一个被卡住的决定和一份缺失交付物。四项齐全，许可证问题才成为合规项目。
常见问题
只要出现 AGPL 依赖，公司就必须公开整个应用吗？
不能从依赖标签直接得到这个结论。具体受许可约束的软件、许可证表达式、修改、代码组合、传递软件副本和远程网络使用方式都会影响判断。第 13 条针对用户通过网络与修改版程序远程交互的情形，具体架构仍可能需要合格法律意见。
AGPL-3.0-only 与 AGPL-3.0-or-later 有什么差别？
它们是不同的 SPDX 标识。前者只指第 3 版，后者允许按照版本条款选择第 3 版或后续版本。应保留软件包证据真正支持的标识。
为什么构建成功不能证明许可证合规？
构建成功只证明选定组件能够编译或打包，不能证明许可证表达式、实际交付制品、修改历史、产品架构，以及组织最终接受的法律与策略判断。
什么时候可以准备合规服务方案？
当记录包含软件包与版本、许可证表达式证据、相关产品用法、当前被卡住的决定、缺失交付物和负责接受结果的人时，才适合界定方案。
常见问题
只要出现 AGPL 依赖，公司就必须公开整个应用吗？
不能从依赖标签直接得到这个结论。具体受许可约束的软件、许可证表达式、修改、代码组合、传递软件副本和远程网络使用方式都会影响判断。第 13 条针对用户通过网络与修改版程序远程交互的情形，具体架构仍可能需要合格的法律意见。
AGPL-3.0-only 与 AGPL-3.0-or-later 有什么差别？
它们是不同的 SPDX 许可证标识。前者只指第 3 版，后者允许依照版本条款选择第 3 版或后续版本。扫描系统应保留软件包证据真正支持的标识。
为什么构建成功不能证明许可证合规？
构建成功只能证明选定组件能够编译或打包，不能证明组件的许可证表达式、实际交付制品、修改历史、产品架构，以及组织最终接受的法律与内部策略判断。
什么时候可以为这条问题准备合规服务方案？
当记录已包含软件包与版本、许可证表达式证据、相关产品用法、当前被卡住的决定、缺失交付物和负责接受结果的人时，才适合界定方案。
资料来源与延伸阅读
值得关注的潜在线索 Signal 是怎样被发现的
了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。
