技能介绍

问题背景

在 Node、Python、Go 等生态里，传递依赖往往比直接依赖多一个数量级。团队常见痛点是：某次引入 sharp 或调试工具链后，树里悄悄出现 LGPL、无 LICENSE 字段 或 MIT OR Apache-2.0 这类 SPDX 表达式；法务问「能不能闭源发二进制」，开发只能凭印象回答。Apache-2.0 与 GPLv2 的专利条款、AGPL 在 SaaS 场景下的网络 copyleft，也不是扫一眼 package.json 就能定论的。

技能如何工作

本技能按固定工作流处理你提供的清单（如 package.json、requirements.txt、go.mod、Cargo.toml、pom.xml）及分发模型（源码、二进制、SaaS、仅内部）：

扫描依赖 — 解析完整传递树，覆盖 direct / dev / peer / optional，并标记未声明许可或双重许可表达式。
识别许可证 — 从 SPDX、LICENSE 文件或 manifest 字段规范化到 SPDX ID；区分无许可（保留所有权利）、专有/自定义、需人工选择的 OR 许可。
兼容性矩阵 — 按你的分发方式做两两兼容评估（宽松许可、Apache 与 GPL 系列、专有组合作品等）。
Copyleft 风险 — 结合使用方式（静态/动态链接、独立进程、网络交互）标注 GPL、AGPL、LGPL、MPL 的传染程度。
合规报告 — 输出许可证表、严重度分级、归属/NOTICE 义务、冲突 remediation，以及可进文档或法务审查的 BOM。

适用边界

报告是工程与合规辅助，不能替代律师意见；FSF 对「独立程序 + IPC」等边界仍有争议。
SSPL、Commons Clause、跨版本改许可（如 Elasticsearch）需单独记为策略风险，不能当普通 OSI 宽松许可。
字体、图像等 Creative Commons 资产与代码许可规则不同；Stack Overflow 片段（CC-BY-SA）与 AI 生成代码的来源也需另行记录。
技能价值在于把「扫全树 + 矩阵 + copyleft 场景」一次说清；日常仍建议在 CI 用 license-checker、FOSSA 等做门禁，并维护预批准许可白名单。