31–40 of 53 posts
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.
Earlier quoted context omitted.
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…
> 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…
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.
Earlier quoted context omitted.
Open source is not synonymous with free software. 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 come…
Why, the source is open. You can use it to look for bugs, to make your own optimized / customized / verified build, etc. 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.
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 ma…
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.
Earlier quoted context omitted.
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 unders…
Sure, I've updated the post so it doesn't imply that we comply with the OSI open source definition.
"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.
Earlier quoted context omitted.
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…
> 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…
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.
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 ma…
It's the same old thing since 1998. 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 t…
Earlier quoted context omitted.
> 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…
The AGPL isn't well defined. 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 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.
Yes, we've dropped the mention of Kafka. Submitters: please, if you follow the guidelines by not editorializing titles we won't have this confusion.
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.