Confluent Creates New 'Open Source' License to Stop Cloud Poaching

Last week Confluent added a new license to the mix it uses to cover its open source data streaming products. Until now, the company has relied on a single license to cover its open source offerings, Apache 2.0, which is a favorite among enterprise users because it allows the code to be incorporated within proprietary projects. The company also employs a proprietary license for its paid "enterprise" editions.

The new license, the Confluent Community License, will cover only a small portion of Confluent's stack, mostly centered around KSQL, the company's streaming SQL engine for Apache Kafka. On the surface, the new license is little different from Apache, with the important added caveat that KSQL and other covered software can't be offered as cloud services.

"[Y]ou can use KSQL however you see fit as an ingredient in your own products or services, whether those products are delivered as software or as SaaS, but you cannot create a KSQL-as-a-service offering," Jay Kreps, Confluent's co-founder and CEO, explained in a blog. "We’ll still be doing all development out in the open and accepting pull requests and feature suggestions. For those who aren’t commercial cloud providers, i.e. 99.9999 percent of the users of these projects, this adds no meaningful restriction on what they can do with the software, while allowing us to continue investing heavily in its creation."

Components of Confluent's platform

The problem is that such restrictions run afoul of the Open Source Definition used by the Open Source Initiative, the standards organization that decides which licenses qualify as open source. The restriction also means that any code covered by the license probably can't be used within any other open source project.

The Problem With Restricting Open Source(x)-as-a-Service

The reason for the change centers on public clouds, which are increasingly offering users the ability to take advantage of fully supported and integrated open source services, with user fees bypassing software developers who contribute to the open source projects and going directly into the bank accounts of the likes of Amazon Web Services, Google Cloud Platform, and Microsoft Azure. Last month at re:Invent 2018, AWS unveiled a managed version of Kafka, which puts the cloud provider in direct competition with Confluent.

Confluent is only the latest in a line of open source companies that have decided to fight what they see as unfair competition from cloud providers. It started in May when Neo4j added the Commons Clause to the AGPL license that had previously covered the software. In August, in-memory database startup Redis made a similar move when it changed the licensing on its Redis Modules from the AGPL to a licensing scheme that combines Apache 2.0 with the Commons Clause.

The Commons Clause, according to its authors, is a license addendum that allows "all permissions of the original license to remain except the ability to 'sell' the software." That exception, however, means that the clause effectively becomes the software license, reducing the underlying license to guideline status and changing the nature of the project from "open source" to "source available" (a term used by the clause's authors). It also makes the code not compatible with the underlying license. Redis Module code, for example, cannot be used in other Apache 2.0 projects because the Commons Clause restrictions are not part of the Apache license.

The same goes for Confluent's new license solution. Even though its license is based-on Apache 2.0, the restrictions against "KSQL-as-a-service" makes it incompatible with Apache and other open source licenses.

"Both have 'field of use' restrictions, which make them not only incompatible with the ALv2, but also make them non-open source licenses," Jim Jagielski, co-founder of the Apache Foundation, told Data Center Knowledge.

MongoDB Takes a Different Route

In October, NoSQL database company MongoDB took a tack similar to Confluent's by coming up with a new license, Server Side Public License (SSPL), to apply to it's MongoDB Community Server. However, unlike the other "solutions" to cloud poaching, MongoDB is attempting to retain the open source nature of the project by not outlawing the use of Community Server as an online service and instead stating conditions that must be met in order to deploy projects licensed under the SSPL as a service.

"A company that offers a publicly available MongoDB as a service must open source the software it uses to offer such service, including the management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software, and hosting software, all such that a user could run an instance of the service using the source code made available," the company said on a web page explaining the license.

Since then, MongoDB has been working to dot all the i's and cross all the t's in its attempt to get the new license approved. In late November, the company submitted version 2 of the license, which seeks to address some concerns that had been expressed by the OSI community's consideration of the first version. If approved, the company says it will use this version for its products going forward.