如何查找Composer开源协议（合规自查）-composer-PHP中文网

composer licenses 非原生且版本受限，仅 composer 2.2.0+ 支持；稳定可用的是 composer show，但需 vendor 已安装，且不校验 license 文件真实性，合规自查必须人工核对原始 license 内容。

如何查找composer开源协议（合规自查）

没有“一键查协议”的原生命令，composer licenses 在多数环境根本不存在；真正可用、跨版本稳定的只有 composer show，但它只读字段、不校验、不解析 LICENSE 文件——合规自查必须手动补上文件核对这一步。

为什么 `composer licenses` 常常报错？

它只在 Composer 2.2.0+ 中原生存在，而大量 CI 镜像（如 GitHub Actions 默认 PHP 环境）、Docker 基础镜像、企业私有部署仍停留在 2.1.x。运行即报：Command "licenses" is not defined。更常见的是：你看到的文档来自已废弃插件（如 zicht/composer-license-plugin），和当前 Composer 无关。

查版本：composer --version，低于 2.2.0 就别试 composer licenses
CI 中需显式指定版本，例如 GitHub Actions 里加 composer-version: '2.5'
composer licenses --format=json 输出是 JSON 数组（如 [{"name":"monolog/monolog","license":"MIT"}]），不是对象，用 .packages[] 会报错，得用 .[].name 这类路径

`composer show` 怎么用才不漏信息？

它是唯一跨版本稳定、不依赖插件、不联网、只读 vendor/ 下真实 composer.json 的命令，但前提是 vendor/ 必须已就位——没执行过 composer install 或 composer update，composer show monolog/monolog 直接报 Package not found。

Discussion Composer

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

下载

查单个包最准：composer show monolog/monolog，字段值原样来自本地文件，不归一、不提示歧义
批量导出必须走 JSON：composer show --no-dev --format=json，再用 jq -r '.packages[] | "\(.name)\t\(.version)\t\(.license // ["UNKNOWN"] | join(" | "))"'
通配符有限但可用：composer show monolog/* 可列 monolog 生态，但 symfony/* 可能漏掉 polyfill 类子包——它们不在 composer.json 的 require 里显式声明
别用 grep license 解析文本输出：遇到数组型 license（如 ["MIT", "Apache-2.0"]）会被切碎，漏掉第二个值

看到 `"license": "MIT"` 就能上线？

不能。这个字段是作者自由填写的字符串，Composer 不校验真实性、不下载 LICENSE 文件、不比对内容。SPDX 官方只认 "MIT"，写成 "MIT License" 或 "The MIT License" 在 Composer 2.5+ 会直接报错，Packagist 显示 ❓。

"SEE LICENSE IN LICENSE.md"：composer show 绝不会打开该文件，你得手动进 vendor/monolog/monolog/LICENSE.md 确认全文是否标准 MIT 文本
["MIT", "GPL-3.0-only"]：没说明是“二选一”还是“同时满足”，法律效力天差地别，必须查原始仓库 LICENSE 文件和集成方式
"proprietary" 或空值：不是“默认安全”，而是法律盲区，法务介入前不能上线
URL 形式 license（如 "https://example.com/LICENSE"）：composer show 不访问网络，也不验证链接有效性，必须人工点开确认

真要控风险，必须补三件事

自动化工具只能筛出明显问题，绕不开人审的关键环节：

装插件读真实 LICENSE 文件：composer require --dev composer/license-checker，再跑 vendor/bin/license-checker——它会逐个打开 vendor/ 下每个包的 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)
人工核对 LICENSE 文件原文：真正有法律效力的是源码根目录下 LICENSE 或 LICENSE.md 的全文内容，不是 composer.json 里的字符串——尤其当字段值为模糊描述、URL 或多许可数组时，这步无法跳过

最容易被忽略的点是：composer show 和 composer.lock 解析结果可能不一致，前者反映当前 vendor/ 状态，后者记录解析快照；而无论哪种，都不等于 LICENSE 文件本身——合规闭环的最后一公里，永远需要人眼确认。