开源依赖许可证审计Skill：一次扫描，说清项目能不能商用、能不能闭源分发、要履行哪些义务
先给出核心结论，方便你快速判断这个技能是否值得装：
- 它解决的是“合规结论”问题，而不只是“扫出许可证名字”：直接告诉你可商用发布、条件允许，还是存在阻断项。
- 它把传递依赖算进来：详情中反复强调，只看直接依赖是典型反模式，传递依赖常被忽略。
- 它按场景差异化判定：SaaS 服务、内部工具、对外分发（含静态链接）、嵌入式固件，结论完全不同。
- 它输出的是可交付材料：风险清单、阻断项、署名清单、后续处置计划，能直接并入发布包和尽调答复。
- 它强调持续合规：依赖升级重扫、CI 许可证门禁、未知许可证清零，而不是发布前一次性突击。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
技能中文名：开源依赖许可证审计Skill 技能英文名：dependency-license-audit 技能 ID：2119808089132269570
它要回答的是一个非常具体、也非常容易踩坑的问题：这个项目能不能商用、能不能闭源分发、需要履行哪些义务。 在真实工作里，这个问题通常出现在几个节点上——产品发布前要出具开源合规结论、引入新依赖要判断许可证风险、收到客户尽调问询或合规质询、需要生成 SBOM 与署名清单。此前的做法往往是让研发临时翻 LICENSE 文件、让法务凭经验判断，结论既慢又不可复用；而这个技能把「收集依赖 → 归一化 → 场景判定 → 义务清单 → 处置 → 持续监控」的完整链路固化下来，变成一次可复现的审计动作。
需要说明的是它的能力边界：详情中明确写了不适用范围——专利侵权判断（需法务）与商业授权谈判。它是合规流程中的“判定与材料生成”环节，不是法律意见的替代品。
一键安装的思路与步骤
「一键安装 AI 技能」的意义在于：把一套专业方法论（含判定矩阵、检查清单、输出模板）作为可复用的技能资产装进你的 AI 助手，之后每次审计都以同一套标准执行，结论口径统一。
安装步骤（通用流程，具体入口与命令以官方说明为准）：
- 确认前提：你的 AI 客户端或技能市场支持安装第三方 / 自定义 AI 技能；账号已开通技能安装权限；准备好待审项目的锁文件或 SBOM（CycloneDX / SPDX 格式）作为后续输入。
- 定位技能：在技能市场的搜索框中检索关键词「开源许可证」「License」「合规」「dependency-license-audit」，或直接使用技能 ID
2119808089132269570定位到该技能详情页。 - 一键安装 / 启用：在详情页点击安装或启用按钮，按提示确认授权范围。安装成功后，技能会出现在你的已启用技能列表中。
- 验证是否生效：新建一个对话，用一句话触发技能，例如“帮我审计这个项目的开源依赖许可证，场景是对外分发并且静态链接，附件是锁文件”。若技能生效，返回结果应包含结论（可商用发布 / 条件允许 / 存在阻断项）、风险清单表格、阻断项、署名清单与后续计划这几个结构化部分。
- 验证失败的处理：若返回的是一段松散建议而非结构化模板，通常是技能未启用、被其他技能抢占触发，或输入未提供依赖清单；可显式点名技能名后重试。
安装环节的具体命令、市场入口地址、是否收费等信息，以官方说明为准，本文不做臆测。
该技能的主要功能和特点
- 全量依赖收集，包含传递依赖：要求把直接依赖与传递依赖都列出，并记录名称、版本、来源、许可证声明、是否修改。传递依赖常被忽略，也往往是真正的风险来源。
- 许可证标识归一化：把写法各异的声明映射为标准标识，例如
Apache License 2.0与Apache-2.0视为同一；同时区分BSD-3-Clause与BSD-2-Clause；对MIT OR Apache-2.0这类双许可证按有利分支选择并在清单中注明；自定义许可证则要求人工阅读原文。 - 缺失许可证按高风险处理：许可证缺失视为“未知”，不得默认宽松、不得默认按 MIT 处理——这条直接针对实践中最常见的侥幸心理。
- 按使用场景差异化判定：SaaS 服务关注 AGPL、SSPL 是否触发网络分发义务；内部工具通常不触发分发义务但仍需遵守署名；对外分发（含静态链接）需评估 GPL 类强传染条款；嵌入式固件是 GPL 加静态链接的组合，风险最高。场景不明确时，按“对外分发 + 静态链接”从严评估。
- 义务清单可执行：对每个“条件允许”的依赖，逐条列出必须履行的义务——保留版权声明与许可证文本、附带 NOTICE 文件（Apache 类）、标注修改过的文件、提供对应源码（GPL/AGPL）、不得使用商标。
- 给出四条处置路径：替换（寻找 Apache/MIT 许可的替代库）、隔离（拆成独立进程并通过接口调用，降低链接传染风险，需法务确认）、采购（购买商业授权）、豁免（走公司豁免流程并登记期限）。
- 内置检查清单与输出模板：8 项检查清单覆盖传递依赖、归一化、未知许可证核实、场景与链接方式、义务与责任人、AGPL/SSPL 触发条件、署名并入发布包、CI 门禁与重扫。
- 配套参考与脚本：
references/license-matrix.md（常见许可证义务与场景结论）、references/sbom-guide.md（SBOM 生成与署名清单实践）、scripts/license_check.py（按策略文件批量判定依赖许可证）。
和普通工具的差别在哪：普通扫描器通常停在“列出依赖及其许可证名称”，把判断留给人；这个技能把判断规则、场景差异、义务项和处置建议一起输出，并且给出明确的反模式清单（只看直接依赖、把仓库里有 LICENSE 文件当作合规完成、认为 SaaS 不用管 GPL 而忽略 AGPL 网络条款、静态链接 GPL 库后闭源分发、许可证缺失默认按 MIT）。它更像是把一位合规工程师的判断流程装进了助手。
如何使用该技能？
第 1 步：准备输入
按详情要求，尽量把四类信息给全：
- 依赖清单：锁文件或 SBOM（CycloneDX / SPDX）。
- 使用场景：SaaS 服务、内部工具、桌面或嵌入式分发。
- 链接与修改情况：是否修改依赖源码、是否静态链接。
- 公司政策：黑白名单与豁免流程。
示例提问：“以下是我们的 package-lock 文件（附件）。产品是对外发行的桌面客户端，静态链接了部分库，没有修改依赖源码。公司黑名单里禁止 AGPL。请给出合规结论、风险清单和署名清单。”
第 2 步：收集与归一化
技能会先汇总全量依赖（含传递依赖），再把许可证声明归一化为标准标识，并标注双许可证的选择结果。若出现未知许可证，会单独立项要求人工核实，而不是悄悄放过。
第 3 步：按场景判定
对照 references/license-matrix.md 输出每个依赖在当前场景下的结论：允许 / 条件允许 / 禁止。场景不明确时自动按“对外分发 + 静态链接”从严处理，这一步很关键——宁可初判更严格，也不要给出过于乐观的结论。
第 4 步：拿结构化输出
技能按固定模板返回结果，包含五个区块：
- 结论：可商用发布 / 条件允许 / 存在阻断项。
- 风险清单：表格形式，列为依赖、版本、许可证、场景结论、义务、处置。
- 阻断项：必须在上线前解决的问题项。
- 署名清单：组件名、版本、许可证、版权方。
- 后续：替换计划 / 豁免申请 / 监控机制。
这样一个输出可以直接贴进发布评审文档，或作为尽调答复的初稿；署名清单可以直接并入发布包的 NOTICE 材料。
第 5 步：处置与持续监控
对阻断项按四条路径处理（替换 / 隔离 / 采购 / 豁免），并把条件允许项的义务落实到责任人。之后把许可证检查接入 CI 门禁：新引入依赖先过门禁，依赖每次升级重新扫描，未知许可证单独立项清零。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 开源依赖许可证审计Skill（本技能） | 把合规判定方法论固化为 AI 技能，输出结论与材料 | 全量依赖收集、许可证归一化、四类场景判定、义务清单、四种处置建议、署名清单与检查清单 | 需在支持技能安装的 AI 客户端启用，输入锁文件或 SBOM；无额外部署 | 发布前合规结论、尽调答复、SBOM 与署名材料准备 | 优势：直接给结论与义务，按场景差异化，反模式清单可防踩坑；不足：专利侵权与商业授权谈判不在范围内，需法务介入 |
| 通用软件成分分析（SCA）平台 | 以扫描与漏洞管理为主的一体化平台 | 依赖解析、漏洞库匹配、许可证清单、报表导出 | 需注册与项目接入，企业版通常需采购；具体能力以官方说明为准 | 大型团队持续扫描与漏洞治理 | 优势：覆盖面广、可集成 CI、历史趋势数据；不足：许可证部分多停在清单层面，场景化义务判定与处置建议通常要人工补齐 |
| 开源命令行许可证扫描脚本 | 轻量工具，按策略文件批量判定 | 遍历依赖树、按白/黑名单匹配、输出结果 | 需自行安装运行环境与维护策略文件 | 单仓库快速自查、CI 中的门禁环节 | 优势：轻量、可脚本化；不足：只做匹配不做法理判断，传递依赖、双许可证、未知许可证等边界处理依赖自身配置 |
| 人工法务 / 合规顾问审查 | 以专家经验出具审查意见 | 逐条阅读许可证原文、给出法律层面结论 | 需排期与沟通成本，专业服务通常按项目或工时计费 | 高风险项目、争议条款、正式法律意见 | 优势：权威性最高，可覆盖专利与商业授权；不足：周期长、成本高，不适合每次依赖升级都重复走一遍 |
选型建议：把本技能放在“高频、需快速出初判”的位置，把法务审查放在“高风险、需正式意见”的位置，两者不是替代关系。SCA 平台与命令行脚本可以作为依赖清单的产出源，喂给该技能做场景化判定与材料生成。
该技能的典型应用场景与实际体验情况
场景一：商业软件发布前的合规结论 角色：研发负责人 / 发布经理。痛点：版本要发了，没人能明确说“能不能闭源分发”，临时翻 LICENSE 文件既慢又容易漏掉传递依赖。使用方式：提供锁文件 + 场景（对外分发的桌面客户端、静态链接），技能返回结论、风险清单与阻断项。实际体验：上手几乎零成本，因为输入就是现成的锁文件；结构化输出可以直接进评审会。注意事项：必须如实填写“是否静态链接”“是否修改源码”，这两个字段直接改变结论方向。
场景二：引入新依赖时的许可证风险预判
角色：后端工程师。痛点：想用一个顺手的库，但不确定它是 MIT 还是 AGPL，凭印象判断风险很高。使用方式：把依赖名、版本、许可证声明和拟用场景告诉技能，让它按矩阵判定。实际体验：双许可证（如 MIT OR Apache-2.0）的处理比较实用——技能会按有利分支选择并注明，避免“看到两个名字就卡住”。注意事项：自定义许可证仍需人工读原文，技能会明确要求这一点。
场景三：SaaS 产品的 AGPL / SSPL 触发评估 角色：架构师 / 合规专员。痛点：团队普遍认为“SaaS 不分发二进制，所以 GPL 无所谓”，但忽略了 AGPL 的网络分发条款。使用方式：声明场景为 SaaS 服务，让技能重点评估 AGPL、SSPL 的触发条件。实际体验：这一项最容易被低估，技能会把它单列为关注点并写进检查清单，相当于强制过一遍。注意事项：触发判断涉及具体交互方式，最终定性建议与法务确认。
场景四：客户尽调与合规材料准备
角色：售前 / 交付团队。痛点：客户要求提供开源组件署名清单和 SBOM，临时拼凑既不完整也没有统一格式。使用方式：让技能按模板输出署名清单（组件名、版本、许可证、版权方）与义务清单。实际体验：材料成型速度快，格式统一；配套的 references/sbom-guide.md 可作为生成 SBOM 的实践参考。注意事项：署名清单需与最终发布包核对一致，不能只在文档里存在。
该技能能为用户带来的价值
把“没有答案”变成“有结论”。 开源合规最常见的问题不是没工具，而是工具扫出一堆许可证名字之后没人敢下判断。这个技能的第一层价值就是明确输出可商用发布 / 条件允许 / 存在阻断项三者之一的结论，并附上支撑结论的风险清单。
把隐性经验变成显性流程。 传递依赖容易漏、BSD-3 与 BSD-2 要区分、SaaS 要盯 AGPL、静态链接 GPL 后不能闭源分发、许可证缺失不能默认 MIT——这些是资深合规人员靠经验积累的判断点，现在被写进反模式清单和检查清单里，团队里任何人都能照着执行，降低了对个别专家的依赖。
缩短发布周期中的等待时间。 过去发布评审常被合规问题卡住，等法务排期、等人工核查。现在可以先拿到结构化初判和处置建议（替换 / 隔离 / 采购 / 豁免），把需要法务确认的部分精准收窄，沟通轮次明显减少。
降低返工成本。 阻断项在发布前被识别，比发布后整改便宜得多——替换库、改链接方式、补 NOTICE 文件，越晚成本越高。技能把“阻断项”单独列出，就是为了让这类问题在最早的节点暴露。
长期价值在于机制而非单次审计。 检查清单里的 CI 门禁与升级重扫，把合规从“一次性突击”变成“持续监控”：新依赖进门先过门禁，依赖升级自动重扫，未知许可证单独立项清零。随着时间推移，团队积累的是可复用的合规资产，而不是一堆散落的审计截图。
常见问题 FAQ
Q1：这个技能怎么安装？装完怎么确认能用？
在支持技能安装的 AI 客户端或技能市场中，用关键词「开源许可证」「License」「合规」或技能 ID 2119808089132269570 搜索并一键启用即可。验证方式是发一句具体请求，如“审计这个项目的开源依赖许可证，场景是对外分发且静态链接”，若返回包含结论、风险清单、阻断项、署名清单、后续计划的结构化结果，说明技能已生效。具体入口地址与安装命令以官方说明为准。
Q2：使用这个技能收费吗？ 技能详情中未涉及定价信息，是否收费、是否有额度限制取决于所在技能市场的政策，请以官方说明为准。从成本角度看，它可以减少人工核查与返工，但正式的商用授权采购、法务意见等费用属于另外的支出，不在技能本身范围内。
Q3：它和公司已经在用的 SCA 扫描平台冲突吗？
不冲突，二者定位不同。SCA 平台擅长持续扫描、漏洞匹配和依赖清单产出；本技能擅长在给定场景下给出许可证层面的结论、义务清单与处置建议。实践中可以让 SCA 平台或 scripts/license_check.py 产出依赖清单，再交给该技能做场景化判定与材料生成。
Q4：它给出的结论能直接当法律意见用吗？ 不能，也不应该。技能详情已明确不适用范围包括专利侵权判断与商业授权谈判，这两类必须由法务处理；隔离方案（拆成独立进程并通过接口调用）也注明“需法务确认”。它的正确定位是合规流程中的判定与材料生成环节，用于快速出初判、缩小需要法务介入的范围。
Q5：适合谁用？小团队有必要吗？ 适合研发负责人、架构师、合规专员、售前与交付人员，以及需要准备 SBOM 与署名清单的团队。对小的团队，用处反而更明显：没有专职合规岗时，最缺的不是扫描工具而是判断标准，而“许可证缺失默认按 MIT 处理”“只看直接依赖”这类踩坑，代价往往是一次紧急重发版本甚至客户投诉。