开源许可证决定了一个项目能否被修改、分发、闭源商用、二次开发，以及二次分发时需要承担哪些义务。对项目发起方来说，许可证是开源生态和商业模式的边界；对项目使用方来说，许可证是技术选型里的合规前提。
被 OSI 认可的开源许可证，目前已经有 100 多个，还有很多因为不符合 OSI 有关开源的定义，而被称之为“伪开源(Fauxpen Source Licenses)”的许可证，比如最有代表性的 SSPL 许可证，SSPL 许可证是 MongoDB 公司于 2018 年推出的一种“开源许可证“，并尝试将其提交给 OSI 审批，此后在 2021 年， Elastic 公司也将旗下知名的开源软件 ElasticSearch 和 Kibana 的许可证变更为 SSPL，为此 OSI 在其官方网站专门发布了一篇声明，阐述“SSPL 不是开源许可证”，因为他不符合 OSI 有关开源定义中的“第六条：许可证不得限制任何人在特定领域使用该程序”。
核心要点
- OSI 认可的开源许可证很多，但多数项目只需要重点理解 MIT、GPL、Apache 这三类代表性许可证。
- MIT 更宽松，适合希望最大程度降低使用限制的项目。
- GPL 强调衍生作品继续开源，适合希望保护项目完整性、避免闭源分叉的项目。
- Apache 在保留版权和专利授权方面更明确，适合希望兼顾开放生态和商业化使用的项目。
- 对开源项目用户来说，许可证、社区活跃度、生态位和基金会托管情况，都是选型时需要同时评估的因素。
开源许可证这么多，作为开源项目的管理者如何选择？
100 多种开源许可证协议，没有必要挨个去研究，首先这些协议的用词都非常复杂和晦涩难懂，非专业人士难以理解，其次大多数协议的应用范围也非常有限，研究的意义不大。抓住其中具有代表性的许可证进行分析即可。
作为项目的管理者，为自己的项目选择许可证，首先要明确以下三个问题：
- 他人修改源码后，是否可以闭源？（会影响到开源软件的商业化生态）
- 新增的代码，是否要采用同样的许可证？（所谓的许可证的传染性，是项目不分叉的重要保障）
- 每一个修改过的文件，是否都必须放置版权说明？（考虑的是版权问题）
明确了上述三个需求之后，基本上就圈定了许可证选择的主要方向。更进一步，还可以考虑以下两个问题：
- 衍生软件的广告，是否可以用你的名字促销？（基本上放弃了所有权利）
- 是否需要对源码的修改之处，提供说明文档？（对许可证的传染性进行折中）
下面这个图，比较简洁的呈现了最常用的几个许可证的区别和联系（阮一峰制图）：
综上：
- 如果你期望自己的开源项目真正的、完全的、不附加任何限制的开源，那么选择 ”MIT 许可证“，比如我所在的公司快猫星云开源的 all-in-one 监控数据采集器项目 flashcatcloud/categraf 就采用 MIT 许可证；
- 如果你期望保障自己的开源项目的完整性，不被分叉或者不被闭源，那么选择 ”GPL 许可证“，典型代表项目为 Linux 内核：https://github.com/torvalds/linux，GPL 许可证有效的保障了 Linux 内核项目沿主干稳定发展；
- 如果你期望自己的开源项目，保留一定的版权，又不限制其他人基于该开源软件商业化，那么就选择 ”Apache 许可证“，典型的代表项目有 Kubernetes、云原生监控工具 Nightingale 夜莺，围绕着开源软件的商业化公司也是开源项目生态的重要组成力量；
三类常见许可证怎么理解
| 许可证 | 典型特征 | 更适合的项目诉求 |
|---|---|---|
| MIT | 限制少，使用和再分发门槛低 | 希望尽可能扩大采用范围 |
| GPL | 衍生作品需要遵循同类开源要求 | 希望防止核心代码被闭源分叉 |
| Apache | 兼顾版权、专利授权和商业使用友好性 | 希望开放协作，同时支持商业生态 |
知名开源项目陆续变更开源许可证，会带来什么影响？
最近，有一些知名开源项目，出于保护商业利益的角度出发，陆续更改了自己的开源许可证，比如：Redis、Zabbix、Grafana、ElasticSearch、Kibana 等。
这些许可证的更改，对于普通的终端用户来讲，并不会有太大的影响。这些变化无一例外，都针对”商业使用“做出了限制，避免了第三方商业公司对开源项目发起方的商业利益构成竞争。以 Zabbix 7.0 变更许可证为例，会给以二次开发 Zabbix 并提供商业化版本的公司带来约束，如不能及时调整服务模式，那影响就是致命的。
不过考虑到围绕着开源软件的各种商业化公司，本身也是开源项目生态的重要贡献者和参与方，这些许可证的变化，对整个开源生态的合力肯定是造成了削弱，出现“另起炉灶”的事情，或者出现各种“开源平替方案”。比如当 ElasticSearch 更改许可证之后，Amazon 直接对 ElasticSearch 进行分叉另起炉灶推出了 OpenSearch 项目；再比如最近 Redis 更改许可证之后，微软立即推出了 Redis 的开源平替 Garnet 项目，并号称性能遥遥领先 Redis。
开源许可证，无所谓好与坏。合适的许可证，是开源项目发展的基石。变更许可证带来的项目分叉或者出现平替，就是根本性基石出现动摇的体现之一。
作为开源项目的用户，如何选型开源项目？
作为开源项目的终端用户，如何评价和选项开源软件呢？可以从以下四个方面去考虑：
- 开源项目的生态位要准确：也就是看该项目在庞大的开源软件构成的链条上，是否是关键的一环，能否通过标准化的输入输出嵌入到链条中。反例：如果你看到一个开源项目的定位模糊、功能追求大而全、难以和其他开源软件对接，那么大概率该项目的发展会受限。
- 开源项目社区的活跃度和多元化：众人拾柴火焰高，速度是开源项目的制胜法宝，我们可以从 Issue / PR / Contributor 维度去评价，比如看 issue 数量是不是多、Contributor 来源是否多元化、Issue/PR 的响应速度是否够快等。
- 项目的许可证是否符合自己的要求：合适的许可证，是开源项目发展的基石，推荐选择 Apache 许可证、MIT 许可证、GPL 许可证等主流许可证相关项目。
- 是否有基金会托管：托管在基金会的项目一般都有相对透明的治理架构，能够聚集更多的力量，也不会轻易的做出更改许可证类型等事项。
开源许可证 FAQ
Q1：MIT、GPL、Apache 应该优先记住哪几个差异？ A：MIT 更宽松，GPL 更强调衍生作品继续开源，Apache 对版权和专利授权表达更完整。多数非法律专业人士先理解这三类差异，就能覆盖大量技术选型场景。
Q2：许可证变更为什么会引发分叉或平替项目？ A：许可证变更会改变使用方、云厂商、二次开发公司和社区贡献者之间的权利边界。当原有生态无法接受新边界时，就可能出现分叉或替代项目。
Q3：选择开源软件时只看许可证够吗？ A：不够。许可证是底线，还要看项目生态位、社区活跃度、贡献者多元化、治理结构和长期维护能力。
