Composer如何查看包的开源协议？规避商业法务风险【避坑】-composer-PHP中文网

composer licenses 命令仅在 composer 2.2.0+ 中可用，旧版本及多数 ci 环境不支持；稳定可靠的方式是用 composer show --format=json 配合解析，但需注意 license 字段仅为作者声明、非法律凭证，须人工核验 license 文件内容。

composer如何查看包的开源协议？规避商业法务风险【避坑】

别信 composer licenses —— 它在大多数生产环境根本不存在，运行即报 Command "licenses" is not defined.。你真正能稳定用的，只有 composer show，且必须配合 --format=json 和后续解析，否则信息不可靠、不完整、无法自动化。

为什么 `composer licenses` 常常失效？

这个命令只在 Composer 2.2.0+ 中原生存在，但很多 CI 镜像（如 GitHub Actions 默认 PHP 环境）、Docker 基础镜像、甚至企业私有部署的 Composer 版本仍卡在 2.1.x。一旦执行，直接失败。更麻烦的是：旧教程或插件（如已废弃的 zicht/composer-license-plugin）留下的文档痕迹，会让开发者误以为它是标准命令。

查版本：运行 composer --version，低于 2.2.0 就别试 composer licenses
CI 中要显式指定版本，例如 GitHub Actions 里加 composer-version: '2.5'
composer licenses --format=json 输出是 JSON 数组，不是对象；用 jq '.packages[]' 会报错，得用 .[].name 这类路径

用 `composer show` 查许可证的实操要点

composer show 是唯一跨版本稳定的原生命令，但它读的是 vendor/ 下已安装包的 composer.json，不是 Packagist 缓存，也不是 composer.lock。这意味着它只反映当前 vendor/ 状态，且不解析 LICENSE 文件内容。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

必须先运行过 composer install 或 composer update，否则 vendor/ 为空，composer show monolog/monolog 直接报 Package not found
查单个包最准：composer show monolog/monolog，字段值原样来自本地文件
批量导出必须走 JSON：composer show --no-dev --format=json，再用 jq -r '.packages[] | "\(.name)\t\(.license // ["UNKNOWN"] | join(" | "))"'
license 字段可能是字符串（"MIT"）、数组（["MIT", "Apache-2.0"]）、URL（"https://example.com/LICENSE"）或空值——composer show 全部照搬，不做归一化

看到 `"MIT"` 也不能松口气：三个高危陷阱

license 字段只是作者填的字符串，不是法律凭证。合规审计认的是源码根目录下 LICENSE 或 LICENSE.md 的全文内容，不是这个字段。

"MIT License"、"The MIT License"、"mit" 都不是 SPDX 合法标识符，工具会标红；合法写法只有 "MIT"
"SEE LICENSE IN LICENSE.md" —— composer show 绝不会自动读取该文件，你得手动打开对应包的 LICENSE.md 核对是否真含标准 MIT 文本
["MIT", "GPL-3.0-only"] 这种写法没说明是“二选一”还是“同时满足”，必须查原始仓库确认适用条件；GPL-2.0-only 和 GPL-2.0-or-later 法律效力完全不同，但 composer show 不区分也不提示

真正控风险，得补上三步人工+工具验证

自动化只能筛出明显问题，法律闭环绕不开人。最易被跳过的环节是：确认第三方包是否真的按其声明许可证分发（比如 GitHub release assets 里有没有附带 LICENSE 文件），以及判断你的部署方式（SaaS？动态链接？）是否触发 GPL 类传染性条款——这没法靠命令行算出来。

装 composer/license-checker：它会真去读每个包的 LICENSE 文件内容，比对是否匹配声明
CI 硬检查示例：composer show --no-dev --format=json | jq -r '.packages[].license // ["UNLICENSED"] | .[]' | grep -qE '^(MIT|Apache-2.0|BSD-3-Clause)$' || (echo "non-compliant license found"; exit 1)
对 proprietary、unlicensed、unknown 必须立刻标记，它们不是“大概率是 MIT”，而是法律盲区，法务看到会叫停上线

最后一点容易被忽略：你改自己项目的 composer.json 里的 license 字段，只是更新 Packagist 页面上的徽章，既不控制代码权限，也不影响 composer install 行为——它就是个标签，不是开关。