开源协议怎么选：一张决策树 + LICENSE 生成
你的仓库现在可能处于"谁都不能用"的状态
很多人以为代码传到 GitHub 就等于开源了。实际上没有 LICENSE 的代码受默认版权保护：别人下载了也只是"能看"，复制、修改、再分发在法律上都缺授权——企业选型看到这种仓库直接绕道，社区想提 PR 都会犹豫。反过来，为了"看起来正规"随手贴一个 GPL 到打算商业化的项目里，又可能给未来埋雷。
协议决定的就是一件事：别人能对你的代码做什么、必须以什么条件做。所以选协议不用先啃法条，先回答三个问题。
三个决策问题
问题一：要不要强制衍生作品也开源？ 这是宽松协议与 copyleft（著佐权）的分水岭。无所谓 → MIT/BSD/Apache 这类宽松协议；在乎 → MPL/GPL/AGPL 这一族。
问题二：有没有专利顾虑？ MIT 和 BSD 对专利只字未提；Apache-2.0 带显式专利授权——贡献者明确授予使用者专利许可，并用"专利反诉即终止授权"的条款约束恶意诉讼。企业级项目偏爱它的原因就在这里。
问题三：怕不怕 SaaS 化绕过？ GPL 的开源义务只在"分发"时触发，有人拿你的代码改一改、只提供在线服务不分发软件，义务就不触发。AGPL 把"网络交互"也算作分发，堵上了这个漏洞——这也是 MongoDB、Grafana 先后选 AGPL 的原因。
主流协议一表看懂
| 协议 | 一句话画像 | 代表项目 |
|---|---|---|
| MIT | 最宽松，只要求保留版权与许可声明 | React、Vue、Rails |
| BSD-3 | MIT 加一条"不得用作者名义做背书" | Go、FreeBSD |
| Apache-2.0 | 宽松 + 显式专利授权 + 要求声明改动 | Kubernetes、TensorFlow |
| MPL-2.0 | 文件级 copyleft：改过的文件要开源，可与其余闭源文件混用 | Firefox |
| GPL-3.0 | 强 copyleft：分发衍生作品必须整体同协议开源 | Bash、GIMP |
| AGPL-3.0 | GPL + 网络服务也算分发，堵 SaaS 漏洞 | Grafana、MinIO |
| 木兰-2.0 | 中文文本、贴合国内法域，已通过 OSI 认证 | openGauss |
拿不准两个协议的差异时，开源协议生成器页面附的对比表能把关键条款并排看，重点盯两列：有没有专利条款、要不要声明改动。
决策树（文字版）
从上往下问，第一个"是"就是出口：
- 别人闭源商用，你完全无所谓？→ 要专利条款选 Apache-2.0，追求最简选 MIT/BSD-3。
- 希望"改过的文件"保持开源，但允许被闭源项目引用？→ MPL-2.0。
- 要求一切衍生作品都同协议开源？→ GPL-3.0。
- 还要防止别人拿去做在线服务不分发？→ AGPL-3.0。
- 面向国内合规环境（信创、政企），想要中文文本与本土法域适配？→ 木兰-2.0。
生成 LICENSE 与徽章
选定协议后不用手抄全文。打开开源协议生成器，提供 11 种协议可选，填上版权人名称与年份，它会生成完整的 LICENSE 文件，直接放进仓库根目录；同时给出对应的 README 徽章，贴到项目首页就能展示协议信息。
两个容易忽略的动作：
- LICENSE 文件名就用
LICENSE，不带变体，代码托管平台才能自动识别并在仓库页标注协议 - 多数协议不要求每个源文件都带声明，但 Apache-2.0 建议在源文件头附上简短的协议标识与版权行
常见问题
没有 LICENSE 的代码，我能拿来用吗？
法律上默认不能——版权保留，任何复制、修改、分发都缺授权。实践里可以给作者提 issue 请求补协议或明确授权，别"先用了再说"，尤其在公司产品里。
项目以后能换协议吗？
自己是唯一版权人时可以——版权人有权重新授权自己的作品。但如果已经接受了社区贡献，每条贡献的版权属于其作者，换协议需要他们同意，这就是严肃开源项目签 CLA（贡献者许可协议）的原因。
LICENSE 和 NOTICE 是一回事吗？
不是。LICENSE 放协议全文；NOTICE 是 Apache-2.0 体系里记录署名与第三方组件来源的文件。小项目一个 LICENSE 就够，引入大量第三方依赖时再维护 NOTICE。
小结
选协议本质上是在回答"你想让这个项目被怎样使用"：无所谓 → MIT/Apache，有条件 → MPL/GPL，防 SaaS → AGPL，本土合规 → 木兰。三分钟定方向，再花一分钟在开源协议生成器里把 LICENSE 文件和 README 徽章生成出来——这两分钟，可能就是你项目从"没人敢用"到"有人敢用"的分界线。