如何在Composer中检查已安装包的许可证合规性

如何在Composer中检查已安装包的许可证合规性

先说一个核心事实：Composer本身并不检查许可证合规性。所有关于“自动过审”的想象，都是一种危险的错觉。你看到的license字段，仅仅是作者填写的一个字符串，它既不是法律意见，更不代表实际分发文件的内容。

composer show 是唯一可靠起点，但只读 vendor/ 下已安装包

这个命令读取的是vendor/目录下每个包的composer.json中声明的license字段。它不会联网查询，不会解析LICENSE文件内容，也不会自动映射到SPDX标准。这里有个关键前提：你必须先运行过composer install，否则vendor/目录是空的，composer show只会报错Package not found ["unknown"]。

• 使用composer show vendor/package-name来检查单个关键依赖，确认其声明的许可证标识符（例如MIT或GPL-3.0）。
• 使用composer show --all可以列出所有已安装包，但输出信息较为杂乱。通常需要配合grep或jq来提取关键信息，比如：
  composer show --format=json | jq -r '.packages[] | "\(.name) \(.license // "UNKNOWN")"'
• 如果遇到"license": "SEE LICENSE IN LICENSE.md"、空值、proprietary或unlicensed等情况，就必须手动打开对应包的LICENSE.md文件进行全文核对——composer show绝不会替你读取文件内容。

别信 composer licenses —— 它在多数环境根本不存在

需要警惕的是，截至2026年4月，Composer官方并未内置名为licenses的命令。你在某些文档或博客里看到的composer licenses，要么是旧版第三方插件（例如zicht/composer-license-plugin），要么是误传。直接运行大概率会得到：Command "licenses" is not defined.。

• 如果你使用的是Composer 2.2+版本并且确实安装了zicht/composer-license-plugin插件，那么composer licenses --format=json才会生效。这个插件会尝试标准化许可证名称（例如将MIT License统一为MIT）。
• 该插件默认会跳过私有仓库（例如配置中"repositories": [{"type": "vcs", "url": "git@"}]的依赖），这类依赖需要先用composer archive命令导出，再进行人工审计。
• 如果没有安装插件却将其命令写入了CI脚本？那么构建过程会直接失败，这可不是警告，而是致命错误。

composer audit 和 license 合规毫无关系

这一点必须明确：composer audit命令只检查CVE漏洞、废弃包和源连接失败。它根本不看license字段，也完全不会判断MIT和GPL等许可证的兼容性问题。它的--ignore、--abandoned=fail等参数，对许可证类型完全无效。

• 如果在CI流程中只运行composer audit就认为可以安全发布，这无异于将法务风险视若无物。
• 如果在输出中看到“License conflict”之类的提示，那绝对不是Composer本身报出的信息——这很可能是某个第三方工具或人为注入的假消息。特别是如果发布时间标注为2026年3月22日这类未来日期，更属不可信来源。
• 真正要筛选GPL这类具有传染性的许可证，得依靠脚本来处理结构化数据，例如：
  jq -r '.[] | select(.license | test("GPL|AGPL|LGPL"; "i")) | "\(.name) \(.version) \(.license)"' licenses.json

SPDX 标识符 + LICENSE 文件双验证才是硬要求

很多项目的合规审计最终无法通过ISO或法务部门的审查，问题往往卡在两个地方：一是composer.json里填了"MIT"，但源码根目录下根本没有LICENSE文件；二是写了"BSD-3-Clause"，可实际文件里的条款却是被修改过的非标准版本。

• SPDX官方列表是唯一权威的参考标准：将composer show输出的值，粘贴到 https://www.php.cn/link/f164ba76f5fba1522bfbb098c4597aa6 进行搜索，重点关注“Is This License Compatible With GPL?”和“Matching Rules”部分。
• 对于多许可证声明，必须使用SPDX标准允许的逻辑运算符："MIT OR Apache-2.0" ✅，而["MIT", "Apache-2.0"] ❌（JSON数组在旧版Composer中可能被截断处理）。
• 像“MIT License”、“The MIT License”、“mit”这类写法都是无效的标识符，Packagist无法识别，合规扫描工具通常会将其标红。

最后，也是最容易被忽略的一点：许可证声明值与实际分发文件内容不一致，其危险性甚至超过版本号漂移。你核查了100个包的license字段，但只要漏掉一个没有核对LICENSE文件的私有fork，整份合规报告的法律效力就可能荡然无存。这才是关键所在。