CockroachDB 修改开源协议以限制商业构建 DBaaS


开源云原生 SQL 数据库 CockroachDB 宣布修改开源协议,加入限制商业使用的条款。
情况与之前 Redis Labs再次更改开源许可证、MariaDB CEO痛斥云厂商滥用开源许可、MongoDB不满AWS等云厂商坐收渔利而修改开源协议类似,Cockroach 官方表示,以往的开源软件与商业模式的结合规范是一家公司可以在没有大平台的情况下,围绕某个开源核心产品去构建其业务并以该产品提供服务(XX as a Service),然而现在的情况变了,一些大公司可以直接在业务中高度集成竞争对手的开源核心软件,并将其以服务的形式(XX as a Service)提供给用户。
为了回应这一类竞争对手,Cockroach 对核心源码的开源协议进行修改,从原本的 Apache V2.0 协议修改为 BSL(Bussiness Source License),在该协议之下,CockroachDB 用户可以将 CockroachDB 扩展到任意数量的节点,可以使用 CockroachDB 或将其嵌入到他们的应用中,无论是将这些应用分发给客户还是将其作为服务运行,甚至还可以在内部将其作为服务运行。但是唯一不能做的是在没有取得授权的情况下以商业形式用 CockroachDB 提供数据库即服务(DBaaS)。
Today, we're adopting an extremely permissive version of the Business Source License (BSL). CockroachDB users can scale CockroachDB to any number of nodes. They can use CockroachDB or embed it in their applications (whether they ship those applications to customers or run them as a service). They can even run it as a service internally. The one and only thing that you cannot do is offer a commercial version of CockroachDB as a service without buying a license.
同时,BSL 还具有滚动时间限制,具体到 CockroachDB 中,其每一个版本在基于 BSL 发布三年后,License 将切换为标准定义的开源协议 Apache 2.0。这个举措一方面可以使 CockroachDB 官方维持一个有竞争力的 DBaaS,另一方面也保证了 CockroachDB 核心还是纯粹的开源项目。
BSL 是 MariaDB 公司的一个 License,它本质上是闭源和 Open Core 开源模式的“中间模式”,同时也得到了 OSI 创始人 Bruce Perens 的认可。在 BSL 之下,源码始终是自由的,并且保证在某个时间点会变成“真的”开源(OSI 定义的开源),这个时间节点也就是前边提到的“滚动时间限制”,表现在 CockroachDB 中是版本发布满三年。
BSL 中指定级别以下的使用总是完全自由的,超过指定级别的使用需要有商业授权,直到滚动时间限制到期,这时所有对项目的使用行为都是自由的。
CockroachDB 具体解释道:
我们的 BSL 保护 CockroachDB 的当前代码不会在没有企业授权的情况下被用作 DBaaS,为期三年。3 年后此限制失效,代码变为开源的(根据我们当前的 Apache 开源协议),可以用于任何目的。
我们将此 License 应用于 CockroachDB 的核心版本(即目前在 Apache 2.0 开源协议下的代码),这意味着 CockroachDB 核心不再是 OSI 定义上开源的,尽管完整的源代码仍然可用,并且除了构建 DBaaS 之外,允许任何商业用途。
关于 BSL 的详细信息,可以查看此链接。
关于 CockroachDB 修改开源协议的一些报道的解读
据 CockroachDB 官方博客称,CockroachDB 新的核心代码授权协议将采用 BSL,用户可以将 CockroachDB 扩展到任意数量的节点,可以随意使用 CockroachDB,也可以将其嵌入到应用程序中(无论是将这些应用程序发送给客户,还是将其作为服务运行),甚至可以在内部将 CockroachDB 作为服务运行。唯一不能做的事情是,在没有购买许可证的情况下,提供商业版 CockroachDB 作为服务。但好消息是该限制并不是无限期的,而是有失效性的:CockroachDB 每个版本在发布三年之后,许可证将转换为 APL。CockroachDB 官方表示,之所以会设置时间限制的再许可,主要有两个目的,一是想要创建一个具有竞争力的数据库即服务(DBaaS),二是为了保证核心产品是纯粹的开源产品。
更改协议的原因
从首次出现在 GitHub 上,CockroachDB 一直走的是比较典型的开源路线,即核心代码保存在 Apache 2.0 许可证之下,启动了托管服务,并根据企业许可证为已建立的公司提供一些功能。为什么突然就转变路线,想要变更协议呢?
变更协议的主要原因是 CockroachDB 团队对于开源商业模式有了重新的认识,之前他们认为公司可以基于强大的开源产品来建立业务,并不需要其它更大的技术平台,提供相同的产品即服务。现在,他们发现现行法律允许竞争对手提供其它公司的 OSS 产品即服务,而这一举动伤害到了原本的开源产品。前些时间, AWS 推出的 Elasticsearch 开源发行版就是一个典型案例,该 Elasticsearch 发行版不仅可以作为免费软件来使用,同时还将提供 Elastic 只向付费客户提供的高级功能,例如传输加密、用户身份验证、详细审计、基于角色的细粒度访问控制、事件监控和警报、深度性能分析和 SQL 支持等。
在博客中,CockroachDB 团队表示这次软件许可条款的更改就是为了回应这一类竞争对手。事实上,开源软件和云厂商的矛盾早已存在,之前 Redis Labs、Confluent 和 MongoDB 等公司先后修改了开源协议,并明确表示修改的原因是阻止像 AWS 这样的大型云服务提供商将其开源软件作为一项服务来接受和销售。在这场交锋中,双方都在朝着更加“利己”的方向改变策略,例如越来越多的开源产品转向更强势的许可方式,而云厂商针对新的许可方式也有自己的应对方法,例如自研兼容开源产品的相关产品、推出相应的增强开源发行版等等。
关于 BSL 协议
CockroachDB 更改为的 BSL 协议到底是什么?BSL 全称是 Business Source License,它不是一个开源协议,用户虽然可以拿到源代码,但是使用时会受限。使用 BSL 协议的软件在发布的最多 4 年之后(开发者可在协议中自定义开源时间)会将协议变更为开源协议,也就是说,使用 BSL 协议的软件,最终都会变成开源软件。
BSL 协议是在经历了 MySQL 被收购之后,MariaDB 公司新定义的一种协议,是开源软件与商业公司对抗的一次新的探索。它介于开源和闭源之间,在非生产环境中,BSL 协议的软件可以不受限制的使用,如果用于商业目的,那么会有所限制。
协议变更后的 CockroachDB
BSL 许可证应用于 CockroachDB 的核心版本(即目前在 Apache 2.0 许可证下的代码),这意味着 CockroachDB 核心不再开源,但完整的源码仍然可用,除了构建 DBaaS 之外,也允许用于其它商业用途。对于绝大多数用户来说,CockroachDB 仍然可被自由使用,而且三年之后就又变成无任何附加条件的开源产品。
CockroachDB 数据库从 19.2 版本开始重新授权,企业功能继续沿用 Cockroach Community License (CCL),使用企业功能需要与 Cockroach Labs 签订许可协议,并且此许可证在三年之后不会转换为开源。而之前的版本不受此许可证更改的影响,即 CockroacheDB 19.1 仍使用 APL,19.1.x 系列中当前和将来的所有补丁版本也将使用 APL。具体来讲,CockroachDB 19.2(暂定 2019 年 10 月)是使用新许可方案的第一个版本,它包括在 BSL 和 CCL 许可下的代码。2022 年 10 月(发布三年后),CockroachDB 19.2 中 BSL 下的部分代码将转换为 APL,补丁版本也会随之转变为 APL。其它版本的协议转换时间以此类推,例如 CockroachDB 20.1 计划在 2020 年 4 月发布,于 2023 年 4 月成为开源软件。
开源和商业的关系绝不是简单的对立:没有开源的基础技术是没有生命力,很难被广泛应用;而商业体现了开源项目的价值,也反向推动了开源项目的发展和生态的建立。所以开源项目如何在开源和商业找到一个平衡点,是很多开源团队在思考的问题,希望 CockroachDB 团队的尝试能够给大家更多启发。
情况与之前 Redis Labs再次更改开源许可证、MariaDB CEO痛斥云厂商滥用开源许可、MongoDB不满AWS等云厂商坐收渔利而修改开源协议类似,Cockroach 官方表示,以往的开源软件与商业模式的结合规范是一家公司可以在没有大平台的情况下,围绕某个开源核心产品去构建其业务并以该产品提供服务(XX as a Service),然而现在的情况变了,一些大公司可以直接在业务中高度集成竞争对手的开源核心软件,并将其以服务的形式(XX as a Service)提供给用户。
为了回应这一类竞争对手,Cockroach 对核心源码的开源协议进行修改,从原本的 Apache V2.0 协议修改为 BSL(Bussiness Source License),在该协议之下,CockroachDB 用户可以将 CockroachDB 扩展到任意数量的节点,可以使用 CockroachDB 或将其嵌入到他们的应用中,无论是将这些应用分发给客户还是将其作为服务运行,甚至还可以在内部将其作为服务运行。但是唯一不能做的是在没有取得授权的情况下以商业形式用 CockroachDB 提供数据库即服务(DBaaS)。
Today, we're adopting an extremely permissive version of the Business Source License (BSL). CockroachDB users can scale CockroachDB to any number of nodes. They can use CockroachDB or embed it in their applications (whether they ship those applications to customers or run them as a service). They can even run it as a service internally. The one and only thing that you cannot do is offer a commercial version of CockroachDB as a service without buying a license.
同时,BSL 还具有滚动时间限制,具体到 CockroachDB 中,其每一个版本在基于 BSL 发布三年后,License 将切换为标准定义的开源协议 Apache 2.0。这个举措一方面可以使 CockroachDB 官方维持一个有竞争力的 DBaaS,另一方面也保证了 CockroachDB 核心还是纯粹的开源项目。
BSL 是 MariaDB 公司的一个 License,它本质上是闭源和 Open Core 开源模式的“中间模式”,同时也得到了 OSI 创始人 Bruce Perens 的认可。在 BSL 之下,源码始终是自由的,并且保证在某个时间点会变成“真的”开源(OSI 定义的开源),这个时间节点也就是前边提到的“滚动时间限制”,表现在 CockroachDB 中是版本发布满三年。
BSL 中指定级别以下的使用总是完全自由的,超过指定级别的使用需要有商业授权,直到滚动时间限制到期,这时所有对项目的使用行为都是自由的。
CockroachDB 具体解释道:
我们的 BSL 保护 CockroachDB 的当前代码不会在没有企业授权的情况下被用作 DBaaS,为期三年。3 年后此限制失效,代码变为开源的(根据我们当前的 Apache 开源协议),可以用于任何目的。
我们将此 License 应用于 CockroachDB 的核心版本(即目前在 Apache 2.0 开源协议下的代码),这意味着 CockroachDB 核心不再是 OSI 定义上开源的,尽管完整的源代码仍然可用,并且除了构建 DBaaS 之外,允许任何商业用途。
关于 BSL 的详细信息,可以查看此链接。
关于 CockroachDB 修改开源协议的一些报道的解读
据 CockroachDB 官方博客称,CockroachDB 新的核心代码授权协议将采用 BSL,用户可以将 CockroachDB 扩展到任意数量的节点,可以随意使用 CockroachDB,也可以将其嵌入到应用程序中(无论是将这些应用程序发送给客户,还是将其作为服务运行),甚至可以在内部将 CockroachDB 作为服务运行。唯一不能做的事情是,在没有购买许可证的情况下,提供商业版 CockroachDB 作为服务。但好消息是该限制并不是无限期的,而是有失效性的:CockroachDB 每个版本在发布三年之后,许可证将转换为 APL。CockroachDB 官方表示,之所以会设置时间限制的再许可,主要有两个目的,一是想要创建一个具有竞争力的数据库即服务(DBaaS),二是为了保证核心产品是纯粹的开源产品。
更改协议的原因
从首次出现在 GitHub 上,CockroachDB 一直走的是比较典型的开源路线,即核心代码保存在 Apache 2.0 许可证之下,启动了托管服务,并根据企业许可证为已建立的公司提供一些功能。为什么突然就转变路线,想要变更协议呢?
变更协议的主要原因是 CockroachDB 团队对于开源商业模式有了重新的认识,之前他们认为公司可以基于强大的开源产品来建立业务,并不需要其它更大的技术平台,提供相同的产品即服务。现在,他们发现现行法律允许竞争对手提供其它公司的 OSS 产品即服务,而这一举动伤害到了原本的开源产品。前些时间, AWS 推出的 Elasticsearch 开源发行版就是一个典型案例,该 Elasticsearch 发行版不仅可以作为免费软件来使用,同时还将提供 Elastic 只向付费客户提供的高级功能,例如传输加密、用户身份验证、详细审计、基于角色的细粒度访问控制、事件监控和警报、深度性能分析和 SQL 支持等。
在博客中,CockroachDB 团队表示这次软件许可条款的更改就是为了回应这一类竞争对手。事实上,开源软件和云厂商的矛盾早已存在,之前 Redis Labs、Confluent 和 MongoDB 等公司先后修改了开源协议,并明确表示修改的原因是阻止像 AWS 这样的大型云服务提供商将其开源软件作为一项服务来接受和销售。在这场交锋中,双方都在朝着更加“利己”的方向改变策略,例如越来越多的开源产品转向更强势的许可方式,而云厂商针对新的许可方式也有自己的应对方法,例如自研兼容开源产品的相关产品、推出相应的增强开源发行版等等。
关于 BSL 协议
CockroachDB 更改为的 BSL 协议到底是什么?BSL 全称是 Business Source License,它不是一个开源协议,用户虽然可以拿到源代码,但是使用时会受限。使用 BSL 协议的软件在发布的最多 4 年之后(开发者可在协议中自定义开源时间)会将协议变更为开源协议,也就是说,使用 BSL 协议的软件,最终都会变成开源软件。
BSL 协议是在经历了 MySQL 被收购之后,MariaDB 公司新定义的一种协议,是开源软件与商业公司对抗的一次新的探索。它介于开源和闭源之间,在非生产环境中,BSL 协议的软件可以不受限制的使用,如果用于商业目的,那么会有所限制。
协议变更后的 CockroachDB
BSL 许可证应用于 CockroachDB 的核心版本(即目前在 Apache 2.0 许可证下的代码),这意味着 CockroachDB 核心不再开源,但完整的源码仍然可用,除了构建 DBaaS 之外,也允许用于其它商业用途。对于绝大多数用户来说,CockroachDB 仍然可被自由使用,而且三年之后就又变成无任何附加条件的开源产品。
CockroachDB 数据库从 19.2 版本开始重新授权,企业功能继续沿用 Cockroach Community License (CCL),使用企业功能需要与 Cockroach Labs 签订许可协议,并且此许可证在三年之后不会转换为开源。而之前的版本不受此许可证更改的影响,即 CockroacheDB 19.1 仍使用 APL,19.1.x 系列中当前和将来的所有补丁版本也将使用 APL。具体来讲,CockroachDB 19.2(暂定 2019 年 10 月)是使用新许可方案的第一个版本,它包括在 BSL 和 CCL 许可下的代码。2022 年 10 月(发布三年后),CockroachDB 19.2 中 BSL 下的部分代码将转换为 APL,补丁版本也会随之转变为 APL。其它版本的协议转换时间以此类推,例如 CockroachDB 20.1 计划在 2020 年 4 月发布,于 2023 年 4 月成为开源软件。
开源和商业的关系绝不是简单的对立:没有开源的基础技术是没有生命力,很难被广泛应用;而商业体现了开源项目的价值,也反向推动了开源项目的发展和生态的建立。所以开源项目如何在开源和商业找到一个平衡点,是很多开源团队在思考的问题,希望 CockroachDB 团队的尝试能够给大家更多启发。