License Changes for Confluent Platform
confluent.io
confluent.io
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.
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.
http://deblanc.net/blog/2018/12/13/the-osd-and-user-freedom/
"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?
Nobody is saying that it is.
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.
The change applies to making the running code available in certain ways, not to access to the source.
I wonder how "free as in freedom" such software is, though. OTOH AGPL is considered "free software" by GNU, so this likely is, too.
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.
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.
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.
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.
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.
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".
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.
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.
I agree that it is always sad to see a company closing its (future) source code like this, but such is their perogative.
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.
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.
"Viral" and "cancer" are catchy memes but the GPL doesn't just inexplicably leap to software that is sat next to it minding its own business.
The GPL is inheritance, not contagion. But it's difficult to talk smack about that without sounding even creepier.
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?
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/
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).
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
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.
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...
"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.
"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.