2008 年，MySQL 创始人 Monty 所创办的开源创企——MySQL AB 以 10 亿美元的价格，卖给了 SUN 公司。对 SUN 日益不满的 Monty 很快出走，在 SUN 被甲骨文收购之际，Fork 了 MySQL，发布 MariaDB 项目。

之后，Monty 创立的 Monty Program 公司与 SkySQL 合并后成立 MariaDB Corporation AB，围绕 MariaDB 建设新的商业版图。如今，MariaDB Corporation AB 估值已达 6.72 亿美元。

当年创造 MySQL  AB 时，Monty 的杀手锏之一就是采用 GPLv-2 和商业授权的双重许可。2007 年，MySQL AB 的年收入是 7500 万美元，其中 70% 的收入是商业授权许可证带来的，同时这也是 MySQL AB 拥有巨大估值的原因。Monty 曾评价称：“我们是一家产品公司，在某些情况下人们必须为此付费。”

Monty 关于开源与商业平衡的想法到了 MariaDB 出现的时候变得更加成熟。2013 年，Monty 和伙伴 David Axmark 共同创建，并与 Linus Nyman 一起发布了 BSL——Business Soft License，将其用在 MariaDB Corporation AB 的一系列产品之上。Monty 等人把 BSL 当做是闭源与 Open Core 的替代方案，寄予了非常大的期望，MariaDB Corporation AB 如今的高估值也很难说没有 BSL 的一份功劳。然而另一方面，BSL 不符合 OSI 对开源许可证的定义，并非是广受认可的开源许可证，甚至有人说 BSL 只会在本已复杂和拥挤的许可证世界中增加混乱……

纳斯达克庆祝 MariaDB Corporation AB 与 Angel Pond Holdings Corporation 在 2022 年 2 月宣布合并成为上市公司

作为闭源与 Open Core 的替代方案出现

BSL 希望在遵循开源精神与原则的前提下，能够让一家软件公司有盈利能力，在闭源与开源的 Open Core 模式之间取得平衡。 

BSL 的模式下，软件的源代码始终是公开的，代码的非生产使用始终免费。另外，软件作者即许可证还可以增加附加的使用条款，允许部分生产使用。同时，BSL 会保证在某一时间点，软件的源代码自动更换许可证为开源许可证，比如 GPL 2.0 以及更高的版本，或者是其他兼容许可证，如 Apache 许可证。

BSL 最早出现在大众视野中源于 2013 年的一篇文章

“BSL 的目的是为客户、开发人员、用户和供应商提升软件行业整体的自由度和创新性。最后，我希望 BSL 将为新的商业模式铺平道路，这种新模式可以在不主要依赖捐赠的情况下维持软件开发。”Monty 非常希望 BSL 能带来新的增长模式，他也无数次表达过对开源的认可，以及开源需要支持的观点，“持续的成功需要利用开源的力量，同时要产生足够的收入，来确保项目的发展和福祉，找到正确的商业模式和许可是成功的重要先决条件。”

正式这种信念驱使着 Monty 不断基于开源软件去创业，并且在不断寻找新的增长模式。

前面提到过，Monty 曾为 MySQL 设计出双许可的发展模式，并在很长一段时间内实践成功，BSL 是在 Monty 等人意识到双许可的局限性之后创造的新物种，一定程度上是为了弥补双许可的缺陷而出现的。

比如，在 GPL 和商业授权的双许可之下，企业必须花钱购买商业许可证，才能使用带有封闭源码的软件。而 BSL 下的代码，企业只有想在生产中使用的时候，才需要付费。另外，从供应方的角度来看，GPL 双许可仅对那些希望嵌入该产品并售卖自身基础架构产品的公司能造成影响，对于仅使用服务的云厂商无法形成约束，而 BSL 则适用于任何类型的软件产品。

Monty 认为，相较于双许可营造出的单一供应商环境，BSL 避免了供应商锁定的情况——BSL 模式允许任何人查看和修改源代码，并且在约定期限到期后更改许可证时，任何人都可以根据更改后的开源许可证免费使用、更改和共享该软件。

那么，BSL 是怎么实现这些目标的？

首先， BSL 非商业性使用没有限制，商业性使用有限制。其次，BSL 是一种参数化许可证，它允许版权所有者设置三个灵活的参数：

一是更改许可证，该作品在“更改日期”之后，可更改成 GPL 版本 2.0 或更高版本兼容的许可证；

二是更改日期，作品不再根据 BSL 获得许可，而是根据“变更许可”获得许可的日期；

三是设置附加条款，“针对性”收费，BSL 默认禁止软件的生产使用，许可人可以选择使用此参数向被许可人授予额外的权利。例如，它允许开发人员设置服务器/CPU 等的数量限制，测试环境没有使用限制，只有生产使用时，高于限制值的使用会产生许可费。比如，MariaDB 附加的条件是，一个项目最多只能使用两个数据库服务器实例，超过就要付费。CockroachDB 附加的条件是，对外提供商业性的数据库服务需要付费。

附加条款以及收费的特质，让 BSL 听起来像是一个非常标准的商业授权，但它与商业授权最大的区别在于——源码始终可用。并且 BSL 通过设置一个到期日，保证 BSL 会变更成标准的开源许可证。

“这可以创建一个全新的生态系统，”Monty 认为，即使用户没有立即获得开源许可证的授权，但将来，也会有更多的开源应用程序可以被创建。

不是开源许可证，却被开源界元老的接受

实际上，现在 BSL 的身份、处境非常之尴尬。

MariaDB 在其官网上非常明确地指出：BSL 不是开源许可证，BSL 不符合 OSI 所提出的 OSD 开源定义。原因在于 OSD 不允许对特定类型的行为做限制，如生产用途。

但这不代表 BSL 不被开源界欢迎。从某种意义上来说，OSI 联合创始人 Bruce Perens 是 BSL 最流行的版本——1.1 版本的作者，他对于 BSL 出现的理由也非常认可：

“总的来说，我赞成允许人们通过创建开源来赚钱的计划，即使代价是该软件在一段时间内无法在完全开源的情况下提供给社区使用。做开源不应该意味着你穿一件毛衣，靠义气过活，而你的用户——通常是华尔街最大的公司，却在挣钱。”

Bruce Perens 在 2017 年写文章论述他对 BSL 做出的修改，并自称自己是出于同情，开始研究 BSL。回看 2013 年 Monty 等人发布 BSL 时，针对三个参数，并未设置一个严格的数字，比如对于变更时间的描述是：“仅仅一年的许可期限会促使许多用户决定等到开放版本时再使用，而超过五年的期限会促使软件走向 Open Core 的模式，三年似乎是一个很好的平衡……”

对于变更之后的许可证建议是：如果想要所有人都可以自由使用代码，那么 BSDv2 或者是 Apache 是最简单的，GPL 也是一种选择……

同样在收费部分，Monty 等人最初虽然提出过什么人应该付费、应该付多少的问题。但他们并未给出一个可供参考量化的答案。

针对这几个未定参数，Bruce Perens 认为这种模糊的设定没有真正发挥出 BSL 的作用，也会给想要使用的用户带来不便，用户对于未来的走向难以有清晰的感知和判断，“如果您告诉某人许可证是 BSL 1.0，他们将不知道自己真正拥有什么样的许可证，BSL 1.0 可能会转换成 100 个开源许可证中的任何一个，或者是非开源许可证。而这种转变可能会在下个月发生，也可能是下个世纪发生……”

基于此，Bruce Perens 和 Monty 等人共同确定 BSL 1.1 版本的内容。

BSL 1.1 规定，从作品初始版本的发布到专为开源许可证的时间不得超过 4 年，并且只能转化成能与 GPL 兼容许可证，并且许可人可以添加任意数量的额外许可供被许可人选择。它将始终允许在非生产环境中进行复制、修改、重新分发、非商业用途和商业用途。许可方将能够（并鼓励）指定额外的使用权限：例如，在 MaxScale 的情况下，MariaDB 指定在 BSL 下最多允许三个生产服务器，而无需额外的许可。许可文本是不可侵犯的，唯一允许的附加条款是授予权利。

结果就是，新版本的“BSL”中，当有人说某件作品在 BSL 下时，用户会很清楚自己得到了什么。“因此，我觉得它值得我的认可。新的 BSL 将是开发人员在最终使他们的作品开源的同时获得报酬的好方法。”

对于想要使用 BSL 的人，只需要填写四个要素：产品名称、设置用户必须付费的场景、许可证恢复为开源许可证、以及更改为哪个开源许可证。

不过，Bruce Perens 的调整仅局限于参数，并未涉及 BSL 的“身份认证”，而不被 OSI 认可，一定程度上对它的接受度造成了影响的。

粉丝队伍渐长？

不被开源界的定义所认可，那 BSL 在商业方面的表现如何？

从使用上来看，毫无疑问，MariaDB 是 BSL 的头号粉丝，MariaDB Corporation AB 在资本市场的表现也不差。在 MariaDB Corporation AB，包括 MaxScale、ColumnStore Backup Restore Tool、ColumnStore MaxScale CDC Data Adapter 和 ColumnStore Kafka Data Adapter 等在内的软件产品使用 BSL。

MariaDB Corporation AB 公司队伍

但放眼 MariaDB 之外，BSL 的使用者并不多，并且，从其他使用者的附加条款来看，BSL 更多地是作为一种防御云厂商“白嫖”的方式。比如，BSL 的采用者 CockroachDB、Sentry.io、Materialize 和 ZeroTier：

CockroachDB：变更日期 3 年；变更为 Apache 2.0；附加规定允许将 CockroachDB 用于任何目的（例如生产），只要不将其作为商业 DBaaS（数据库即服务）提供即可。 

Sentry.io：变更日期 3 年；变更为 Apache 2.0；附加规定基本和 CockroachDB 雷同，只要不提供商业 SaaS（软件即服务），您就可以将 Sentry 用于任何目的（例如生产）。 

Materialize：变更日期 4 年，变更为 Apache 2.0；附加规定同样是只要不将其作为商业 DBaaS 提供，您就可以将任意数量的 Materialise 非集群隔离服务器实例用于任何目的（例如生产）。

ZeroTier：变更日期 3 年 4 个月，变更为 Apache 2.0。ZeroTier 的附加条款相较复杂，前提有 3个，不能是提供商业服务，例如 ZeroTier SaaS；不能用于创建非开源商业衍生作品；不能在政府内部使用它，除非用于身体或精神保健、家庭和社会服务、社会福利、老年护理、儿童护理和残疾人护理。

此外，前不久 CI/CD 框架 Earthly 宣布变更 BSL 许可证为 MPL 2.0 开源许可证。

Earthly 称过去是用 BSL 是为了保护自身利益，并围绕 Earthly 建立一个可持续的业务。但自从 2020 年首次提交代码以来，BSL 并没有像预期中的那样保护 Earthly。反而根据官方社交媒体下方的互动信息来看，在过去两年时间里，Earthly 不断增长的用户群大多都对 BSL 许可证没有意见，但在少数情况下，BSL 许可证也会成为劝退部分用户的一个原因。

虽然 Earthly 在很短的时间内取得了快速增长，但也因为潜在用户对 BSL 协议不甚了解和 “恐惧” 限制了公司的成长，再加上他们希望 Earthly 能够成为任何 CI/CD 供应商的统一框架，他们需要一个更加开放的协议来拥抱社区并实现公司的愿景。

面对外界询问，项目作者也对变更许可证作出了回复：“我们转向开源，以更好地使我们与社区保持一致。面对科技巨头的垄断欺凌，这是一个艰难的决定，但我认为在这种情况下利大于弊。”

如果说开源项目是在用脚投票，BSL 显然还有很长的路要走，而 BSL 是否能在营收方面扳回一城，就要看 MariaDB Corporation AB 接下来的表现了。