Composer 的 license 字段必须使用 SPDX 官方短标识符，如 "MIT" 或 ["MIT", "GPL-2.0-or-later"]，填错会导致验证失败、合规工具漏报及依赖分析失效；私有项目应使用 "proprietary"，不可用自然语言或非标准写法。
Composer 的 license 字段只接受 SPDX 标识符
Composer 不识别自然语言描述（如 "MIT License" 或 "Apache 2.0"），必须使用 SPDX 官方短标识符。写错会导致 composer validate 报错或依赖分析工具无法识别协议类型。
常见正确写法：
"license": "MIT"-
"license": ["MIT", "GPL-2.0-or-later"]（多协议用数组） -
"license": "proprietary"（闭源项目，SPDX 允许的特殊值）
错误示例："license": "The MIT License (MIT)"、"license": "apache-2"（非 SPDX 标准写法）、"license": "BSD"（不明确是 BSD-2-Clause 还是 BSD-3-Clause）。
如何查一个协议对应的 SPDX 标识符
直接访问 https://www.php.cn/link/f164ba76f5fba1522bfbb098c4597aa6，用页面右上角搜索框输入关键词（如 mit、apache、bsd）。注意区分变体：
-
BSD-2-Clause和BSD-3-Clause是不同标识符，不能混用 -
GPL-2.0-only与GPL-2.0-or-later法律效力不同，选错可能影响下游合规 -
LGPL-3.0-or-later不等于LGPL-3.0-only
不确定时，优先查项目原始 LICENSE 文件头 —— 大多数主流开源项目会在第一行注明 SPDX-License-Identifier，例如：SPDX-License-Identifier: MIT。
license 字段为空或填错会有什么实际影响
表面上 composer install 可能照常运行，但真实风险在下游：
- 企业级依赖扫描工具（如
synk、FOSSA、WhiteSource）会跳过无 license 或非法 license 声明的包，导致合规报告漏报 - 某些 CI 流程（如 GitHub Actions 中的
composer validate --strict）会直接失败 - Packagist.org 页面不显示协议类型，降低用户信任度
- PHPStan / Psalm 等静态分析工具在检查许可证兼容性时无法参与推理
私有包和内部组件怎么填 license
私有代码库不等于可以留空或乱填。推荐做法：
- 内部服务/SDK：用
"license": "proprietary"（SPDX 官方认可，语义清晰） - 已签署 NDA 的客户定制包：仍建议写
proprietary，并在readme.md补充法律说明路径，例如：See LICENSE-CUSTOMER-A.pdf - 禁止写
"license": "unlicensed"—— 这不是 SPDX 合法值，且易被误读为“放弃版权”
真正麻烦的是混合协议场景：比如主代码 MIT，但某 vendor 子模块含 GPL 组件。这种不能靠 license 字段规避，必须在 NOTICE 或文档中单独声明，并考虑是否违反 GPL 传染性。
