A Developer’s Guide to the Confluent Community License

Last week we announced that we changed the license of some of the components of Confluent Platform from Apache 2.0 to the Confluent Community License. We are really grateful to our community for their understanding and support in making this change. Changes to a licensing model can be confusing, so I want to highlight some important elements of this license to provide my perspective on what I think this means for you.Let’s get two important points out of the way up front. First, Apache Kafka^® was completely unaffected by this change; the change applied only to some of the Confluent components. Second, software made available under this license is not open source because the license does not meet the Open Source Initiative’s Open Source Definition. But from the perspective of the vast majority of users, things have changed very little. You can access the source code and modify and redistribute it; there is only one thing you cannot do, and that is use these components to make a competing SaaS offering. So while there is a restriction on our license, it is intended to apply to a very small set of use cases. This restriction is called an “Excluded Purpose” which reads as follows:

“Excluded Purpose” is making available any software-as a-service, platform-as-a-service, infrastructure-as-a-service or other similar online service that competes with Confluent products or services that provide the software.

Now let’s get into some of the subtler yet important elements.

I’m building a SaaS product. Does this license in some way prohibit my use of Confluent Community software?

Put simply, no, unless you are using the Confluent code to create a SaaS product that is competitive with the particular Confluent products we have licensed to you. Let’s go through a specific example. Say that you are building a SaaS hotel booking engine and you want to include KSQL in the implementation. You can do that because your service does not compete with any Confluent product that “provides the software.” KSQL is a streaming SQL engine, and is clearly not directed to the same market or purpose as a hotel booking engine.

What happens if, in the future, Confluent creates a new SaaS product that competes with my product? Would that put me in violation of the license?

This is best explained by expanding on the example above. Say you have a SaaS hotel booking engine that uses KSQL. Later Confluent releases a new SaaS product that does hotel bookings. Are you in trouble? No, in this case you would still be OK.

The important thing to note is that the license clause doesn’t restrict you from competing with Confluent (the company), but rather, from competing with the product you licensed, in this example, KSQL. So if you’re using KSQL in your hotel booking engine you only need to make sure your use does not compete with Confluent’s SaaS offering of KSQL.

You might also ask, does using KSQL limit future products my company might build? What if my company decides someday that streaming SQL is a key new market for us—would our usage of KSQL in the hotel booking engine preclude this? The answer is no, so long as you are not using KSQL to build a competing streaming SQL SaaS product.

So in summary, in this example, you can use KSQL, and you can compete with Confluent, but you can’t use KSQL to build a SaaS product that competes with Confluent’s KSQL service.

Why did you create a new license?

There is no standardized, “limited purpose” license yet. We went with a solution that grants most of the same rights as does Apache 2.0. We defined our excluded purpose as narrowly as possible to accomplish our purpose. If a standard solution in the space emerges, we’re open to considering that.

Is the Confluent Community License a EULA? An open source license? Something else?

There are many kinds of software licenses. A EULA is an end user license agreement. By definition, it grants only the “right to use” software. An open source license is a license that meets the Open Source Definition. The Confluent Community License is neither of those types. It is a class of license that is very common and becoming more common every day—a “source-available” license. A source-available license is not a new idea, nor a radical one.

Some of the language used in the Confluent Community License is similar to language used in EULAs or other licenses. One of these similarities is acceptance language (sometimes referred to as an “assent clause”). Acceptance language makes the license a legal contract—it states that by using or accessing the software, you’re agreeing to the license.

Having an acceptance clause doesn’t make a document a EULA; it makes it a contract. In fact, open source licenses like Creative Commons BY, the Open Database License and the Eclipse Public License are styled as contracts. Importantly, there is no rule that a contract is not a license, regardless of the type of license.

Does the Confluent Community License change my ownership of my code?

No. Copyright law dictates your ownership in this case, and of course our license doesn’t change copyright law. Our change from Apache 2.0 to the Confluent Community License doesn’t impact the ownership of our code base, the ownership of any changes you might make to it or the ownership of any compiled programs built with those changes.

Summary

So, in summary the Confluent Community License has been designed to let you make broad use of Confluent Community software including downloading, modifying and redistributing the code. It restricts certain competitive use cases, but describes that restriction as narrowly as possible so that you can determine whether you would be engaging in that restricted use. For your convenience, we’ve collected a broader set of questions and answers in our Confluent Community License FAQ.