This is a really negative trend for Open Source, and I hope it runs its course and dies out soon. License proliferation, bizarre "field of use" restrictions, blurring the line between what is open and what isn't, none of this stuff is a win for anybody. If you want to make something proprietary, make it proprietary, call it proprietary, and let that be the end of it. If you want to make something Open Source, then make it Open Source and don't try to straddle the line.
Open source is not synonymous with free software. The world is evolving and so open source should also evolve with it. Confluent have made it abundantly clear that the Apache Kafka project is and always will be Apache 2 licensed. Therefore that's where you go for your completely free solution. The community license is additional features free for use but not for you to provide as a managed service. Enterprise is something you have to pay for.
There's clear distinction and delineation between these. To an outside observer this might seem confusing and nuanced. In which case use the apache 2 licensed software which should unquestionably be open source and free. But otherwise those building businesses around open source technology have to find a way to protect against cloud providers. Licensing innovation is the only path forward right now until the cloud providers start to philosophically realign themselves back with what open source stood for and stop being bad actors.
The community license is additional features free for use but not for you to provide as a managed service.
IOW, "not Open Source". And that's fine... a company has a right to create software using any licensing terms they want. But making something that's "almost OSS, but not quite" and trying to steal the sheen of respectability that comes from being OSS, while not actually being OSS, is disingenuous and misleading.
Additionally, license proliferation in general is a Bad Thing because it muddles the issue around what's really Open Source and what isn't, especially for new-comers.
The world is evolving and so open source should also evolve with it.
Not all evolutionary steps are good things, in real life, or in metaphor-space.
until the cloud providers start to philosophically realign themselves back with what open source stood for and stop being bad actors.
There have always been people who used OSS without contributing back. There's nothing novel about this w/r/t cloud providers. And it's very questionable how you can consider somebody a "bad actor" for using a project under the terms that it was explicitly licensed under.
"Open Source" has a very specific meaning[1], that goes beyond the mere availability of the source code. And these terms violate article 6 of the OSD, meaning that code licensed this way is not Open Source.
And yes, yes, I know the old saw that "The OSI doesn't have a trademark on Open Source". That's irrelevant. In practical terms, the de-facto definition of "Open Source" is the OSD.
The only time I have an issue with this sort of setup is when the commercial entity employs, or directly is itself, a primary maintainer of the open source project (not sure how that works for Confluent and Kafka). It creates an incentive structure that is counter to the community at large. e.g. a PR is issued to the open source project that makes a piece of the commercial product irrelevant. For the community that's good, for the maintainer it threatens their livelihood.
Some of these projects wouldn't exist without commercial support, so it's not a clear cut issue, but I get why people are bothered by it.
a primary maintainer of the open source project (not sure how that works for Confluent and Kafka).
In theory Apache projects are supposed to exist in such a way that one vendor doesn't dominate all the decision making and development. In reality, it's not uncommon for a given vendor to have outsized influence on a given project. See: Ambari and Hortonworks, for example.
I don't follow Kafka development super closely, but I believe Confluent do have significant influence, but I'm not sure if it's to an extent that could be considered dangerous or not.
It is also far more dependent on personality of project leadership and contributors than pure % of code committed. Jay is well-regarded as a 'good guy' and has the interest of the technology at heart. Such personalities in leadership can change a project greatly though. A bad project leader may lose a great deal of public goodwill in an open source project. That is a key intangible that many do not take into account -- trustworthiness of leadership.
> Open source is not synonymous with free software.
This is literally the point of Open Source. It is "Free Software" repackaged for business people who hate ideals and morals as part of the story for the development of software.
I agree very strongly with the penultimate paragraph there.
"Methods of development are tools being used to protect software freedom, which in turn is a tool to protect user freedom. User freedom, and what we get from that, is what’s valuable."
But Open Source and Free Software are not synonyms, as the rest of the article shows.
Open Source cannot account for itself or for why anything other than "having the source" is necessary. Free Software cannot accept just "having the source" on locked-down systems.
As the article shows, "Open Source" confuses epiphenomena (source availability) and affordances (collaborative development) of Free Software with its primary goal.
We see that confusion mislead people time and time again. It's doing so elsewhere in this discussion.
So if Open Source was named not to help corporations avoid talking about freedom but to avoid confusing people it has failed in its intended as well as its adopted usage.
> software freedom, which in turn is a tool to protect user freedom
is AFAIK an assumption, or has this ever been proven?
I mean, isn't it entirely possible that helping software startups protect their business model of whatever "near-enough" OS/free software they build will help user freedom more than taking a purist OSS stance and leaving it all up for grabs by Amazon, Alibaba etc.? Because of increased choice and competition?
I agree that the proliferation of new licenses is annoying. But I think the reason you see changes in licensing from Elastic, MongoDB, etc is that the world has changed pretty dramatically since most of the original licenses were created. This proliferation existed early on in the days of open source and eventually died down to a set of standard things that solved the problems most people had. But the reality is the public cloud has dramatically changed the dynamic and many of the people who want to make code available with a permissive license don't have an option that is common and well understood and that protects them. I believe such a thing will likely emerge and will allow us all to standardize.
> many of the people who want to make code available with a permissive license don't have an option that is common and well understood and that protects them.
The AGPL is that option. It is a copyleft license that explicitly regulates the 'public performance' of software (putting conditions on public performance of a copyrighted work is a right of all copyright owners, there's nothing "exotic" involved here) in order to close the perceived 'service provider loophole' where software that's made available as part of an application services platform is not required to make its complete source code available, including even modifications that are purportedly asserted to be "for internal use".
Short answer:
1. AGPL doesn't actually solve this problem. This is why MongoDB just moved away from AGPL.
2. AGPL is quite restrictive for people who want to use the software in proprietary applications but don't want to open source their own code. This is a really large proportion of usage for us and we don't want to restrict people in that way.
Say that your SaaS product to share pictures of cats uses database X, which is AGPL licensed. Depending on how you read the license, your SaaS product could have to be licensed as AGPL. Or not.
That ambiguity is why many companies won't touch the AGPL with a mile long pole.
The problem stems from companies that raise $100 million dollars to sell open source software after the project has already been popular for years. Then they complain all their free adoption/marketing from being open source isn't monetarily advantageous for them so they need to change the license. It's really a bait and switch.
I'm as sad as you are about licensing complications, but I can totally see why they're doing it. And I'd say it's miles better than these parts being closed.
They could adopt a different business model. Open source business models are hard.
What they're doing is changing to a proprietary license and keeping the business model. That's a fine thing for them to do, and lots of their customers are going to choose different software as a result.
It's just a push back against free software as always. It's the same kind of attacks as always, back when Ballmer called the GPL "cancer", except that now that "open" and "community" are part of the lexicon, so they have to be sneakier about how they fight back. They use the same words but introduce the same tired old kind of restrictions. Whether it's about not being able to use the software in a server or not being allowed to redistribute the software in a CD, it's just the same kind of restriction for a different medium.
It's not free, it's not open. It's an attack on freedom and openness as usual.
You can rant about an "attack on freedom" all you want, but how do you propose that Confluent protect its business so that they can continue paying their engineers to keep working on tools for which they publish all the source code?
The alternatives seem to be 1. they keep all their stuff proprietary or 2. they leave it truly open and AWS takes the majority of their market and they slowly suffocate.
Aren't both of those strictly worse than the path they've taken?
Other than the pure ideal of software freedom, what practically is bad about this kind of dual licensing? And how is this in any way tantamount to calling the GPL "cancer" (which, in all fairness, does spread somewhat like cancer throughout a codebase, regardless of whether you think that's a good or bad thing).
At least in this case, they are being more clear about what they are doing and not claiming their new license is Open Source or trying to poison an existing Open Source license, the way some other companies are doing things.
I agree that it is always sad to see a company closing its (future) source code like this, but such is their perogative.
or trying to poison an existing Open Source license
Yes, kudos to Confluent for at least creating a new license, as opposed to adopting "Commons Clause + Apache" or something.
All of this said, even though I don't particularly like this "you can do everything except build a SaaS of this project" model, if people are going to do this, I hope that eventually things consolidate to where there's one de-facto standard "Shared Source - Non-SaaS" license.
Speaking as someone who makes a living contributing to open source, it's a frustrating trend that the major cloud providers (Amazon being the worst offender) have decided that it's in their interests to take open source projects and never contribute back or even interact with the community.
It's less clear to me whether this is rational on their part - whether the incentives have actually changed. It's generally been in companies' best interest to contribute back to open source projects they are building products around, because:
You need to contribute to projects to influence the direction of them.
And you will need to make changes or fixes to your version of the project, and the maintenance cost of an upstreamed patch is much lower than the cost of maintaining an ever-growing stack of custom patches.
I've seen companies before make the bet that they are better off forking a large project because they can "move faster". And it is true for the first year or two, but after a while the burden of keeping up with the backporting of changes from upstream takes multiple engineers spending large chunks of their time to keep up with.
In some cases you might be able to offset this just by hiring more engineers, but how many of the best engineers really want to work on backporting changes to a bizarro fork of an open source project? I suspect this is the bet the cloud providers are making - that they can grow the product fast enough to the point where they can throw money at it. We'll see how that works out for them.
I work for Amazon Web Services, and I will risk responding to the first and only comment from a brand new account.
Amazon does contribute back and does interact with open source communities. You can find information on AWS's open source activities here: https://aws.amazon.com/opensource/
The page hasn't been updated for some of the latest news, such as releasing the Firecracker virtualization technology as open source: https://firecracker-microvm.github.io/
"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.
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):
I kinda expected this after recently revealed AWS Managed Kafka. AWS can afford to release half baked products because platform inertia and that will easily cannibalize whatever traction SaaS offerings of Elastic, Kafka, Mongo etc has.
That's a great point. I can only hope that platform providers who productize open-source packages are giving back a significant chunk of revenue to the project, either in cash or in employees contributing labor.
The submission title is misleading (“License Changes for Confluent Platform (Kafka)” at time of commenting) - the license changes do not apply to Kafka itself, as the article specifically states.
The way it was mentioned in the title was misleading, but mentioning Kafka at all was useful. How about `License Changes for Confluent Platform (Kafka distribution)`?
No, this has no effect on Kafka, which is part of the ASF and under the Apache 2.0 license. This just impacts things like KSQL that are part of Confluent Platform.
