注意事项 佩雷夫 ：开放源代码许可证提供的灵活性和自由性使大型SaaS解决方案的现代提供商可以质疑从事开发受欢迎的开放源代码项目的小型企业的成功。 在本文中，来自CockroachDB（一种分布式且容错的RDBMS）的作者全面揭示了该问题的实质以及解决该问题的可能方法。
CockroachDB被认为是开源软件。 自该项目出现在GitHub
（代码于2014年2月首次发布- 大约是Transl。 ）以来的岁月中，我们遵循了一种相对典型的开发路径，在开源哲学与创建可行业务之间取得了平衡。 主要代码是根据Apache许可证2（APL）许可的，已启动了托管服务，并且一些公司的附加组件是根据企业许可证发行的。
但是，我们过去关于
正确的业务模型的想法
是基于OSS世界的关键准则的：您可以围绕功能强大的开源产品建立业务，而无需假设更大的技术公司会提供与服务相同的产品。 该规范不再有效。
原则上，从法律上讲，没有什么能阻止竞争对手提供由另一家公司创建的即服务OSS产品。 现在我们看到这确实在发生。 今天，我们目睹了利用自身独特地位并提供OSS产品即服务版本的高度集成的提供商数量的增加。 显然，它们的高度集成极大地增强了用户体验。 最近，这发生在Amazon“借用”的ElasticSearch的分支上（
TechCrunch文章中的Salil Deshpande巧妙地描述了发生的“自我服务和理性”）。
针对这种不正当竞争，我们更改了许可条款。 详情在下面的
GitHub中提供。 简要更改如下：
从今天开始，我们将引入独家许可的业务源许可证（BSL）版本。 CockroachDB用户可以将我们的DBMS扩展到任意数量的节点。 他们可以自由使用CockroachDB并将其集成到应用程序中（无论是将其交付给消费者还是作为服务提供）。 您还可以将CockroachDB作为服务来实现公司的内部目标。 您唯一不能做的就是无需购买适当的许可证即可将CockroachDB商业版本作为服务提供 。
为了确保项目的进一步发展，我们的限制有一个移动时间限制：发布后三年，许可证变成了标准的Apache 2.0许可证。 通过更改许可条件并引入时间限制，我们有两个目标：
- 创建竞争性数据库即服务（DbaaS）
- 在此过程中，请确保主产品保持完全打开状态。
各种开源许可方式的比较
一些公司已经将其产品许可用于类似的双重用途。 评估现有方法后，我们发现它们都倾向于两种主要方法：copyleft和多级模型。 不幸的是，它们都不符合我们想要通过更改许可证来实现的目标。
Copyleft模型
Copyleft传统的创始人是GNU GPL。 其目的是防止出现专有叉，在某些情况下需要发布源代码。 Affero通用公共许可证（AGPL）和姊妹服务器端公共许可证（SSPL）属于此阵营。 在SSPL中，要特别注意竞争性服务的问题。
但是，我们认为所有这些许可证都是多余且不足的。 从细节上讲，它们是多余的，而copyleft要求也不总是很清楚。 潜在的范围太广的代码公开要求使许多潜在用户感到恐惧。 从竞争者已经准备好并且可以透露足够多的代码的角度来看，它们是不够的，这样他们就不会有任何疑问，同时也不会给核心技术的开发人员带来任何好处。 亚马逊通过
Open Distro for Elasticsearch做到了这一点，尽管copyleft许可证不需要这样做。
我们需要更简单，更严格的工具。
分层模型
我们还考虑了使用三级模型的可能性：开放源代码内核，企业组件和某些中间层，这些中间层的功能的源代码已关闭，但可以完全免费使用。 这种模型在软件界非常流行。 到目前为止，我们已经使用了一些变体。
但是，它为我们公司生成了错误的信息。 事实证明，在开放的核心中实现新功能对我们无利可图，将所有精力集中在封闭的组件上是有意义的。 实际上，我们很想欺骗用户的信任，并隐藏批量许可证最有趣的功能。 从长远来看，这种方法对于开源生态系统而言并不是好兆头。
找到的解决方案：BSL
我们开始研究有时间限制的许可证，发现不需要从头开始创建新的许可证。 MariaDB的业务源许可证（BSL）1.1版包含您需要的所有内容，并且已经
获得 OSI创始人Bruce Perens的
批准 。 BSL是
参数化许可证，因此我们使用它的方式与MariaDB不同。
关键区别在于附加使用授权-例如，MariaDB允许
在最多三台服务器上使用MaxScale。 CockroachDB的“
附加使用授权”使您可以在任意数量的节点上使用我们的产品，前提是您不将其作为商业DbaaS提供。 三年来，我们的BSL版本保护了现有的CockroachDB代码，使其不被用作DBaaS，而无需获取适当的批量许可。 3年后，将取消此限制，并且代码将变为开放状态（在Apache许可证中已嵌入），并且可以随意将其用于任何目的。
我们将此许可证应用于CockroachDB的基本版本（即以前适用于Apache 2.0的代码）。 这意味着CockroachDB内核不再开放（根据OSI的
开源定义 ），尽管完整的代码仍然可用，并且除DBaaS之外，任何商业用途都被允许。 我们认为，这是平衡业务需求与我们的开源承诺的最佳方法。 新许可证允许绝大多数用户自由使用，分发和修改CockroachDB代码（三年后，它无条件开放）。
什么是：BSL的工作方式
我们将引入从版本19.2开始的新CockroachDB许可证。 现在，如果未与Cockroach Labs达成适当的协议，则该代码将无法用于组织商业数据库即服务（DBaaS）。 每次发布的有效期为三年。
CockroachDB企业附加组件将继续根据Cockroach社区许可（CCL）发行。 与他们合作需要与Cockroach Labs达成适当的许可协议； 三年后，该许可将不会转换为开放源代码。
让我们用一个具体的例子来解释。 CockroachDB 19.2（计划于2019年10月发布）将是第一个遵守新许可计划的版本。 它将包括BSL和CCL下的代码。 在2022年10月（发布三年后），属于BSL的CockroachDB 19.2部分将转换为APL。 补丁程序不会更改转换日期：所有19.2.x版本都将在2022年10月进行转换，尽管那时只有三年的基本版本19.2.0将执行三年。 CockroachDB 20.1（计划于2020年4月发布）将于2023年4月打开，依此类推。
旧版本将不受影响：CockroachDB 19.1将继续在Apache许可下工作，并且所有将来的补丁19.1.x也将根据APL发行。
我们致力于开源的理念，并努力创建功能强大的开源产品。 尽管BSL正式不是开放源代码许可，但这种折衷方案与开放源代码的精神最接近，但同时也保护了我们的业务。 此外，发布三年后，我们对开源软件理念的承诺会自动得到重申。 我们相信，在这种新现实中，选择的途径将使我们能够为公司提供支持，同时保护开源的丰富传统。
译者的PS
另请参阅我们的博客：