Composer licenses是什么协议_Composer开源许可查询方法

Composer licenses 命令不存在，唯一可靠方式是用 composer show 读取 vendor/ 中已安装包的 composer.json license 字段，支持通配符和 JSON 输出，但需注意字段值不校验、不解析 LICENSE 文件，且非 SPDX 规范

先澄清一个常见的误解：composer licenses 既不是一个协议，也不是 Composer 的原生命令。事实上，在绝大多数真实环境里，这个命令根本就不存在。如果你在终端里尝试运行它，大概率会看到 Command “licenses” is not defined. 这样的错误提示。这可不是你的配置出了问题，而是因为 Composer 官方从未实现过这个命令。

composer show 是唯一稳定、无需插件的许可证元数据来源

那么，到底该怎么查？答案是：composer show。这个命令直接从本地 vendor/ 目录下已安装包的 composer.json 文件中读取 license 字段。它不查询网络、不依赖任何第三方插件、也不会去解析实际的 LICENSE 文件，因此得到的结果最为直接和可控。

不过，使用前有几个关键点必须注意：

• 依赖必须已安装：你必须先执行过 composer install 或 composer update，否则 vendor/ 目录是空的，运行 composer show monolog/monolog 只会得到 Package not found 的报错。
• 支持通配符查询：比如，使用 composer show monolog/* 可以一次性列出整个 monolog 生态下的所有包，非常方便。
• 字段值五花八门：license 字段的值可能是字符串（如 “MIT”），也可能是数组（如 [“MIT”, “Apache-2.0”]）。此外，空值、“proprietary”，甚至是 “SEE LICENSE IN LICENSE.md” 这样的指引语句也屡见不鲜。而 composer show 会原封不动地输出所有这些内容，不会做任何归一化处理。
• 不处理传递依赖：这个命令只覆盖你项目 composer.json 中显式声明的包。像 symfony/polyfill-intl-idn 这类作为子依赖被引入的包，是不会出现在结果列表里的。

--format=json + jq 是批量提取的唯一可靠路径

如果你需要批量处理许可证信息，用文本管道（比如 grep 加 awk）去解析 composer show 的默认文本输出，很容易遇到错行、漏字段或误判多许可证场景的问题。要想机器可读且稳定可靠，必须走 JSON 格式。

• 标准操作示例：可以这样组合命令：composer show --no-dev --format=json | jq -r ‘.packages[] | “(.name)\t(.version)\t(.license // [“unknown”] | join(“ | “))”’。这个命令会过滤掉开发依赖，并以制表符分隔的格式输出包名、版本和许可证信息。
• 注意数据结构：输出的 JSON 顶层是一个数组，而非对象。对于多个许可证，它们会以数组形式保留，切记不要想当然地用 join(“ OR “) 去连接。因为根据 SPDX 规范，许可证之间的逻辑连接符（如 OR/AND）必须被显式地写出来，数组本身才是包作者声明的原始事实。
• 无 jq 的替代方案：如果系统没有安装 jq，可以用一段简单的 PHP 脚本替代：通过 json_decode(file_get_contents(‘composer.lock’), true) 读取锁文件，然后对 $pkg[‘license’] ?? [‘unknown’] 的结果进行强转数组再展开处理。

license 字段只是线索，不是法律依据

最后，也是最重要的一点：在 composer.json 里看到 “license”: “MIT”，绝不意味着你的使用就自动合规了。这个字段完全由包作者自由填写，Composer 不会进行强制校验，也无法保证它与包内实际的 LICENSE 文件内容一致。

这里有几个典型的“坑”：

• 标识符不标准：像 “MIT License”、“The MIT License” 甚至小写的 “mit”，都不是有效的 SPDX 标识符。合规工具通常只认大写的 MIT。
• 指引性语句需手动核对：如果字段值是 “SEE LICENSE IN LICENSE.md”，composer show 绝不会自动去读取那个文件。你必须手动打开对应包目录下的 LICENSE.md 文件，核对全文内容。
• 不区分许可证变体：GPL-2.0-only 和 GPL-2.0-or-later 在法律效力上完全不同，但 composer show 不会帮你区分，也不会给出任何提示。
• 警惕空值与专有声明：遇到空值、“unlicensed” 或 “proprietary” 必须立刻标记。这属于法律盲区，绝不能凭经验猜测“它大概率和 MIT 差不多”就蒙混过关。

说到底，composer show 提供的只是一个高效的线索索引。当项目需要正式商用、涉及出口或者需要通过等保测评时，跳过对源码仓库中实际 LICENSE 文件的最终核对（比如用 grep -r -i “GNU GENERAL PUBLIC LICENSE.*v3” vendor/ 这样的命令做一次全文匹配），未来可能带来的合规成本和风险，远高于现在多花的那十分钟检查时间。这一点，值得所有开发者牢记。