Confluent restricts competing hosted services for selected platform components

A source repository can remain publicly readable while the permission to offer its software changes. Confluent's December 14 licensing announcement makes that distinction explicit for selected components of Confluent Platform. Their license changes from Apache 2.0 to the Confluent Community License, with a restriction on competing hosted offerings. Apache Kafka itself remains Apache 2.0.

The practical distinction is between using a component inside another product and offering that component itself as a competing service. Jay Kreps's announcement uses KSQL as the example. It says a company can use KSQL as an ingredient in its own software or SaaS product, while it cannot offer KSQL itself as a competing managed service under the new terms.

I value Kafka's retained log because independent consumers can derive different results from the same history. The surrounding ecosystem determines which processing and integration tools those consumers can use. A licensing change in that ecosystem therefore matters even when the broker's protocol and license remain unchanged.

The restriction depends on the service being offered

The Confluent Community License version 1.0 grants rights to use, modify, reproduce and distribute the covered software, subject to its terms. It then excludes exercising those rights for a competing online service that provides the software. The excluded category covers SaaS, platform services, infrastructure services and similar online offerings.

This is a restriction on a particular use of the implementation. The software can remain available in source form and permit modifications while forbidding that use. Those permissions and that exclusion can coexist, which is why describing the change only as code remaining on GitHub omits the relevant difference for a service provider.

The announcement's KSQL example helps identify the intended boundary. An application using KSQL internally to process its own events has a different product relationship from an offering whose customer is buying managed access to KSQL. Both may involve networked software and paying customers, but the role of the covered component in the offered service differs.

This does not turn the license into a general prohibition on commercial activity. The announcement expressly allows commercial products and SaaS uses outside the excluded category. Calling it a non-commercial license would therefore describe a broader restriction than the published explanation gives. The restriction is tied to competing services providing the covered software.

For engineering work, the resulting question includes how the implementation is exposed to customers. A dependency inventory names the component and version. A service description explains what customers receive from it. Both become relevant when the permission depends on the kind of offering made with that component.

Public development and open-source permissions are separate

Confluent says development will continue publicly, with pull requests and feature suggestions accepted. That preserves an observable development process. It does not restore a permission expressly excluded by the license. Being able to inspect or contribute to code is a different property from being allowed to use it for every commercial service model.

The Open Source Definition, version 1.9 dated March 2007, makes source access one requirement among several. It also requires that a license not restrict use in a particular field of endeavor. A license designed to exclude a category of hosted services should consequently be distinguished from the unrestricted-use expectation attached to that definition.

Source-available is the useful description of the changed permission model. It communicates that the implementation can be inspected without implying that every use allowed by a permissive open-source license remains available. The difference matters most to a party considering the very service category the new terms exclude.

That terminology also helps ordinary users understand what has and has not changed. A readable implementation remains useful for debugging or proposing a patch. A license assessment still needs to account for the permitted purposes. One does not cancel the value of the other, but neither can substitute for it.

I prefer to name that tradeoff plainly. Public implementation is valuable, and restrictions on offering an implementation as a service reduce the choices available to potential providers. Whether the restriction affects a particular application depends on its actual role in the service, not on whether its developers can clone the repository.

Apache Kafka remains a separate project with separate terms

The announcement explicitly excludes Apache Kafka from the change. Kafka is developed through the Apache Software Foundation and remains under the Apache License 2.0. Confluent also says it will continue contributing there. A licensing change to selected Confluent-maintained components is therefore not a relicensing of the Kafka broker.

That separation matters because a platform distribution can contain software with different origins and terms. The distribution name alone cannot identify the permission attached to every component. A broker and a processing service may participate in one application architecture while their implementations have different licenses.

Apache 2.0's grant and redistribution conditions do not contain the competing hosted-service exclusion introduced here. Its conditions include providing the license and retaining applicable notices when distributing covered work, with modified files carrying change notices. Those obligations differ in kind from deciding whether an online offering competes with a licensor's service.

The distinction also reaches technical evaluations. A Kafka-compatible protocol identifies how programs communicate. It does not identify the license of every implementation using that protocol. Swapping a processing component or choosing a managed service requires information about its implementation and distribution, in addition to whether existing clients can connect.

A deployment record can preserve those identities without treating the whole platform as one license. Naming the component version and its accompanying license makes the relevant terms inspectable. Naming the broker separately prevents an unrelated component change from being reported as a change to Kafka itself.

The commercial rationale concerns funding and cloud distribution

Kreps presents the change as a way to keep funding software distributed without charge. His argument is that distributed data systems require sustained engineering investment, while a cloud provider can package permissively licensed work into its own service and invest in proprietary differentiation. The announcement identifies that economic relationship as the reason for excluding competing hosted offerings.

This is the vendor's rationale, rather than a technical guarantee that the new license will produce a particular maintenance outcome. The announcement does not establish a measurable relationship between the restriction and future defect rates. It states which business model Confluent intends to protect and how it expects that protection to support continued investment.

The tradeoff can be analyzed without adopting every broader claim in that argument. A restriction may protect the vendor's ability to sell its managed implementation. It also removes the corresponding option from other parties relying solely on the published license. Customers building an application with the component and companies selling the component as a service consequently face different effects.

Confluent's 2017 Cloud announcement supplies context for the service side of that decision. It presented managed operation as the product while retaining Kafka-compatible APIs. The December licensing change concerns the terms under which selected implementations around that ecosystem can be used for competing service offerings. API compatibility and implementation licensing remain separate properties throughout that model.

Redistribution still has explicit conditions

The Community License also requires modified software to carry modification notices and requires preserving the applicable proprietary notices with distributed copies. It permits separate terms for a licensee's modifications, while the recipient's rights to the underlying covered software remain governed by the Community License. Those details matter to an organization redistributing a modified component, even when its use is outside the excluded service category.

The agreement does not grant a right to sublicense the underlying software. Instead, a recipient can exercise the granted rights by accepting the agreement's terms. This makes it useful to distinguish the license a distributor places on its own modifications from the terms accompanying the underlying component. Combining them in one shipped artifact does not erase that difference.

The announcement is consequently more than a statement about where development takes place. It changes a permission relevant to a specific delivery model and leaves other identified permissions available under conditions. The engineering description needs the component's role in the delivered system as well as its package identity.

I find that level of detail necessary for a streaming architecture because the log often outlives individual applications and deployment choices. A decision to expose a processing implementation as a customer-facing service has a different relationship to these terms from using it behind an application's own interface. Kafka's unchanged Apache license remains one fact in that architecture, while the selected Confluent component and the purpose of its deployment supply the facts needed to understand the December restriction.