开源许可协议怎么选？搞懂这几种，装软件、改代码不踩坑

你是不是也遇到过这种情况：在 GitHub 上找到一个超好用的工具，想拿过来改一改适配自己项目，结果点开 LICENSE 文件，满屏英文看得直挠头？MIT、Apache、GPL……这些名字听着像密码本，其实它们就是开源许可协议——相当于给开源代码贴的一张“使用说明书”。

不是所有“免费”都能随便用

开源 ≠ 无限制。比如你下载了一个带 GPL 协议的命令行工具，把它集成进自家商业软件里直接打包发布，可能就踩雷了。因为 GPL 要求：只要用了它的代码，整个衍生作品也得开源。而 MIT 就宽松得多，连署名都不强制要求保留（当然，留着更礼貌）。

常见协议一句话看懂

MIT 协议：最轻量。允许你自由使用、修改、分发，哪怕做成收费软件也没问题，唯一建议是保留原作者版权声明。

Apache 2.0：比 MIT 多一层保护。明确授予专利使用权，还规定如果你起诉别人侵犯了你基于该项目的专利，你的授权自动失效。适合企业级项目。

GPL v3：带“传染性”。只要你发布的程序链接或整合了 GPL 代码（尤其是动态/静态链接），整个程序都得按 GPL 开源。Linux 内核就用它。

AGPL v3：GPL 的“云服务加强版”。就算你只把软件跑在服务器上、不对外分发（比如做 SaaS），只要用户能通过网络交互使用它，你也得公开源码。

实际配置中怎么查？

装软件前顺手扫一眼项目根目录的 LICENSE 或 COPYING 文件。很多包管理器也会提示协议类型。比如用 npm 安装一个库：

npm install lodash
// 安装完可以看 node_modules/lodash/LICENSE

再比如 Docker 镜像，官方镜像页通常会写明基础镜像用的协议（如 Alpine Linux 是 MIT）。

改代码前先看协议底线

你想给一个 Apache 2.0 的 Python 工具加个中文界面，没问题；但如果它用的是 AGPL，而你打算把它部署成内部后台系统供几十人用，那最好确认下是否需公开修改部分——有些公司会专门设法规避 AGPL 的触发条件，比如用 API 隔离调用。

说白了，选协议不是比谁更“开放”，而是看你的使用场景：要不要闭源？会不会商用？有没有专利顾虑？把 LICENSE 当 README 一样读一遍，省下的可能不只是律师费。