前言¶
用 DSH 做应用或插件时，依赖往往一层套一层。发版、对外开源或接受客户审计前，如果只凭肉眼扫 package.json，很容易漏掉 GPL/AGPL 这类强传染许可，或项目根目录、清单里根本没有可识别的许可证信息。事后被追问「为什么用了 GPL 却没按义务开源」，风险从「分发」那一刻就已经存在。
下面介绍维护者 feely0208 的 DSH 插件 dsh-license-guard（npm 包名 @deepwhale-cn/dsh-license-guard，分类 admin-security）。它在当前工程目录扫描依赖树，并按固定规则标出许可相关风险；也可不装 DSH，单独用 CLI 跑一遍。检查通常只需几秒，退出码可用于 CI。
这是什么¶
dsh-license-guard 做的是开源许可与许可证合规检查：扫描依赖树，找出 GPL/AGPL 传染、许可未知、缺 LICENSE 等风险，适合发布前、开源前、被审计时跑一遍。
与「只列依赖许可证」的工具不同，README 明确说明它不只看依赖，也会看项目自身——例如仓库缺 LICENSE、package.json 缺 license 字段，这两类问题会让下游无法判断能否合法使用你的代码。
插件归属 GitHub 仓库 feely0208/dsh-license-guard，在 DSH 社区目录（如 skillhub.cn 插件页）可查到条目；DSH 生态理念是「一切皆插件」，社区目录为独立站点，与 DeepSeek / 幻方无官方从属关系。
它查什么¶
README 用级别表格归纳检查重点（工具内部共 5 条规则，覆盖依赖树许可风险与项目基础文件）：
| 级别 | 内容 |
|---|---|
| 高 | GPL / AGPL —— 强传染 |
| 中 | 许可未知（没写许可证 ≠ 随便用）· 项目缺 LICENSE |
| 低 | LGPL / MPL / EPL · package.json 缺 license 字段 |
不覆盖：专利条款、商标、出口管制、SSPL/BUSL 等非 SPDX 自定义协议。依赖声明里的许可证字段可能不准（维护者写错），本工具不校验其真实性。
README 用典型场景说明「不装它会怎样」：产物里混入未发现 GPL 依赖并对外分发后，GPL 义务从分发时即可能触发；跑一次检查成本很低，与事后审计代价形成对比。此处为 README 中的说明性场景，非第三方实测数据。
安装与启用¶
在 DSH 环境中安装（命令来自官方 README）：
# DSH 插件（推荐）
dsh plugin --profile web add @deepwhale-cn/dsh-license-guard
不依赖 DSH 时，可用 npm 一次性执行（同样来自 README）：
npx @deepwhale-cn/dsh-license-guard
package.json 中要求 Node >=18，DSH 引擎 >=0.1.0-rc.6。插件以当前 dsh 进程权限 读取目录与依赖信息；安装或使用前，应自行查看仓库源码与 MIT 许可证声明，并对合规结论负责。README 边界声明：使用者须遵守所在地区法律法规，对使用本项目造成的后果自行承担责任。
典型用法¶
在项目根目录执行以下命令（均来自 README）：
dsh-license-guard # 扫当前目录
dsh-license-guard --demo # 用内置样本看效果
dsh-license-guard --html r.html # 输出 HTML 报告
无参数扫描适合日常发版前自检；--demo 便于在未接入真实仓库时确认输出格式；--html 生成可归档或附在审计材料中的 HTML 报告。README 说明退出码可挂 CI，具体流水线写法需按你方 CI 对非零退出码的策略配置。
报告示例与规则说明图见 README 中的链接（deepwhale.org.cn 插件资源路径）。
适用场景与注意¶
适合谁：维护 Node/前端或 DSH 插件仓库、需要在发版/开源/审计前快速扫一遍许可风险的开发者；与深鲸网安守护系列里「供应链与构建」方向的 依赖投毒、物料清单 等插件配套时，README 将其定位为「一个插件做一件事」，安全问题链式出现时可组合使用。
务必知晓：
- 工具给出的是基于声明与项目文件的规则化提示，不能替代法务意见。
- 不覆盖 SSPL/BUSL 等自定义协议及专利、商标等维度。
- 依赖树中的
license字段未被工具验证真伪。
结尾¶
dsh-license-guard 把「依赖传染许可」和「项目自身缺许可信息」放在同一次扫描里，用短命令和可接 CI 的退出码，把发版前、开源前、被审计前的许可自检做成固定步骤。
