依赖协议审计 - AI 自动化引导

本页面专为 AI 助手设计

用户可以将本页面的 URL 发送给 AI 助手（如 Claude Code、Cursor、Google Antigravity 等），AI 助手会阅读本页内容，自动完成依赖协议审计、生成合规报告、并安装持续检查 Skill。

使用示例

将以下提示词发送给你的 AI 助手：

"使用 websearch 访问 https://tpscsm-docs.pages.dev/license-audit/ 按照里面的步骤帮我完成依赖协议审计"

AI 会阅读本页内容，自动扫描项目依赖、查询协议、生成合规报告、安装持续检查 Skill。

面向 AI 助手的说明

你正在阅读一份依赖协议审计自动化指南。你需要对用户当前项目的所有直接依赖进行协议（License）审计，生成合规报告文件，并安装一个持续检查的 Skill，确保后续依赖变更时能自动触发重新检查。

分发场景前提

⚠️ 重要前提：本审计以"开源分发"为基准。
被审计的项目将上传到 GitHub 公开仓库，属于开源分发形式。所有后续的合规判定均以此为基准。这意味着：
所有依赖必须是开源协议 — 依赖必须具有经 OSI 认证的开源协议（如 MIT、Apache-2.0、GPL 等）。未知协议（UNKNOWN）或非开源协议视为不合规。
项目协议必须与依赖协议兼容 — 项目自身的协议必须与所有依赖的协议在分发场景下兼容（参见附录 A 的兼容性矩阵）。
必须满足分发要求 — 必须满足所有依赖协议的分发要求，包括但不限于：保留版权声明（attribution）、Copyleft 传染性义务、专利授权声明等。

强制执行规则

你必须严格遵守以下规则，不得违反：

必须创建 Checklist — 在开始之前，创建以下完整的 checklist，在整个流程中持续跟踪进度：

☐ Step 0: 环境检测 — 检测项目类型和依赖清单文件
☐ Step 0.5: 检查项目自身协议 — 识别项目 LICENSE 文件的 SPDX 标识符
☐ Step 1: 提取直接依赖 — 从依赖清单中提取所有直接依赖
☐ Step 2: 查询协议 — 使用 WebSearch 查询每个依赖的协议，并判定是否为开源协议
☐ Step 3: 生成 LICENSE.LIST — 生成依赖协议清单文件
☐ Step 4: 生成 LICENSE — 生成合规参考报告，含项目协议与依赖协议兼容性判定
☐ Step 5: 安装 Skill — 安装依赖协议持续检查 Skill
☐ Step 6: 生成审计报告 — 生成完整的中文审计报告，含版权协议合规结论

必须逐步执行 — 按照 Step 0 到 Step 6（含 Step 0.5）的顺序逐一执行，禁止跳过任何步骤，禁止合并步骤。
必须通知用户 — 每个步骤开始执行前和完成后都必须通知用户当前进度。
必须完成每个子任务 — 每个步骤内部的子任务也必须全部完成，不得偷懒省略。
遇到错误必须处理 — 如果某个步骤执行失败，必须尝试修复或告知用户具体的错误原因，不得静默跳过。
只处理直接依赖 — 不要处理传递依赖（transitive dependencies），只审计用户直接声明的依赖。

Step 0: 环境检测

目标： 检测当前项目类型，识别包管理器和依赖清单文件。

0.1 检测项目类型

检查用户当前项目根目录中的文件，判断项目类型：

检测文件	项目类型	包管理器	依赖清单文件
`package.json`	Node.js / 前端项目	npm / yarn / pnpm	`package.json`
`go.mod`	Go 项目	go modules	`go.mod`
`requirements.txt`	Python 项目	pip	`requirements.txt`
`pyproject.toml`	Python 项目	pip / poetry	`pyproject.toml`
`Cargo.toml`	Rust 项目	cargo	`Cargo.toml`
`*.csproj`	.NET 项目	nuget	`*.csproj`

如果项目中包含多种依赖清单文件（例如同时有 package.json 和 go.mod），则所有类型都需要审计。

0.2 处理未识别的项目

如果项目不匹配上述任何类型，通知用户：

我无法自动识别你的项目类型。请告诉我：
你的项目使用什么编程语言？
依赖声明在哪个文件中？

等待用户回复后，手动指定依赖清单文件继续执行。

完成后更新 checklist：

☑ Step 0: 环境检测 — 检测项目类型和依赖清单文件

Step 0.5: 检查项目自身协议

目标： 识别项目自身使用的开源协议，作为后续兼容性判定的基准。

0.5.1 读取 LICENSE 文件

检查项目根目录是否存在 LICENSE 或 LICENSE.md 文件：

如果存在，读取文件内容
如果不存在，跳转到 0.5.3

0.5.2 识别协议类型

根据 LICENSE 文件内容，识别其 SPDX 协议标识符。常见的识别方式：

关键文本特征	对应协议
"MIT License" 或 "Permission is hereby granted, free of charge"	MIT
"Apache License, Version 2.0"	Apache-2.0
"GNU GENERAL PUBLIC LICENSE Version 3"	GPL-3.0-only
"GNU GENERAL PUBLIC LICENSE Version 2"	GPL-2.0-only
"GNU LESSER GENERAL PUBLIC LICENSE"	LGPL-3.0-only 或 LGPL-2.1-only
"BSD 3-Clause" 或 "Redistribution and use in source and binary forms"	BSD-3-Clause
"ISC License"	ISC

如果无法通过文件内容识别，可以使用 WebSearch 搜索 "<项目名称>" site:github.com license 辅助确认。

记录结果： 将识别到的 SPDX 标识符记录下来，后续 Step 4 兼容性判定会用到。

0.5.3 处理特殊情况

场景 A：有 LICENSE 文件且可识别

通知用户：

已识别项目协议为 <SPDX 标识符>（如 MIT），将以此作为后续兼容性判定的基准。

场景 B：有 LICENSE 文件但无法识别

通知用户：

项目中存在 LICENSE 文件，但内容为自定义协议或无法自动识别其 SPDX 标识符。请确认项目使用的协议：
这是一个标准开源协议？请告诉我协议名称
这是自定义协议？请注意：自定义协议可能与某些依赖协议不兼容
需要更换为标准开源协议？建议选择 MIT、Apache-2.0 或 GPL-3.0

等待用户回复后，记录确认的协议标识符继续执行。

场景 C：没有 LICENSE 文件

通知用户：

⚠️ 项目没有 LICENSE 文件。 作为开源分发的项目，必须有明确的协议声明。没有协议的代码在法律上默认"保留所有权利"，他人无权使用、修改或分发。
请选择一个开源协议：
MIT — 最宽松，允许任何用途，只需保留版权声明
Apache-2.0 — 宽松 + 专利授权保护
GPL-3.0 — Copyleft，衍生作品须同协议开源
其他（请指定）

等待用户选择后，记录协议标识符继续执行。

完成后更新 checklist：

☑ Step 0.5: 检查项目自身协议 — 项目协议为 <SPDX 标识符>

Step 1: 提取直接依赖

目标： 从依赖清单文件中提取所有直接依赖的名称和版本。

1.1 读取依赖清单文件

根据项目类型，按以下规则提取直接依赖（不含传递依赖）：

Node.js (package.json)

读取 package.json 中的 dependencies 字段。不要读取 devDependencies、peerDependencies 或 optionalDependencies。

json

{
  "dependencies": {
    "express": "^4.18.2",    // ← 提取这些
    "lodash": "^4.17.21"
  },
  "devDependencies": {
    "typescript": "^5.0.0"   // ← 忽略这些
  }
}

Go (go.mod)

读取 go.mod 中 require 块的依赖。不要提取带有 // indirect 注释的传递依赖。

require (
    github.com/gin-gonic/gin v1.9.1          // ← 提取这个
    github.com/go-sql-driver/mysql v1.7.1     // ← 提取这个
    golang.org/x/net v0.10.0 // indirect      // ← 忽略这个
)

Python (requirements.txt)

逐行读取，每行一个依赖。忽略注释行（以 # 开头）和空行。

flask==2.3.2          # ← 提取
requests>=2.28.0      # ← 提取
# dev dependency       # ← 忽略

Python (pyproject.toml)

读取 [project.dependencies] 或 [tool.poetry.dependencies] 中的依赖。不要读取 [project.optional-dependencies] 或 [tool.poetry.dev-dependencies]。

Rust (Cargo.toml)

读取 [dependencies] 部分。不要读取 [dev-dependencies] 或 [build-dependencies]。

.NET (*.csproj)

读取 <PackageReference> 标签中的 Include 和 Version 属性。

1.2 生成待查询列表

将提取的依赖整理成一个列表，格式如下：

1. express (^4.18.2) — npm
2. lodash (^4.17.21) — npm
3. github.com/gin-gonic/gin (v1.9.1) — go
...

通知用户：

共检测到 N 个直接依赖，接下来将逐一查询其协议信息。

1.3 处理空依赖

如果依赖清单为空（没有直接依赖），通知用户：

项目没有直接依赖，无需进行协议审计。流程结束。

完成后更新 checklist：

☑ Step 1: 提取直接依赖 — 从依赖清单中提取所有直接依赖

Step 2: 查询协议

目标： 使用 WebSearch 查询每个直接依赖的协议类型。

2.1 逐一搜索依赖协议

对每个依赖，使用 WebSearch 进行搜索。使用以下推荐搜索词模板以提高准确性：

生态系统	推荐搜索词	示例
npm	`<包名> npm package license`	`express npm package license`
Go	`<模块路径> go module license`	`github.com/gin-gonic/gin go module license`
Python	`<包名> pypi license`	`flask pypi license`
Rust	`<包名> crates.io license`	`serde crates.io license`
.NET	`<包名> nuget license`	`Newtonsoft.Json nuget license`

2.2 记录搜索结果

对每个依赖，记录以下信息：

SPDX 协议标识符：如 MIT、Apache-2.0、GPL-3.0-only 等。参考本页末尾的协议兼容性参考表进行标准化。
来源 URL：协议信息的来源页面（如 npm 包页面、GitHub 仓库等）
确认状态：已确认 或 待确认
开源状态：判定该协议是否为开源协议
- ✅ 开源：经 OSI 认证的开源协议（MIT、BSD-2-Clause、BSD-3-Clause、ISC、Apache-2.0、GPL-2.0、GPL-3.0、LGPL-2.1、LGPL-3.0、MPL-2.0、AGPL-3.0、Unlicense、CC0-1.0 等）
- ⚠️ 非传统开源：非 OSI 认证但有条件允许使用的协议（CC-BY-4.0、CC-BY-SA-4.0 等）；或限制商业用途的协议（CC-BY-NC-4.0 等）
- ❌ 非开源：自定义协议、私有协议、商业协议（BSL-1.1、SSPL-1.0 等限制性协议也归入此类）
- ❌ 无法验证：UNKNOWN，无法通过搜索确定协议类型

2.2.1 搜索结果记录示例

依赖名称	协议 (SPDX)	来源 URL	确认状态	开源状态
express	MIT	https://www.npmjs.com/package/express	已确认	✅ 开源
some-lib	CC-BY-NC-4.0	https://github.com/xxx/some-lib	已确认	⚠️ 非传统开源
private-tool	自定义协议	https://example.com/private-tool	已确认	❌ 非开源
unknown-lib	UNKNOWN	—	待确认	❌ 无法验证

2.3 交叉验证不确定的结果

如果某个依赖的搜索结果不明确（多个来源给出不同协议），进行二次搜索：

搜索词：<包名> github LICENSE file
或搜索词：<包名> SPDX license identifier

如果二次搜索仍无法确定，将该依赖标记为 UNKNOWN。

2.4 批量搜索进度通知

每完成 5 个依赖的搜索，通知用户当前进度：

协议查询进度：已完成 10/25，目前未发现风险协议。

或：

协议查询进度：已完成 15/25，发现 2 个需要关注的协议（GPL-3.0、AGPL-3.0）。

完成后更新 checklist：

☑ Step 2: 查询协议 — 使用 WebSearch 查询每个依赖的协议

Step 3: 生成 LICENSE.LIST

目标： 在项目根目录生成 LICENSE.LIST 文件。

3.1 文件格式

使用以下 Markdown 格式生成 LICENSE.LIST 文件：

markdown

# 依赖协议清单 (LICENSE.LIST)

> 本文件由 AI 助手自动生成，记录项目所有直接依赖的协议信息。
> 生成时间：YYYY-MM-DD
> 审计工具：AI 依赖协议审计 (https://tpscsm-docs.pages.dev/license-audit/)

## 统计摘要

| 协议类型 | 数量 | 风险等级 |
|---------|------|---------|
| MIT | 15 | ✅ 低风险 |
| Apache-2.0 | 5 | ✅ 低风险 |
| BSD-3-Clause | 3 | ✅ 低风险 |
| GPL-3.0-only | 1 | ⚠️ 需关注 |
| UNKNOWN | 1 | ❌ 需手动确认 |

**总计：** 25 个直接依赖

## 依赖详情

| 序号 | 依赖名称 | 版本 | 协议 (SPDX) | 来源 | 风险 | 备注 |
|------|---------|------|-------------|------|------|------|
| 1 | express | ^4.18.2 | MIT | https://www.npmjs.com/package/express | ✅ | |
| 2 | some-gpl-lib | ^1.0.0 | GPL-3.0-only | https://github.com/xxx/some-gpl-lib | ⚠️ | 分发时须开源 |
| 3 | unknown-lib | ^2.0.0 | UNKNOWN | — | ❌ | 需手动确认协议 |

3.2 风险标记规则

✅ 低风险：MIT、BSD-2-Clause、BSD-3-Clause、ISC、Apache-2.0、Unlicense、CC0-1.0
⚠️ 需关注：GPL-2.0、GPL-3.0、AGPL-3.0、LGPL-2.1、LGPL-3.0、MPL-2.0、CC-BY-SA-4.0、BSL-1.1、SSPL-1.0
❌ 需手动确认：UNKNOWN、CC-BY-NC-4.0、自定义协议

3.3 写入文件

将生成的内容写入项目根目录的 LICENSE.LIST 文件。如果文件已存在，先通知用户：

项目中已存在 LICENSE.LIST 文件，是否覆盖？

等待用户确认后再写入。

完成后更新 checklist：

☑ Step 3: 生成 LICENSE.LIST — 生成依赖协议清单文件

Step 4: 生成合规 LICENSE

目标： 在项目根目录生成 LICENSE 合规参考报告。

重要说明： 这是一份合规参考报告，不是具有法律约束力的协议文件。目的是帮助开发者了解项目的协议合规情况。

4.1 分析协议兼容性

根据本页末尾的协议兼容性参考表，分析所有依赖的协议，确定：

最严格的继承限制：如果包含 GPL 依赖，项目在分发时须遵守 GPL 要求
所有 attribution 要求：哪些协议要求保留版权声明（MIT、BSD、Apache 等）
商用限制：是否有依赖禁止商业用途（CC-NC 等）
分发限制：是否有依赖限制分发方式
项目协议与依赖协议兼容性：逐一检查每个依赖协议与项目协议的兼容性

4.1.1 项目协议与依赖协议兼容性检查

使用本页附录 A 中的协议兼容性矩阵，逐一检查项目协议（Step 0.5 识别的协议）与每个依赖协议的兼容关系：

在矩阵中找到项目协议所在的行
找到依赖协议所在的列
查看交叉点的判定结果：
- ✅ — 兼容，无需额外操作
- ⚠️ — 有条件兼容，需要满足特定条件（参见矩阵脚注）
- ❌ — 不兼容，分发时存在协议冲突

对于每个 ❌ 不兼容的依赖，记录：

冲突原因（如"MIT 项目不能在分发时包含 GPL-3.0 依赖"）
修复建议：
- 方案 A：将项目协议更换为与该依赖兼容的协议
- 方案 B：替换该依赖为使用兼容协议的替代库
- 方案 C：移除该依赖

如果依赖协议不在矩阵中，参见附录 A 的"矩阵外协议处理规则"。

4.2 文件格式

使用以下格式生成 LICENSE 文件：

markdown

# 项目协议合规报告

> 本文件由 AI 助手自动生成，旨在帮助了解项目的协议合规情况。
> 本文件为合规参考，不构成法律建议。如有疑问请咨询法律专业人士。
> 生成时间：YYYY-MM-DD
> 审计工具：AI 依赖协议审计 (https://tpscsm-docs.pages.dev/license-audit/)

## 项目协议

[此处填写项目自身的协议，如果项目已有协议则引用，如果没有则提示用户选择]

## 版权协议合规结论

> 本结论基于项目协议与所有直接依赖协议的兼容性分析，以开源分发为前提。

### ✅ 合规 — 可开源分发

[如果所有依赖协议与项目协议兼容，且所有依赖均为开源协议:]

项目协议 `<项目 SPDX>` 与所有 XX 个直接依赖的协议兼容，满足开源分发要求。

分发时须满足以下义务：
- [列出 attribution 要求]
- [列出其他分发义务]

### ❌ 不合规 — 不可分发

[如果存在不兼容或非开源依赖:]

项目协议 `<项目 SPDX>` 与以下依赖存在合规问题：

| 序号 | 依赖名称 | 依赖协议 | 问题类型 | 冲突说明 | 修复建议 |
|------|---------|---------|---------|---------|---------|
| 1 | some-gpl-lib | GPL-3.0 | 协议不兼容 | MIT 项目不能包含 GPL 依赖并分发 | 将项目改为 GPL-3.0 或移除该依赖 |
| 2 | unknown-lib | UNKNOWN | 协议未知 | 无法验证合规性 | 联系维护者确认协议或替换 |
| 3 | private-tool | 自定义协议 | 非开源 | 不满足开源分发要求 | 替换为开源替代库 |

**在解决上述问题之前，项目不应进行公开分发。**

## 依赖协议摘要

- 宽松协议 (MIT/BSD/ISC): XX 个 — ✅ 无特殊限制
- Apache-2.0: XX 个 — ✅ 需保留 NOTICE 和版权声明
- 弱 Copyleft (LGPL/MPL): XX 个 — ⚠️ 修改部分须开源
- 强 Copyleft (GPL/AGPL): XX 个 — ⚠️ 分发时须开源衍生作品
- 未知协议: XX 个 — ❌ 需手动确认

## 协议兼容性详情

基于项目协议 `<项目 SPDX>` 与各依赖协议的逐项判定结果：

### ✅ 兼容的依赖

| 依赖名称 | 依赖协议 | 兼容性 | 分发义务 |
|---------|---------|--------|---------|
| express | MIT | ✅ 兼容 | 保留版权声明 |
| lodash | MIT | ✅ 兼容 | 保留版权声明 |
| axios | MIT | ✅ 兼容 | 保留版权声明 |

### ⚠️ 有条件兼容的依赖

| 依赖名称 | 依赖协议 | 条件 | 当前使用方式是否满足 |
|---------|---------|------|-------------------|
| some-lgpl-lib | LGPL-3.0 | 动态链接可豁免 | [需确认] |

### ❌ 不兼容的依赖

| 依赖名称 | 依赖协议 | 冲突原因 | 修复建议 |
|---------|---------|---------|---------|
| some-gpl-lib | GPL-3.0 | 项目协议 MIT 与 GPL-3.0 不兼容 | 方案 A/B/C |

## 第三方协议声明

[按协议类型分组，列出每个依赖的版权声明]

### MIT License

以下组件使用 MIT 协议：

- express (^4.18.2) — Copyright (c) 2009-2014 TJ Holowaychuk
- lodash (^4.17.21) — Copyright JS Foundation and other contributors

MIT 协议全文：
[MIT 协议文本]

### Apache License 2.0

以下组件使用 Apache-2.0 协议：

- xxx — Copyright 20xx xxx

Apache-2.0 协议全文：
[Apache 协议文本]

## 风险提示与建议

1. [根据实际情况给出具体建议]
2. 建议定期重新审计依赖协议（可使用本审计工具的 Skill 功能自动检查）
3. 如有法律疑问，请咨询专业法律顾问

4.3 处理已有 LICENSE 文件

如果项目中已存在 LICENSE 文件：

读取现有 LICENSE 文件内容
将现有内容作为"项目协议"部分保留
通知用户：

项目中已存在 LICENSE 文件。我会将现有协议内容保留在"项目协议"部分，并在后面追加依赖合规分析。是否继续？

等待用户确认后再写入。

完成后更新 checklist：

☑ Step 4: 生成 LICENSE — 生成合规参考报告

Step 5: 安装持续检查 Skill

目标： 在项目中安装一个 Skill，确保后续依赖变更时能自动触发协议检查。

5.1 检测当前 AI 编辑器

判断你当前运行在哪个 AI 编辑器中：

判断方式	编辑器	Skill 路径
你能调用 Claude Code 的内置工具（如 Read、Write、Edit、Bash）	Claude Code	`.claude/skills/license-audit/SKILL.md`
你运行在 Cursor IDE 中，能看到 `.cursor/` 目录	Cursor	`.cursor/rules/license-audit.mdc`
你运行在 Google Antigravity 中，能看到 `.agent/` 目录或 `~/.gemini/` 配置	Google Antigravity	`.agent/skills/license-audit/SKILL.md`

如果无法确定，询问用户：

你使用的是哪个 AI 编辑器？
Claude Code
Cursor
Google Antigravity
其他

5.2 写入 Skill 文件

根据检测到的编辑器类型，从本页末尾的 Skill 模板附录 中复制对应格式的模板，写入项目中。

Claude Code

创建目录和文件：

路径：.claude/skills/license-audit/SKILL.md
内容：使用本页 附录 B: Claude Code Skill 模板 中的完整内容

Cursor

创建文件：

路径：.cursor/rules/license-audit.mdc
内容：使用本页 附录 C: Cursor Skill 模板 中的完整内容

Google Antigravity

创建目录和文件：

路径：.agent/skills/license-audit/SKILL.md
内容：使用本页 附录 D: Google Antigravity Skill 模板 中的完整内容

5.3 通知用户

写入完成后，通知用户：

已安装依赖协议持续检查 Skill。当你添加新依赖、更新依赖版本时，AI 助手会自动提醒你重新检查协议合规性。
Skill 文件位置：[具体路径]

完成后更新 checklist：

☑ Step 5: 安装 Skill — 安装依赖协议持续检查 Skill

Step 6: 生成审计报告

目标： 生成一份完整的中文审计报告，总结本次审计结果。

6.1 报告模板

# 依赖协议审计报告

## 项目信息
- 项目名称：xxx
- 项目路径：xxx
- 项目类型：xxx
- 审计时间：YYYY-MM-DD

## 版权协议合规结论

**最终判定：** ✅ 合规 — 可开源分发 / ❌ 不合规 — 不可分发

[如果合规:]
项目协议 `<SPDX>` 与所有 XX 个直接依赖协议兼容。分发时须满足以下义务：
- [attribution 要求列表]

[如果不合规:]
项目协议 `<SPDX>` 存在以下合规问题：

| 依赖名称 | 依赖协议 | 问题类型 | 修复建议 |
|---------|---------|---------|---------|
| xxx | GPL-3.0 | 协议不兼容 | 更换项目协议或移除依赖 |
| xxx | UNKNOWN | 协议未知 | 联系维护者确认或替换 |

## 审计结果摘要

| 指标 | 数值 |
|------|------|
| 直接依赖总数 | XX |
| 已确认协议 | XX |
| 未确认协议 | XX |
| 低风险 (✅) | XX |
| 需关注 (⚠️) | XX |
| 需确认 (❌) | XX |

## 协议分布

| 协议 | 数量 | 占比 |
|------|------|------|
| MIT | XX | XX% |
| Apache-2.0 | XX | XX% |
| ... | ... | ... |

## 风险发现

### 协议不兼容

[如果存在与项目协议不兼容的依赖:]

| 依赖名称 | 依赖协议 | 项目协议 | 冲突说明 | 修复建议 |
|---------|---------|---------|---------|---------|
| xxx | GPL-3.0 | MIT | MIT 不能包含 GPL 依赖并分发 | 更换项目协议为 GPL-3.0 或移除该依赖 |

[如果不存在不兼容:]
未发现协议不兼容问题。✅

### 协议未知

[如果存在 UNKNOWN 协议的依赖:]

| 依赖名称 | 版本 | 处理建议 |
|---------|------|---------|
| xxx | ^1.0.0 | 手动查看仓库 LICENSE 文件，或联系维护者 |
| xxx | ^2.0.0 | 考虑替换为协议明确的替代库 |

[如果不存在 UNKNOWN:]
所有依赖协议均已确认。✅

## 生成文件

| 文件 | 路径 | 说明 |
|------|------|------|
| LICENSE.LIST | ./LICENSE.LIST | 依赖协议清单 |
| LICENSE | ./LICENSE | 合规参考报告 |

## 已安装 Skill

| 编辑器 | Skill 路径 | 说明 |
|--------|-----------|------|
| [编辑器名] | [路径] | 依赖变更时自动触发协议检查 |

## 后续建议

1. 请人工确认所有标记为 ❌ 的依赖协议
2. 如果项目需要分发，请特别关注 ⚠️ 标记的 Copyleft 协议依赖
3. 依赖更新后，AI 助手会通过已安装的 Skill 自动提醒重新检查
4. 建议每季度进行一次完整的依赖协议审计
5. 如有法律疑问，请咨询专业法律顾问

根据实际审计结果填充报告内容。

完成后更新 checklist：

☑ Step 6: 生成审计报告 — 生成完整的中文审计报告

附录 A: 协议兼容性参考表

以下参考表供 AI 助手在生成合规报告时引用，用于判断各协议的类型、限制和风险等级。

宽松协议 (Permissive)

SPDX 标识符	协议名称	关键要求	风险等级
`MIT`	MIT License	保留版权声明和协议文本	✅ 低
`BSD-2-Clause`	BSD 2-Clause	保留版权声明	✅ 低
`BSD-3-Clause`	BSD 3-Clause	保留版权声明，禁止用作者名字推广	✅ 低
`ISC`	ISC License	保留版权声明	✅ 低
`Apache-2.0`	Apache License 2.0	保留声明 + 标注变更 + 包含 NOTICE 文件 + 专利授权	✅ 低

弱 Copyleft

SPDX 标识符	协议名称	关键要求	风险等级
`LGPL-2.1-only` / `LGPL-2.1-or-later`	GNU LGPL 2.1	修改库本身须开源；动态链接可豁免	⚠️ 中
`LGPL-3.0-only` / `LGPL-3.0-or-later`	GNU LGPL 3.0	修改库本身须开源；动态链接可豁免	⚠️ 中
`MPL-2.0`	Mozilla Public License 2.0	修改的源文件须开源（文件级 copyleft）	⚠️ 中

强 Copyleft

SPDX 标识符	协议名称	关键要求	风险等级
`GPL-2.0-only` / `GPL-2.0-or-later`	GNU GPL 2.0	衍生作品必须使用同一协议开源	⚠️ 高
`GPL-3.0-only` / `GPL-3.0-or-later`	GNU GPL 3.0	衍生作品必须使用同一协议开源 + 禁止 Tivoization	⚠️ 高
`AGPL-3.0-only` / `AGPL-3.0-or-later`	GNU AGPL 3.0	通过网络提供服务也视为分发，须开源	⚠️ 高

非商用 / 限制性协议

SPDX 标识符	协议名称	关键要求	风险等级
`CC-BY-NC-4.0`	CC BY-NC 4.0	禁止商业用途	❌ 需确认
`CC-BY-NC-SA-4.0`	CC BY-NC-SA 4.0	禁止商业用途 + 衍生作品须同协议	❌ 需确认
`BSL-1.1`	Business Source License 1.1	有使用限制期（通常 3-4 年后转为开源）	⚠️ 高
`SSPL-1.0`	Server Side Public License	提供服务须开源整个服务平台	⚠️ 高

公共领域

SPDX 标识符	协议名称	关键要求	风险等级
`Unlicense`	The Unlicense	无限制，公共领域	✅ 无
`CC0-1.0`	CC0 1.0	无限制，公共领域	✅ 无

Creative Commons

SPDX 标识符	协议名称	关键要求	风险等级
`CC-BY-4.0`	CC BY 4.0	须署名	✅ 低
`CC-BY-SA-4.0`	CC BY-SA 4.0	须署名 + 衍生作品须同协议	⚠️ 中

协议继承规则

当项目同时包含多种协议的依赖时，遵循以下继承规则：

Copyleft 传染性：如果包含 GPL/AGPL 依赖，且以静态链接或源码方式使用，项目在分发时须遵守 GPL/AGPL 条款
LGPL 豁免：LGPL 依赖如果以动态链接方式使用（如 npm 包引用），通常无需开源项目代码
Attribution 合并：所有要求 attribution 的协议（MIT、BSD、Apache 等），其版权声明须在 LICENSE 文件中列出
最严格原则：当多个限制冲突时，以最严格的限制为准
商用限制继承：任何一个依赖禁止商用，整个项目在商用场景下须移除该依赖

分发场景下的协议兼容性矩阵

以下矩阵用于判定"项目协议"与"依赖协议"在开源分发场景下的兼容性。行为项目协议，列为依赖协议。

项目协议 ↓ \ 依赖协议 →	MIT	BSD-3-Clause	Apache-2.0	LGPL-2.1	LGPL-3.0	MPL-2.0	GPL-2.0	GPL-3.0	AGPL-3.0
MIT	✅	✅	✅	⚠️¹	⚠️¹	⚠️²	❌	❌	❌
Apache-2.0	✅	✅	✅	⚠️¹	⚠️¹	⚠️²	❌	❌	❌
GPL-2.0-only	✅	✅	❌³	✅	❌⁴	❌⁵	✅	❌⁴	❌
GPL-3.0-only	✅	✅	✅	✅	✅	✅	❌⁴	✅	❌
AGPL-3.0-only	✅	✅	✅	✅	✅	✅	❌⁴	✅	✅

脚注说明：

¹ LGPL 有条件兼容：LGPL 依赖如果以动态链接方式使用（如 npm 包引用、pip 安装的独立包），通常可以豁免 copyleft 要求，项目无需开源。但如果以静态链接或源码嵌入方式使用（如 Go 语言的静态编译），则修改部分须以 LGPL 开源。在 Node.js/Python/Rust 生态中通常为动态链接，可视为兼容。
² MPL-2.0 文件级 copyleft：MPL-2.0 要求对修改过的源文件以 MPL-2.0 开源，但不要求整个项目开源。如果只是引用 MPL 依赖而未修改其源码，则兼容；如果修改了 MPL 依赖的源文件，被修改的文件须以 MPL-2.0 发布。
³ Apache-2.0 与 GPL-2.0 不兼容：Apache-2.0 包含专利授权条款，与 GPL-2.0 的条款存在冲突。但 Apache-2.0 与 GPL-3.0 兼容（FSF 已确认）。
⁴ GPL 版本不兼容：GPL-2.0-only 与 GPL-3.0-only 互不兼容。但 GPL-2.0-or-later 与 GPL-3.0 兼容（因为 "or later" 允许升级到 GPL-3.0）。判定时须注意依赖声明的是 -only 还是 -or-later。
⁵ MPL-2.0 与 GPL-2.0 的兼容性：MPL-2.0 第 3 条允许将代码转为 GPL-2.0+ 分发，但 GPL-2.0-only 不接受此转换，因此不兼容。与 GPL-3.0 兼容。

矩阵外协议处理规则

如果依赖的协议不在上述矩阵中（如 Artistic License、EUPL、Zlib、0BSD 等），按以下步骤处理：

搜索兼容性信息：使用 WebSearch 搜索 "<依赖协议名>" compatibility with "<项目协议名>""
查询 OSI 认证：搜索 "<协议名>" OSI approved license，确认是否为 OSI 认证的开源协议
参考 FSF 列表：搜索 "<协议名>" FSF GPL compatible，查看 FSF 是否认定该协议与 GPL 兼容
无法确定时：标记为 ⚠️ 需人工确认，在审计报告中提示用户手动核实

常见的矩阵外协议快速参考：

协议	类型	与 MIT 兼容	与 GPL-3.0 兼容	备注
0BSD	宽松	✅	✅	比 MIT 更宽松，无需保留声明
Zlib	宽松	✅	✅	类似 MIT，常见于游戏库
Artistic-2.0	弱 Copyleft	✅	✅	Perl 生态常见
EUPL-1.2	强 Copyleft	❌	✅	欧盟公共许可证，与 GPL-3.0 兼容
WTFPL	宽松	✅	✅	非正式协议，等同公共领域

附录 B: Claude Code Skill 模板

以下是 Claude Code 的 Skill 模板完整内容。在 Step 5 中，将此内容写入 .claude/skills/license-audit/SKILL.md。

markdown

---
description: 依赖协议合规检查 — 当依赖文件变更时自动检查协议合规性
---

# 依赖协议审计 Skill

## 触发条件

当以下任一文件被修改时，自动触发本 Skill：

- `package.json`（Node.js 项目）
- `go.mod`（Go 项目）
- `requirements.txt` 或 `pyproject.toml`（Python 项目）
- `Cargo.toml`（Rust 项目）
- `*.csproj`（.NET 项目）

## 执行指令

当检测到上述依赖文件变更时，执行以下操作：

### 1. 检测变更的依赖

对比当前依赖文件与 `LICENSE.LIST` 中已记录的依赖，找出：
- **新增的依赖**：在依赖文件中存在但 LICENSE.LIST 中没有的
- **版本变更的依赖**：版本号发生变化的
- **移除的依赖**：在 LICENSE.LIST 中存在但依赖文件中已删除的

### 2. 查询新增/变更依赖的协议

对新增或版本变更的依赖，使用 WebSearch 查询其协议：
- 搜索词模板：`<包名> <生态系统> license`（如 `express npm package license`）
- 如果搜索结果不明确，进行二次搜索交叉验证
- 无法确定的标记为 UNKNOWN

### 3. 检查协议兼容性

对新增或版本变更的依赖，检查其协议与项目协议的兼容性：
- 读取项目根目录的 LICENSE 文件，识别项目协议的 SPDX 标识符
- 对照协议兼容性矩阵（参见 https://tpscsm-docs.pages.dev/license-audit/），判定每个新增依赖的协议与项目协议是否兼容
- 兼容（✅）：无需额外操作
- 有条件兼容（⚠️）：提示用户注意使用方式
- 不兼容（❌）：警告用户存在协议冲突，给出修复建议

### 4. 更新 LICENSE.LIST

- 添加新增依赖的协议信息
- 更新版本变更的依赖信息
- 移除已删除的依赖条目
- 更新统计摘要

### 5. 更新 LICENSE

- 重新分析协议兼容性
- 更新继承限制部分
- 更新第三方协议声明

### 6. 通知用户

完成后通知用户变更结果：

> 依赖协议检查完成：
> - 新增 X 个依赖，协议均为 [协议列表]
> - 更新 X 个依赖版本
> - 移除 X 个依赖
> - 兼容性检查：✅ 所有新增依赖与项目协议兼容 / ❌ 以下依赖与项目协议不兼容：[列表]
> - 风险提示：[如有新增风险协议则列出]

## 重要说明

- 只检查直接依赖，不检查传递依赖
- 协议信息通过 WebSearch 查询，可能存在不准确的情况
- UNKNOWN 协议的依赖需要用户手动确认
- 完整的协议兼容性参考表请访问：https://tpscsm-docs.pages.dev/license-audit/

附录 C: Cursor Skill 模板

以下是 Cursor 的 Skill 模板完整内容。在 Step 5 中，将此内容写入 .cursor/rules/license-audit.mdc。

markdown

---
description: "依赖协议合规检查 — 当依赖文件变更时自动检查协议合规性"
globs: ["package.json", "go.mod", "requirements.txt", "pyproject.toml", "Cargo.toml", "*.csproj"]
---

# 依赖协议审计规则

当匹配的依赖文件被修改时，执行以下协议合规检查：

## 检测变更

对比当前依赖文件与项目根目录的 `LICENSE.LIST` 中已记录的依赖，找出：
- **新增的依赖**：在依赖文件中存在但 LICENSE.LIST 中没有的
- **版本变更的依赖**：版本号发生变化的
- **移除的依赖**：在 LICENSE.LIST 中存在但依赖文件中已删除的

## 查询协议

对新增或版本变更的依赖，使用 WebSearch 查询其协议：
- npm 包搜索：`<包名> npm package license`
- Go 模块搜索：`<模块路径> go module license`
- Python 包搜索：`<包名> pypi license`
- Rust 包搜索：`<包名> crates.io license`
- .NET 包搜索：`<包名> nuget license`

如果搜索结果不明确，进行二次搜索：`<包名> github LICENSE file`

## 检查协议兼容性

对新增或版本变更的依赖，检查其协议与项目协议的兼容性：
- 读取项目 LICENSE 文件，识别项目协议
- 对照协议兼容性矩阵（参见 https://tpscsm-docs.pages.dev/license-audit/），判定兼容性
- 不兼容时警告用户并给出修复建议（更换项目协议/替换依赖/移除依赖）

## 更新文件

1. 更新 `LICENSE.LIST`：添加/更新/移除依赖条目，更新统计摘要
2. 更新 `LICENSE`：重新分析协议兼容性，更新继承限制和第三方声明

## 风险标记

- ✅ 低风险：MIT、BSD、ISC、Apache-2.0、Unlicense、CC0-1.0
- ⚠️ 需关注：GPL、AGPL、LGPL、MPL、BSL、SSPL
- ❌ 需确认：UNKNOWN、CC-BY-NC、自定义协议

## 通知用户

完成后通知用户变更结果：

> 依赖协议检查完成：
> - 新增 X 个依赖，协议均为 [协议列表]
> - 更新 X 个依赖版本
> - 移除 X 个依赖
> - 兼容性检查：✅ 所有新增依赖与项目协议兼容 / ❌ 以下依赖与项目协议不兼容：[列表]
> - 风险提示：[如有新增风险协议则列出]

## 重要说明

- 只检查直接依赖（dependencies），不检查 devDependencies 和传递依赖
- UNKNOWN 协议需要用户手动确认
- 完整的协议兼容性参考表：https://tpscsm-docs.pages.dev/license-audit/

附录 D: Google Antigravity Skill 模板

以下是 Google Antigravity 的 Skill 模板完整内容。在 Step 5 中，将此内容写入 .agent/skills/license-audit/SKILL.md。

markdown

---
name: license-audit
description: 依赖协议合规检查 — 当依赖文件变更时自动检查协议合规性
triggers:
  - file_changed: "package.json"
  - file_changed: "go.mod"
  - file_changed: "requirements.txt"
  - file_changed: "pyproject.toml"
  - file_changed: "Cargo.toml"
  - file_changed: "*.csproj"
---

# 依赖协议审计 Skill

## 何时使用

当用户修改了依赖文件（package.json、go.mod、requirements.txt、pyproject.toml、Cargo.toml、*.csproj）时自动触发。

## 不要使用

当用户只是阅读或查看依赖文件而没有修改时，不要触发本 Skill。

## 执行步骤

### 1. 检测变更的依赖

对比当前依赖文件与项目根目录的 `LICENSE.LIST` 中已记录的依赖，找出：
- **新增的依赖**：在依赖文件中存在但 LICENSE.LIST 中没有的
- **版本变更的依赖**：版本号发生变化的
- **移除的依赖**：在 LICENSE.LIST 中存在但依赖文件中已删除的

### 2. 查询新增/变更依赖的协议

对新增或版本变更的依赖，使用 WebSearch 查询其协议：
- npm 包：搜索 `<包名> npm package license`
- Go 模块：搜索 `<模块路径> go module license`
- Python 包：搜索 `<包名> pypi license`
- Rust 包：搜索 `<包名> crates.io license`
- .NET 包：搜索 `<包名> nuget license`

如果搜索结果不明确，二次搜索：`<包名> github LICENSE file`
无法确定的标记为 UNKNOWN。

### 3. 检查协议兼容性

对新增或版本变更的依赖，检查其协议与项目协议的兼容性：
- 读取项目根目录的 LICENSE 文件，识别项目协议的 SPDX 标识符
- 对照协议兼容性矩阵（参见 https://tpscsm-docs.pages.dev/license-audit/），判定兼容性
- 不兼容时警告用户并给出修复建议

### 4. 更新 LICENSE.LIST

- 添加新增依赖的协议信息
- 更新版本变更的依赖信息
- 移除已删除的依赖条目
- 更新统计摘要

### 5. 更新 LICENSE

- 重新分析协议兼容性
- 更新继承限制部分
- 更新第三方协议声明

### 6. 通知用户

完成后通知用户变更结果：

> 依赖协议检查完成：
> - 新增 X 个依赖，协议均为 [协议列表]
> - 更新 X 个依赖版本
> - 移除 X 个依赖
> - 兼容性检查：✅ 所有新增依赖与项目协议兼容 / ❌ 以下依赖与项目协议不兼容：[列表]
> - 风险提示：[如有新增风险协议则列出]

## 风险分类

- ✅ 低风险：MIT、BSD、ISC、Apache-2.0、Unlicense、CC0-1.0
- ⚠️ 需关注：GPL、AGPL、LGPL、MPL、BSL、SSPL
- ❌ 需确认：UNKNOWN、CC-BY-NC、自定义协议

## 重要说明

- 只检查直接依赖，不检查传递依赖
- UNKNOWN 协议需要用户手动确认
- 完整参考表：https://tpscsm-docs.pages.dev/license-audit/

常见问题

Q: 为什么只审计直接依赖，不包含传递依赖？

直接依赖是开发者主动选择引入的，其协议风险由开发者直接承担。传递依赖数量通常远大于直接依赖（npm 项目可达数百个），逐一 WebSearch 查询不现实。如需审计传递依赖，建议使用专业的协议扫描工具。

Q: UNKNOWN 协议的依赖怎么处理？

手动访问该依赖的源代码仓库，查找 LICENSE 文件
联系依赖的维护者确认协议
如果无法确认，考虑替换为协议明确的替代依赖

Q: 协议信息不准确怎么办？

WebSearch 查询的协议信息可能存在不准确的情况。建议：

对 ⚠️ 和 ❌ 标记的依赖手动核实
直接查看依赖的 GitHub 仓库中的 LICENSE 文件
查看包管理器（npm、PyPI 等）上的官方协议声明

Q: Skill 安装后如何验证？

安装 Skill 后，尝试添加一个新依赖（如 npm install dayjs），然后让 AI 助手处理。如果 Skill 正常工作，AI 会自动提示需要更新 LICENSE.LIST 和 LICENSE。

依赖协议审计 - AI 自动化引导 ​

面向 AI 助手的说明 ​

分发场景前提 ​

强制执行规则 ​

Step 0: 环境检测 ​

0.1 检测项目类型 ​

0.2 处理未识别的项目 ​

Step 0.5: 检查项目自身协议 ​

0.5.1 读取 LICENSE 文件 ​

0.5.2 识别协议类型 ​

0.5.3 处理特殊情况 ​

场景 A：有 LICENSE 文件且可识别 ​

场景 B：有 LICENSE 文件但无法识别 ​

场景 C：没有 LICENSE 文件 ​

Step 1: 提取直接依赖 ​

1.1 读取依赖清单文件 ​

Node.js (package.json) ​

Go (go.mod) ​

Python (requirements.txt) ​

Python (pyproject.toml) ​

Rust (Cargo.toml) ​

.NET (*.csproj) ​

1.2 生成待查询列表 ​

1.3 处理空依赖 ​

Step 2: 查询协议 ​

2.1 逐一搜索依赖协议 ​

2.2 记录搜索结果 ​

2.2.1 搜索结果记录示例 ​

2.3 交叉验证不确定的结果 ​

2.4 批量搜索进度通知 ​

Step 3: 生成 LICENSE.LIST ​

3.1 文件格式 ​

3.2 风险标记规则 ​

3.3 写入文件 ​

Step 4: 生成合规 LICENSE ​

4.1 分析协议兼容性 ​

4.1.1 项目协议与依赖协议兼容性检查 ​

4.2 文件格式 ​

4.3 处理已有 LICENSE 文件 ​

Step 5: 安装持续检查 Skill ​

5.1 检测当前 AI 编辑器 ​

5.2 写入 Skill 文件 ​

Claude Code ​

Cursor ​

Google Antigravity ​

5.3 通知用户 ​

Step 6: 生成审计报告 ​

6.1 报告模板 ​

附录 A: 协议兼容性参考表 ​

宽松协议 (Permissive) ​

弱 Copyleft ​

强 Copyleft ​

非商用 / 限制性协议 ​

公共领域 ​

Creative Commons ​

协议继承规则 ​

分发场景下的协议兼容性矩阵 ​

矩阵外协议处理规则 ​

附录 B: Claude Code Skill 模板 ​

附录 C: Cursor Skill 模板 ​

附录 D: Google Antigravity Skill 模板 ​

常见问题 ​

Q: 为什么只审计直接依赖，不包含传递依赖？ ​

Q: UNKNOWN 协议的依赖怎么处理？ ​

Q: 协议信息不准确怎么办？ ​

Q: Skill 安装后如何验证？ ​

依赖协议审计 - AI 自动化引导

面向 AI 助手的说明

分发场景前提

强制执行规则

Step 0: 环境检测

0.1 检测项目类型

0.2 处理未识别的项目

Step 0.5: 检查项目自身协议

0.5.1 读取 LICENSE 文件

0.5.2 识别协议类型

0.5.3 处理特殊情况

场景 A：有 LICENSE 文件且可识别

场景 B：有 LICENSE 文件但无法识别

场景 C：没有 LICENSE 文件

Step 1: 提取直接依赖

1.1 读取依赖清单文件

Node.js (package.json)

Go (go.mod)

Python (requirements.txt)

Python (pyproject.toml)

Rust (Cargo.toml)

.NET (*.csproj)

1.2 生成待查询列表

1.3 处理空依赖

Step 2: 查询协议

2.1 逐一搜索依赖协议

2.2 记录搜索结果

2.2.1 搜索结果记录示例

2.3 交叉验证不确定的结果

2.4 批量搜索进度通知

Step 3: 生成 LICENSE.LIST

3.1 文件格式

3.2 风险标记规则

3.3 写入文件

Step 4: 生成合规 LICENSE

4.1 分析协议兼容性

4.1.1 项目协议与依赖协议兼容性检查

4.2 文件格式

4.3 处理已有 LICENSE 文件

Step 5: 安装持续检查 Skill

5.1 检测当前 AI 编辑器

5.2 写入 Skill 文件

Claude Code

Cursor

Google Antigravity

5.3 通知用户

Step 6: 生成审计报告

6.1 报告模板

附录 A: 协议兼容性参考表

宽松协议 (Permissive)

弱 Copyleft

强 Copyleft

非商用 / 限制性协议

公共领域

Creative Commons

协议继承规则

分发场景下的协议兼容性矩阵

矩阵外协议处理规则

附录 B: Claude Code Skill 模板

附录 C: Cursor Skill 模板

附录 D: Google Antigravity Skill 模板

常见问题

Q: 为什么只审计直接依赖，不包含传递依赖？

Q: UNKNOWN 协议的依赖怎么处理？

Q: 协议信息不准确怎么办？

Q: Skill 安装后如何验证？