合法license字段必须使用SPDX官方标准标识符，如"MIT"、"Apache-2.0"、"GPL-3.0-or-later"；单协议写字符串，多协议写数组，闭源用"proprietary"；须与根目录LICENSE文件内容严格一致，否则Packagist显示❓、CI报unknown、企业拒收。
composer.json里license字段填什么才算合法
必须用SPDX官方列表里的标准标识符，比如"MIT"、"Apache-2.0"、"GPL-3.0-or-later"。Composer v2.5+ 本地运行composer validate就会校验这个字段，非法值直接报错，不是警告。
常见错误包括："MIT "（尾部空格）、"Apache 2.0"（空格和点号不合法）、"BSD"（SPDX要求明确写成"BSD-2-Clause"或"BSD-3-Clause"）、"proprietary"写成"internal"或"closed"——这些都会被当作无效值处理。
-
"MIT"✅，不是"mit"或"MIT License" -
"GPL-3.0-or-later"✅，"GPL-3.0"表示严格锁定v3，语义不同 - 多协议用数组：
["MIT", "BSD-3-Clause"]✅，表示“任选其一” - 闭源项目只能用
"proprietary"✅，其他字符串如"unlicensed"或null会导致工具误判
license字段和LICENSE文件必须严格一致
字段本身没有法律效力，真正起作用的是项目根目录下的LICENSE（无后缀）或LICENSE.md文件。两者内容不一致时，Snyk、FOSSA等合规工具会标为“信息冲突”，企业采购流程可能直接拒收。
例如填了"MIT"，就必须有对应文件，且内容得是完整MIT模板（含版权年份和作者），不能只写一行“See LICENSE file”。GitHub上很多项目第一行就有SPDX-License-Identifier: MIT，这就是最可靠的参考来源。
- 用
curl -sL https://raw.githubusercontent.com/spdx/license-list-data/master/text/MIT.txt获取标准MIT文本 -
spdx-license-matcher可比对字段与文件是否匹配 -
.gitignore里误加了composer.json会导致Packagist读到旧版，也常引发不一致
Packagist不显示协议徽章的真正原因
99%不是缓存问题，而是字段本身不合法，或者没打新tag。Packagist只解析tag指向的commit，push到main分支完全无效。
排查步骤很直接：先运行composer validate确认本地能过；再用git show v1.4.0:composer.json | grep license检查tag里的实际内容；最后访问https://packagist.org/packages/vendor/name看右上角“Last updated”时间是否已更新，滞后就手动点“Update”。
- 字段写在
require或autoload对象里是常见隐形坑——必须在composer.json根级 - 某些私有GitLab实例Webhook失败率高，别依赖自动同步
- 显示
❓时，优先查字段拼写，而不是刷新页面
如何让CI真正卡住非合规依赖
Composer默认不拦截安装，license字段只是元数据。真要阻断流程，得靠CI脚本主动提取并校验。
推荐做法是在CI中加一步：composer show --no-dev --format=json | jq -r '.[].license // ["UNLICENSED"] | .[]' | grep -qE '^(MIT|Apache-2.0|BSD-2-Clause|BSD-3-Clause)$' || (echo "non-compliant license found"; exit 1)。它会遍历所有依赖的license字段值，只要出现不在白名单里的，就立即失败。
-
composer audit可查高危协议（如"AGPL-3.0-only"），但需配合--format=json和jq做精准过滤 -
config.license白名单配置必须配合--strict-licenses参数才生效，光写配置没用 - 第三方包漏填
license或填"BSD"这种模糊值，你无法修复，只能用composer why-not vendor/package评估风险
真正容易被忽略的是大小写和连字符的敏感性——apache2、Apache 2.0、Apache-2.0在扫描工具眼里是三个不同许可证，而人类肉眼很难分辨。
