Composer 的 license 字段必须使用 SPDX 标准化标识符（如 MIT、Apache-2.0），不可写描述性文本；单许可证用字符串，多许可证用数组表示“二选一”；须与 LICENSE 文件内容一致，否则触发合规告警。
Composer 项目中的 license 字段不参与依赖解析、安装或自动合规检查，它只是元数据——但写错或留空会在开源协作、合规扫描（如 Snyk、FOSSA）、Packagist 展示时引发误解甚至阻断集成。
license 字段的合法值有哪些
必须是 SPDX 认可的标准化许可证标识符（如 MIT、Apache-2.0、GPL-3.0-only），不能写成 "MIT License" 或 "see LICENSE file"。Composer 不校验合法性，但 Packagist 会拒绝非 SPDX 标识符的提交。
-
MIT、BSD-3-Clause、ISC：宽松型，允许闭源使用 -
GPL-3.0-onlyvsGPL-3.0-or-later：后者允许升级到 GPL-4.0（若发布），前者严格锁定版本 -
proprietary是合法值，但 Packagist 不收录；私有包应配合repositories配置使用 - 多许可证用数组：
["MIT", "GPL-3.0-or-later"]，表示“二选一”而非“同时满足”
如何在 composer.json 中正确配置 license
直接写入顶层字段，无需嵌套。常见错误是把它塞进 extra 或当成字符串描述写进 description。
{
"name": "acme/utils",
"license": "MIT",
"autoload": { "psr-4": { "Acme\": "src/" } }
}
- 单许可证：用字符串
"MIT" - 多许可证（兼容性选择）：用数组
["MIT", "Apache-2.0"] - 自定义许可证：必须先向 SPDX 提交申请获得 ID，否则不被生态工具识别
- 不要写
"UNLICENSED"—— 这不是 SPDX 标识符，会被视为无效值
license 和 LICENSE 文件的关系
license 字段和项目根目录的 LICENSE（或 LICENSE.md）文件是独立的：前者供机器读取，后者供人类阅读。两者内容必须一致，否则会触发合规工具告警。
- Composer 不读取、不校验
LICENSE文件内容 - 建议用
spdx-license-matcher工具比对二者是否匹配 - 若用
GPL-3.0-or-later，LICENSE文件里必须明确包含“or any later version”字样 - 未提供
LICENSE文件时，仅靠license字段无法满足 OSI 合规要求
真正容易被忽略的是：很多团队把 license 当作“填完就完事”的字段，却没意识到 CI 流水线里的许可证扫描器（如 license-checker）默认只认这个字段，且对大小写和连字符极其敏感——apache2、Apache 2.0、Apache-2.0 在工具眼里是三个不同许可证。
