Hacker News new | ask | show | jobs
by boredandroid 2745 days ago
Hi all, I'm Jay Kreps, the CEO of Confluent and author of that blog post. I'm happy to answer any questions.
3 comments

The first sentence of your blog post reads:

"We’re changing the license for some of the open source components of Confluent Platform from Apache 2.0 to the Confluent Community License."

This implies that the components are still open source. However, as you probably know from the open source definition: https://opensource.org/osd-annotated your new license does not qualify as "open source" by the most commonly understood definition because it violates article 6 "No Discrimination Against Fields of Endeavor." Specifically, you're not allowing your software to be used in a capacity similar to how you use it yourself.

Wouldn't it be less disingenuous to write "We’re changing the license for some of the previously open source components of Confluent Platform from Apache 2.0 to our own partially proprietary Confluent Community License." Or maybe instead of partially proprietary, shared source, or choose your own word for not really open source?

Edit: My original comment was based on the original blog post, which has now changed. Props to the author for being responsive to feedback.

Sure, I've updated the post so it doesn't imply that we comply with the OSI open source definition.
Could you be more explicit and say that it means the software isn't "open source"? Complying with OSI's definition of "open source" is what "open source" means. They defined the term, so they have a prerogative on what it means.

"Visible source" might be a good description if you want to call it something, but don't confuse your users with "open" and "community" and other feel-good terms.

Why not just use Affero GNU General Public License v3 for these? It seems like a lot of you guys are using ASL 2.0 (a permissive license) and getting upset when people fork and proprietarize the code for their services and solutions.

Aside from MongoDB, who seems to be changing the license simply to kill off MongoDB's vendor ecosystem to benefit itself, everyone else seems to be using ASL 2.0 and then regretting the natural consequences of doing so.

The usage of the AGPLv3 license seems to be enough to ward off large SaaS competitors (Amazon and Google stay away from areas that are heavily AGPLv3 or similar).

This is a great question. Many people think the AGPL solves this problem but it absolutely does not. This is why MongoDB, which was AGPL licensed, just changed to a custom license.

The other reason we don't want to use AGPL is that it can be quite aggressive in making you open source your own code if you want to embed our code in a proprietary application. We actually think building proprietary applications is a fine use of our software, and is one of the major use cases for this kind of infrastructure. This is addressed in more depth along with many other questions in this FAQ: https://www.confluent.io/confluent-community-license-faq

> This is a great question. Many people think the AGPL solves this problem but it absolutely does not. This is why MongoDB, which was AGPL licensed, just changed to a custom license.

If the goal is to kill off all potential vendors participating in your ecosystem, then yes, AGPL doesn't work. But if the goal is to prevent cloud provider abuse (e.g. Google, AWS, Azure, etc.), it works well enough.

> The other reason we don't want to use AGPL is that it can be quite aggressive in making you open source your own code if you want to embed our code in a proprietary application.

If you wanted to avoid that, you could grant an exception to be slightly more permissive for that purpose or to otherwise clarify the grant of use.

I know I personally would appreciate it if vendors who don't like the consequences of using ASL 2.0 would consider this option as an alternative.

And of course, selling full exceptions to AGPL in its entirety is a valid business model option.

Hey Jay. Just want to say good job on the execution on this. It's clearly articulated and goes along way to show the industry how and why this needs to happen.
I also give it a +1. There's a lot of debate presently around what I call the "Little Red Hen" problem. Everyone wants to "eat the bread" when y'all are done, but very few people want to help grind the grain or knead the dough.

There's a document gathering people's thoughts on the current state of Open Source here, started by Jesse Anderson (formerly Cloudera):

"Viewpoints on Open Source Interview Responses" https://docs.google.com/document/d/1tLNerYJ5ce8PjGjGgRFfzKha...

+1 from me as well. Well done.
Thanks!