为什么开源数据库改变许可证？

一、CockroachDB 的许可证变更

CockroachDB 以前的许可证是 Apache，代码托管在 GitHub，任何人都可以访问。

现在的许可证改成了“商业源码许可证”（Business Source License，缩写 BSL）。

这段文字的意思是，三年以后的2022年10月1日，这些代码将变为 Apache 许可证，在此之前都属于商业源码许可证。多少人想用三年前的代码？因此，它实际上用 BSL 许可证取代了 Apache 许可证。

二、商业源码许可证的特点

BSL 许可证是 MariaDB 发明的，最大的特点有两个。

一是非商业性使用没有限制，商业性使用有限制。

二是许可证是模块化的，可以附加自己的条件（Additional Use Grant）。

比如，MariaDB 附加的条件是，一个项目最多只能使用两个数据库服务器实例，超过就要付费。

CockroachDB 附加的条件是，对外提供商业性的数据库服务需要付费。

简单说，商业源码许可证就是一种限制了云服务的开源许可证。

三、问题的由来

目前，许多开源数据库对云服务都有限制。这完全是由 Amazon 的 aws 云服务引起的。

aws 一直提供数据库服务，2009年推出 RDS MySQL 服务，2013年推出 PostgreSQL 服务，2015年推出 Amazon Elasticsearch 服务。大量企业购买这些服务，使得收入都向 Amazon 集中，它的 Elasticsearch 一个服务的收入已经高于原始开发商 Elastic 的所有收入。

这就相当于，开源开发者在为 Amazon 免费打工，为它创造利润。Elastic 当然很不爽，推出了付费版本。结果，Amazon 一不做二不休，把开源分支分叉了，自己把 Elastic 的所有收费功能写出来了。也就是说，Amazon 不仅拿走了利润，还创造出了一个竞争性产品。类似的情况还有，Azure 提供 MongoDB 兼容的 CosmosDB 服务。

其他开源数据库看到这种局面，都感到了云服务商的威胁，所以纷纷改变授权模式。

这里的根本问题是，云服务的出现改变了开源软件的生态。以前，开源软件有众多的使用者，会形成一个社区，从社区得到反馈和支持。现在，企业级开源软件很可能都有云服务，导致企业客户都流向了云服务商，软件自身形成不了社区，云服务商反过来会对软件产生巨大影响，许可证的变更只是抵抗云服务商的一种策略。

四、对策

目前，有三种变更许可证的策略。

第一种是采用 AGPL 许可证，任何对软件的修改（包括提供服务）都必须开源。这种策略的好处是防止云服务商对软件进行内部修改，坏处是不够灵活，可能打击企业采用该软件的积极性。

第二种是产品分层策略，同时提供免费的社区版和收费的企业版。这种策略可以保证收入，但是问题是，有些高级功能只在企业版提供，不利于软件的开源。

第三种就是 CockroachDB 的策略，软件依然开源，但是提供服务必须付费。我觉得，目前来看这种策略在开源和收费之间达到平衡，比较理想。