Composer怎么做依赖License合规检查_Composer如何检查项目依赖的许可证是否符合公司合规要求【指南】-composer-PHP中文网

composer show vendor/package-name 是唯一原生靠谱的起点，它输出 license 字段为可信任源头，但需已执行 install/update，且仅限显式声明包，不处理传递依赖或自动解析 license 文件。

composer怎么做依赖license合规检查_composer如何检查项目依赖的许可证是否符合公司合规要求【指南】

composer show 是唯一原生靠谱的起点

Composer 官方从没实现过 composer licenses 命令——这不是你装错了，也不是版本太低，而是它压根不存在。所有声称“运行 composer licenses 就能查全量许可证”的教程，背后都依赖第三方插件，且默认不生效。

真正开箱即用、不依赖 vendor/、不需额外安装、读取源头声明（composer.json）的方式，只有：composer show vendor/package-name。它输出的 license 字段是唯一可信任的起点。

必须已执行过 composer install 或 composer update，否则会报错 “Package not found”
只查显式声明的包，对传递依赖（如 symfony/polyfill-intl-idn）完全不可见
遇到 "license": "SEE LICENSE IN LICENSE.md" 这类模糊值，composer show 会原样输出，绝不会自动读取文件内容——你得手动打开对应 LICENSE.md 核对全文
空值、proprietary、unlicensed 都要立刻标记，不能跳过

批量导出 + 脚本过滤才是 CI 可落地的做法

人工一个一个 composer show 不现实。可行路径是：先用插件导出结构化数据，再用 jq 或 Python 筛选风险项。最稳的组合是：zicht/composer-license-plugin + jq。

它能递归扫描所有依赖（含 require-dev 和传递依赖），尝试标准化许可证名（比如把 MIT License 统一为 MIT），并输出 JSON，适合管道处理。

安装：composer require --dev zicht/composer-license-plugin
导出：composer licenses --format=json > licenses.json
查 GPL 类风险：jq -r '.[] | select(.license | test("GPL|AGPL|LGPL"; "i")) | "\(.name) \(.version) \(.license)"' licenses.json
注意：该插件对私有 fork（如 "repositories": [{"type": "vcs", "url": "git@..."}]）默认跳过，得先 composer archive 导出再人工审计

别信 audit 命令查 License —— 它根本不干这事

composer audit 只查 CVE 漏洞、废弃包和连接失败，**完全不检查许可证类型或兼容性**。它的 --ignore、--abandoned=fail 等配置，跟 MIT/GPL 冲突毫无关系。

Discussion Composer

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

下载

如果你在 CI 里只跑 composer audit 就以为过了合规关，等于在法律雷区闭眼走路。

composer audit 输出里出现 “License conflict”？那是假消息——官方 audit 逻辑里根本没有许可证冲突检测模块
某些文档写 “composer audit --license”，纯属杜撰，实际运行会报 Unrecognized option "--license"
真要堵住高风险许可证，只能靠脚本过滤 + 白名单机制（例如只允许 MIT、Apache-2.0、BSD-3-Clause）

许可证字段 ≠ 法律事实，必须人工验证文本

很多包的 composer.json 声明和实际 LICENSE 文件内容不一致：有的写 "license": "MIT"，但 LICENSE 文件里是修改过的非标准条款；有的根本没放 LICENSE 文件，只靠声明撑场面。

合规检查的最后一步永远是人工翻源码，不是看字段。

快速定位许可证文件：ls vendor/{vendor}/{package}/LICENSE* vendor/{vendor}/{package}/*.{md,txt}
粗筛关键法律词：grep -i "copyright\|permission\|grant\| sublicense\|copyleft" vendor/{vendor}/{package}/*.{md,txt} 2>/dev/null | head -8
特别留意复合许可证（如 "license": ["MIT", "GPL-2.0-or-later"]）——SPDX 兼容性得按组合规则逐条核对，不是简单匹配字符串

模糊声明、私有 fork、未归档的内部包，这些地方没有自动化工具能替你签字担责。