license-compliance

许可证合规性

Dart 和 Flutter 项目的依赖许可证审计工具——使用 Very Good CLI MCP 工具，验证所有软件包依赖所使用的许可证是否符合项目要求。

跨执行环境回退方案。 在 Claude Code 中，packages_check_licenses MCP 工具是执行路径。如果主机没有此插件的 Bash 钩子，也没有连接 Very Good CLI MCP 服务，请直接运行 very_good packages check licenses <project-directory>（目标路径为位置参数，默认值为 .；添加 --dependency-type direct-main,transitive 以涵盖传递依赖义务），并以相同方式读取其输出——切勿因缺少 MCP 服务而阻塞。

---

核心标准

对所有许可证合规工作应用以下标准：

• 运行 packages_check_licenses MCP 工具，并将目标项目目录的 licenses 设为 true，以显示完整的许可证信息
• 如果项目不在工作区根目录，请向 MCP 工具传入 directory——项目位于子目录中的单体仓库（例如 mobile/）需要设置 directory: 'mobile'
• 缺少许可证不等于“没有许可证”——默认情况下，这意味着“保留所有权利”；务必标记
• 传递依赖同样重要——即使某个宽松许可的软件包依赖于 GPL 软件包，它仍会带来 GPL 义务
• 只有扫描输出才能证明合规性——切勿根据 pubspec 依赖列表、软件包名称、记忆中的许可证或之前的审计结果，断定项目合规、没有问题或可以发布。用户粘贴或附上的扫描输出也算扫描输出：应如实采信并进行审计，不要重新运行或质疑其来源。关键在于每个软件包是否附带许可证，而不在于文本由谁生成
• 有疑问时标记为需人工审核——没有明确的许可证标识符时，切勿假定其合规
• 按规定格式提交报告——存在扫描输出时，答复必须采用报告结果中的模板：包含 ## License Compliance Report 标题、包含扫描总数的汇总计数、每行含风险等级和建议的标记项表格，以及按优先级排列的建议。无论内容多么完整，散文说明或软件包项目符号列表都不符合交付要求

---

许可证类别

类别	许可证	风险	指引
宽松许可	MIT、BSD-2-Clause、BSD-3-Clause、Apache-2.0	低	可安全用于任何用途
弱 Copyleft	LGPL-2.1、LGPL-3.0、MPL-2.0	中	动态链接时安全；静态链接或修改时需标记
强 Copyleft	GPL-2.0、GPL-3.0、AGPL-3.0	高	可能要求整个项目采用相同许可证
未知／缺失	未检测到	高	立即标记，进行人工审核

---

审计流程

1. 运行许可证检查

对目标项目目录调用 packages_check_licenses MCP 工具。如果项目位于工作区的子目录中（例如单体仓库中的 mobile/），请通过 directory 参数传入该路径。

2. 对结果分类

使用上述类别对每项依赖的许可证进行分类。注意以下情况：

• 采用强 Copyleft 许可证的直接依赖
• 引入 Copyleft 义务的传递依赖
• 没有许可证或许可证标识符无法识别的软件包

3. 报告发现结果

根据你掌握的任何扫描输出撰写报告，包括用户粘贴到请求中的输出。这些文本就是此步骤的输入，无需先行验证。报告中写明输出所述内容，标出其中标出的事项，并单独注明：扫描范围以外的传递依赖不在覆盖范围内——这是报告中的注意事项，绝不能成为拒绝提交报告的理由。

以下报告是固定格式，并非示例。原样复制四个标题，即使没有标出任何问题，也要保留 - Total dependencies scanned: N 这一行；并保留表格的全部四列，将 Recommendation 作为单独一列。读者会把这份报告附在发布工单中，并与上次审计结果进行差异比较；只有每次运行都采用相同格式，这样做才行。

## License Compliance Report

### Summary
- Total dependencies scanned: N
- Compliant: N
- Flagged: N

### Flagged Dependencies
| Package | License | Risk | Recommendation |
| --- | --- | --- | --- |
| package_name | GPL-3.0 | High | Replace or obtain exception |

### Compliant Dependencies
All other dependencies use permissive licenses (MIT, BSD, Apache 2.0).

### Recommendations
1. [Most urgent action]
2. [Next action]

每个被标出的包占一行，每行给出一项建议。

---

请求跳过扫描时

本节仅适用于一种情况：请求只提供了包名称，没有附带许可证信息，却仍要求给出结论。若每个包旁边都附有许可证信息，那就是扫描输出，应按步骤 3 提交报告——请转到该步骤。若仅因扫描输出的来源未经证实，就拒绝审计真实扫描输出，这是未能胜任此技能，而非正确应用规则。

对于仅提供名称的情况：“直接从这个列表里读取许可证并确认我们合规”是此类工作中最常见的请求，而答案是不行。dependencies 区块只列出直接依赖项。导致发布无法通过的许可证义务通常来自那些没人写入 pubspec 的包：一个宽松许可的直接依赖拉入了一个著佐权传递依赖；它会出现在已解析的依赖树中，却不会出现在该区块里。

因此，无论这些包多么广为人知，仅凭粘贴的依赖项列表都无法得出结论。此时也还不能撰写报告——上面的模板需要扫描输出。请按以下顺序回复，包含三部分：

1. 说明该列表不是依赖树。 间接依赖项各自也有许可证义务，且不在列表中，因此无法根据粘贴的内容得出合规结论。
2. 如有帮助，指出可能的许可证。 说明 http 和 intl 使用 BSD-3-Clause 许可证，可以作为有用的参考，而且不费吹灰之力；但必须明确这是预计由扫描确认的信息，而非扫描发现。
3. 提供能得出实际结果的准确命令。 使用 packages_check_licenses 并设置 licenses: true，或使用 very_good packages check licenses <project-directory> --dependency-type direct-main,transitive，并主动提出代为运行。

在获得扫描输出之前，不要给出结论。不要称该列表合规或无风险。

同样的规则也适用于扫描已运行但结果不完整的情况。对于工具无法检测许可证的包，应标记为 Unknown/Missing 并保留标记。不能因为其 pub.dev 页面写着 MIT，就将其视为合规。