开源许可入门：MIT、Apache、GPL 的差异
开源许可决定了你能怎么用、要不要开源自己的改动，选型前先看许可比事后补合规便宜得多。要分清宽松许可与传染性许可的差异，尤其留意 AGPL 在网络服务场景下可能触发的开源义务。
核心要点
- 开源许可分宽松与传染性两类，区别在于能否闭源分发衍生作品。
- MIT、Apache 2.0 较宽松，GPL 系列要求衍生作品同许可开源。
- AGPL 在网络提供服务时也可能触发开源义务，商用前要评估。
- 维护依赖许可清单，分发时附上许可与声明文件。
一句话结论：开源许可决定了你能怎么用、要不要开源自己的改动，选型前先看许可，比事后补合规便宜得多。
宽松许可与传染性许可
开源许可大致分成两类思路：一类宽松，允许你修改后闭源分发，只要求保留版权声明，如 MIT、Apache 2.0、BSD；另一类是传染性的，要求衍生作品也以相同许可开源，如 GPL 系列。前者适合想集成到自有产品的场景，后者更强调回馈社区。
此外还有更弱的 LGPL、MPL 等，条件介于两者之间，通常对“链接使用”和“修改文件”区别对待。
常见许可的差异
| 许可 | 能否闭源使用 | 主要义务 |
|---|---|---|
| MIT | 可以 | 保留版权与许可声明 |
| Apache 2.0 | 可以 | 保留声明，含专利授权条款 |
| MPL | 部分可以 | 修改过的文件需开源 |
| GPL | 不允许闭源分发 | 衍生作品需同许可开源 |
| AGPL | 不允许 | 网络提供服务也可能触发开源义务 |
上表只是方向性对比，具体条款务必看许可原文。
容易被忽略的点
- AGPL 与在线服务：把 AGPL 项目做成网络服务，可能触发提供源码的义务，商用前要评估。
- 多许可与双许可：同一项目可能提供社区版与商业版，条款不同。
- 依赖传染：你的项目本身许可宽松，但引入 GPL 依赖后整体分发仍可能受限。
- 声明保留：再宽松的许可也要求保留版权声明，删掉就是违规。
行动清单
- 维护一份依赖清单，记录每个组件的许可类型。
- 把 AGPL、GPL 类依赖单独标出，评估分发方式。
- 分发时附上许可与声明文件。
- 商业敏感项目在选型阶段就让法务或专业人士参与。
- 在持续集成里加入依赖许可扫描，自动列出 GPL、AGPL 等需重点关注的组件；分发产品时附上许可与版权声明，重大商业决策前请专业人士复核，而不是仅凭印象判断，避免把合规风险留到最后。
注意事项
- 许可合规属于法律问题，本文不构成法律建议，请咨询专业律师或查看许可原文与官方说明。
- 各项目的许可可能随版本变更，请以官方仓库为准。
参考资料
本文参考以下公开信息源，具体数据与表述以原始来源为准。