选MIT、Apache还是GPL取决于你最怕什么：MIT允许闭源商用，Apache含专利报复条款，GPL要求衍生品开源；composer.json的license字段须与LICENSE文件一致，用composer show查真实依赖协议。
MIT、Apache、GPL 选哪个，取决于你最怕什么
不是看哪个“听起来更开源”，而是看你能否接受别人把你的代码拿去闭源卖钱、改名上市、甚至反过来告你侵权。MIT 最不怕这些；GPL 最怕别人不开放；Apache 则在中间补了一道专利防火墙。
- 选
MIT：你只想让人用，不强求回馈，也不介意大厂把你代码塞进黑盒产品里——React、Vue、Laravel 核心组件都这么干 - 选
Apache-2.0：你希望别人能商用、能改，但得防一手——如果对方起诉你专利侵权，那他自动失去本许可证授权（即“专利报复条款”） - 选
GPL-3.0-only：你坚持所有衍生品必须开源，哪怕只是动态链接（GPLv3 对 SaaS 使用有模糊地带，但比 GPLv2 更严），适合构建自由软件生态的底层工具
composer.json 里 license 字段怎么填才不算瞎写
它不是法律文件，但写错会误导协作者、触发合规扫描误报、甚至让私有项目被误当成可商用开源库。
- 必须和项目根目录的
LICENSE（或LICENSE.md）文件内容一致——不能"license": "MIT"却放一份 GPL 文本进去 - 多许可用数组：
"license": ["MIT", "Apache-2.0"]表示“任选其一”，不是“同时满足” - 闭源内部项目别留空或写
"MIT"，老老实实写"proprietary"或"unlicensed" - 别抄错 SPDX 标识符：是
BSD-3-Clause，不是BSD3或bsd-3；Packagist 能识别标准值，乱写会导致展示为 “Unknown”
怎么确认你依赖的包到底用的是什么协议
composer show 是唯一靠谱的本地命令，它读的是 vendor/ 里真实安装的包的 composer.json，不是 Packagist 缓存，也不是 lock 文件里的快照。
- 先确保已运行过
composer install，否则vendor/为空，composer show会报Package not found - 查单个包：
composer show monolog/monolog→ 看输出里的license:行 - 批量导出（需
jq）：composer show --no-dev --format=json | jq -r '.packages[] | "\(.name) \(.license // "UNKNOWN")"' - 注意兜底逻辑：
.license // "UNKNOWN"比grep license可靠，能处理字段缺失、null、或数组型值（如["MIT", "Apache-2.0"]）
生成 LICENSE 文件别靠手动复制粘贴
手敲容易漏年份、拼错作者名，还可能混入 Windows 换行或不可见字符，导致自动化合规工具解析失败。
- 推荐用官方源下载：
curl -sL https://raw.githubusercontent.com/spdx/license-list-data/master/text/MIT.txt > LICENSE - 需要带变量？用
npx license-generator mit --fullname "Your Name" --year "2026" --output LICENSE（Node.js 环境） - CI/CD 中生成
composer.json？别硬编码"license": "MIT"，改用模板注入："license": "${LICENSE:-proprietary}"，再配合sed或jq替换 - 改完
composer.json的license字段后，务必同步更新LICENSE文件和README.md里的声明，三者不一致才是真坑
许可证不是填完就完的事——它和 LICENSE 文件、README.md、CI 构建流程、甚至法务尽调都连着。一个 proprietary 写成 MIT，可能让整个交付物卡在客户合规审查环节。
