mcpField
L
license-analysis

license-analysis

github.com/seb1n开发232117 次安装11 周前更新
代码仓库

关于 license-analysis

license-analysis 是面向开发者和团队的技能，用于审查项目依赖中的开源许可证义务。它结合分发模式分析传递依赖，整理兼容性、风险和合规建议。

主要功能

  1. 01盘点传递依赖许可证
  2. 02识别 SPDX 许可证
  3. 03按分发模式检查兼容性
  4. 04评估著佐权风险
  5. 05生成合规报告与建议

适用场景

  1. 01发布软件包前审查许可证
  2. 02评估专有软件的依赖风险
  3. 03为法律审查准备声明

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/seb1n/awesome-ai-agent-skills --skill license-analysis

安装后在 Claude Code 中输入/license-analysis确认已加载。

详细介绍

许可证分析

分析项目依赖树中的开源许可证兼容性和义务。此技能可识别正在使用的所有许可证、检查兼容性冲突、标记著佐权传染风险，并生成包含可操作建议的合规报告。涵盖宽松许可证（MIT、BSD、Apache-2.0）、弱著佐权许可证（LGPL、MPL）、强著佐权许可证（GPL、AGPL）以及专有或混合许可场景。

工作流

  1. 扫描依赖项 — 解析项目的依赖清单（package.json、requirements.txt、go.mod、Cargo.toml、pom.xml 等），并解析完整的传递依赖树。识别所有直接和间接依赖项，包括可选、开发和对等依赖项。注意未声明许可证的依赖项，以及 SPDX 表达式中注明双重许可的依赖项。

  2. 识别许可证 — 从软件包元数据中的 SPDX 标识符、软件包中的 LICENSE 文件或清单中的许可证字段中提取每个依赖项的许可证。将许可证名称规范化为 SPDX 标识符。标记没有许可证的软件包（默认保留所有权利）、自定义或专有许可证，以及需要选择的含糊多许可证声明。

  3. 检查兼容性矩阵 — 根据项目的预期分发模式（SaaS、分发二进制文件、开源库、内部工具）评估许可证之间的兼容性。宽松许可证（MIT、BSD、ISC）通常具有广泛兼容性。Apache-2.0 包含专利授权条款，因此与 GPLv2 冲突（但不与 GPLv3 冲突）。著佐权许可证（GPL、AGPL）规定了分发义务，可能与组合著作采用专有许可相冲突。即使通过网络使用，AGPL 也会触发相关义务。

  4. 标记著佐权风险 — 识别采用 GPL、AGPL、LGPL 或 MPL 许可的依赖项，并评估其使用方式（静态链接、动态链接、独立进程、网络交互）是否会触发著佐权义务。静态链接到专有应用程序中的 GPL 库要求整个应用程序采用 GPL 许可。LGPL 允许动态链接，且不会造成著佐权传染。AGPL 将著佐权义务延伸到网络交互。

  5. 生成合规报告 — 生成一份结构化报告，其中包含：许可证清单表、兼容性分析、带严重程度的风险标记、所需的署名和声明，以及解决任何冲突的具体建议。报告还应包含一份可纳入项目文档或供法律审查使用的软件物料清单。

用法

提供项目的依赖清单或依赖项列表，以及项目的许可证和分发模式。说明项目是以源代码、二进制文件、SaaS 形式分发，还是仅供内部使用。

示例提示词：

Analyze the licenses in my Node.js project. Here's my package.json dependencies. The project is MIT-licensed and distributed as an npm package. Flag any compatibility issues.

示例

示例 1：Node.js 依赖树分析

输入： 一个以开源、MIT 许可的 npm 包形式分发的 Node.js REST API。package.json 中的主要依赖项：

{
  "dependencies": {
    "express": "^4.18.2",
    "lodash": "^4.17.21",
    "pg": "^8.11.3",
    "sharp": "^0.33.2",
    "leaflet": "^1.9.4",
    "jsdom": "^24.0.0"
  }
}

输出：

许可证清单

包版本许可证类别风险
express4.18.2MIT宽松型无
lodash4.17.21MIT宽松型无
pg8.11.3MIT宽松型无
sharp0.33.2Apache-2.0宽松型无
leaflet1.9.4BSD-2-Clause宽松型无
jsdom24.0.0MIT宽松型无
libvips（sharp 原生组件）8.15.1LGPL-2.1弱著佐权中
canvas（jsdom 可选依赖）2.11.2MIT宽松型无

传递依赖摘要： 共扫描 347 个包。其中 331 个采用 MIT 许可，8 个采用 Apache-2.0 许可，4 个采用 BSD-2-Clause 许可，2 个采用 ISC 许可，1 个采用 LGPL-2.1 许可，1 个未获许可。

风险标记：

  • LGPL-2.1 — libvips（通过 sharp 引入），严重程度：中 — sharp 包通过原生绑定动态链接 libvips。LGPL-2.1 允许动态链接，不会触发著佐权传染，但你必须：(1) 在分发内容中附上 LGPL-2.1 许可证文本；(2) 提供署名；(3) 允许用户用修改后的版本替换 LGPL 组件。由于 sharp 使用预编译二进制文件，请在 NOTICES 文件中说明这一点。

  • 未获许可的包：[email protected]（通过 debug 传递引入），严重程度：高 — 未找到许可证文件或 SPDX 标识符。没有许可证即未授予任何使用权限。处理方式：确认这是否为过时版本（[email protected] 采用 MIT 许可），并固定到获许可的版本，或寻找替代方案。

必须提供的署名： 为全部 347 个包附上 LICENSE 文件或声明。可使用 license-checker 或 legally npm 包自动生成 THIRD-PARTY-NOTICES 文件。

示例 2：混合许可证兼容性分析

输入： 一款专有商业桌面应用（闭源），希望整合三个库：一个采用 MIT 许可的实用工具库、一个采用 Apache-2.0 许可的数据解析器，以及一个采用 GPL-3.0 许可的图表库。

输出：

兼容性矩阵

MITApache-2.0GPL-3.0专有（你的项目）
MIT兼容兼容兼容（单向）兼容
Apache-2.0兼容兼容仅与 GPL-3.0 兼容兼容
GPL-3.0可在 GPL 项目中使用 MIT 代码可在 GPL-3.0 项目中使用 Apache兼容不兼容
专有可使用 MIT可使用 Apache-2.0不兼容—

分析：

  • MIT 实用工具库 → 专有项目：兼容。 MIT 许可允许在专有软件中使用。义务：在分发内容中附上 MIT 许可证文本和版权声明。

  • Apache-2.0 数据解析器 → 专有项目：兼容。 Apache-2.0 许可允许专有使用。义务：附上 Apache-2.0 许可证；若存在 NOTICE 文件，也须附上；并说明对 Apache 许可文件所做的任何修改。专利授权可保护你免受 Apache-2.0 贡献者提出的专利索赔。

  • GPL-3.0 图表库 → 专有项目：不兼容。 GPL-3.0 要求组合后的作品以 GPL-3.0 许可分发，并提供完整源代码。这与专有／闭源分发直接冲突。纳入该库会使整个应用受 GPL-3.0 约束。

建议：

  1. 替换 GPL-3.0 图表库，改用 MIT 或 Apache-2.0 许可的替代方案。可选项：Chart.js（MIT）、Apache ECharts（Apache-2.0）、Plotly.js（MIT）。
  2. **如果 GPL 库不可或缺，**评估能否将其隔离到独立进程中，通过 IPC 或网络 API 通信。FSF 认为，如果各组件确实是独立程序，这或许能避免著佐权传染，不过这一解释仍有争议，且未经法律检验。
  3. 考虑购买商业许可证——一些 GPL 项目提供双重许可，并可付费获得专有许可。

最佳实践

  • 扫描完整的传递依赖树，而不只是直接依赖——Copyleft 风险常隐藏在依赖图的更深层级。
  • 将“无许可证”视为“保留所有权利”——没有许可证并不意味着可以宽松使用，而是意味着你没有合法权限使用、复制或分发。
  • 区分不同的分发模式：SaaS（会触发 AGPL 要求，但通常不会触发 GPL 要求）、npm 包（会对下游用户触发 GPL 要求）、内部工具（大多数 Copyleft 义务不适用于内部使用）。
  • 使用 FOSSA、Snyk、WhiteSource 或 license-checker 等工具，在 CI/CD 中自动扫描许可证，以便在添加依赖时发现新问题。
  • 维护预先批准的许可证允许列表（例如，MIT、BSD、Apache-2.0、ISC），并要求对列表之外的许可证进行人工审核。
  • 在随发行版提供的 THIRD-PARTY-NOTICES 文件中记录所有许可证义务。

安全边界

  • 将输出视为信息性草拟或问题识别，而非法律建议。
  • 确定适用司法管辖区和相关生效日期；针对不断变化的要求，核实当前的权威来源。
  • 不要声称某种表述合规、可执行或完整。标明不确定之处，并建议就重大决策咨询合格的法律顾问。
  • 未经用户审阅并明确授权，不要提交、发布、接受、签署或发送法律条款。

边缘情况

  • 双重许可的软件包（例如，MIT OR Apache-2.0） — 当软件包通过 SPDX OR 表达式提供许可选项时，你可以选择兼容性最高的许可证。记录所选许可证，并且只遵循该许可证的义务。
  • SSPL 和 Commons Clause — MongoDB 的 SSPL 和 Commons Clause 均未获 OSI 批准。它们分别限制 SaaS 使用和商业使用。即使可以获取源代码，也应将其视为专有许可限制。
  • 版本间的许可证变更 — 依赖项可能会在不同版本间变更许可证（例如，Elasticsearch 在 v7.11 中从 Apache-2.0 变更为 SSPL）。固定使用许可证已知且符合要求的版本，并监控更新中的许可证变更。
  • 字体、图像和非代码资产 — 资产适用的 Creative Commons 许可证与软件许可证的兼容规则不同。CC-BY-SA 要求相同方式共享（类似于 Copyleft），CC-BY-NC 禁止商业使用。不要假设代码许可证扫描会涵盖随附资产。
  • 来自 Stack Overflow 的代码片段或 AI 生成代码 — Stack Overflow 内容采用 CC-BY-SA 4.0 许可。逐字复制大量代码片段会产生相同方式共享义务。AI 生成代码的来源可能不明确。请记录非原创代码片段的来源。

评论

支持 Markdown