If they'd instead chose to fork the plugins themselves (the only parts where the licenses changed, all except two are Apache V2) then all users can pick and choose which ones they include in their projects, and it doesn't fragment the ecosystem at all. Your plugins would compile in my project, and mine would compile in yours.
The part they're choosing to fork here, which will cause this rift in the community, is still MIT licensed: https://github.com/redpanda-data/benthos. If they simply chose to continue using this MIT part we can all live happily together in a utopian society fully saturated with plugged blobbery.
Edit: I'm bit a baby brained so I forgot that I'm literally streaming live in 30 minutes in order to explain all the changes in detail for those out of the loop: https://www.youtube.com/watch?v=X8nVdUuWZ80
But if I used a project, and that project's new owner hostilely relicensed parts of it, I'd assume that other parts are likely to go down the same path. I can understand why someone would want to make sure code developed under the previous social contract remains accessible and updated under the same terms.
You're also at the same risk if you choose to use their fork.
If you are committing to that then you should say so.
UPDATE: just watched the blobstream and realized there is exactly a repo called “redpanda-data/benthos” with the MIT components. Nice!
TLDR: They don't trust Redpanda to not pull the rug again later.
Finally, Redpanda did some partnerships with vendors nobody cares about whose businesses are at risk to show how you are opening up the ecosystem.
It actually comes off as somewhat malicious and Ashley's note where he notes he didn't read the article also comes off as not caring about developers (even insofar as he has facts wrong -- if the plug APIs remain compatible this creates more choice for users.)
I'm 100% committed to keep contributing to Benthos as long as it remains free and open source and I'm also happy to continue offering community support to whomever requests it on the official channels on Discord, Slack, GitHub etc.
A complete rebranding suggests that the original OSS project will no longer be managed as its own independent entity. I think that alone gives good reason to fork.
You basically took the same route as these companies and while your intent may be different, from the outside it looks like another company making a grab an Open Source software with changing licences and renaming products.
Again, it may not be your intent but you made the first mistake in marketing which is - see how others have done it and what the outcome it.
For me as a Tech Lead/Architect - currently looking at event-based architecture, this is a bit of a turnoff of the entire product stack - because it suggests you might be lining things up to sell off.
I get that people having a problem with the way that your company does business might seem like a personal attack (especially if you're the CEO), but that sort of instant aggressive stance does nothing to alleviate people's concerns, and instead rather makes it seem like you're deliberately attempting to shut down a good faith conversation.
> Started relicensing some of the most critical integrations and connectors as proprietary2 under a completely different license
But left unsaid is which integrations got relicensed. I'm very curious to know!
Ok, from the Redpanda announcement, seems to be Splunk & Snowflake connectors that they have moved to enterprise plan features. I'm not sure this is exhaustive but I tend to think it is. Source: https://redpanda.com/blog/redpanda-connect
It does make me wonder & think, perhaps there's too monolithic an architecture if moving two connectors out of core & having bentho-snowflake and bentho-splunk forked off is too hard. Does the entire project really need a fork?
Over on X, you have the CEO of Confluent writing 18 tweets trying to stay relevant and throw shade at his two competitors drinking his milkshake. I like how he snuck in "Kafka will continue to be the default standard and reference implementation" in that stream of thought.
But I think I get the logic -- RedPanda maintains support (and a bit of control) of a very useful tool that complements RedPanda's core product (a drop-in Kafka replacement). In simple terms, RedPanda is stateful, Benthos is stateless, and Benthos is great for getting things into and out of a stateful thing.
Commoditize your complements, as Joel Spolsky said. [1]
Make it so no one can hinder developers getting data into (or out of) your database / message broker / stateful thing, and you'll reap the low-friction rewards of "developers finding it really easy to get stuff into and out of your system."
So I think I'm somewhat optimistic about all this.
I think the new owners have established a precedent that they're will make to make such drastic changes.
@emaxerrno > it's sad to see you leave when you can already host 99.1% of them on your site. You just have to call it Redpanda Connect. Additionally, I am not sure about the content copyrights of the docs. I'd double check. My proposal would be to have this work for multiple vendors. /2
@emaxerrno > There is plenty of money to be made in streaming, lots of exciting tech. If you decide to change your mind, we'll be here.
@emaxerrno > last the emphasis on "really hard not to fork" is hard to believe when you never reached out. again, happy to have multiple ppl charge and embed this in their own product for the apache 2 license connectors which is 223/225, just gotta be called Redpanda Connect.
Except for the implicit accusation in the first sentence of the last tweet, I completely don’t get what’s being said here. Maybe that’s fair given how little I know about the history here, it’s just been quite some time since I was so baffled by a piece of (supposedly conversational) English.
I don't know who's who here, but I do maintain an open source project, so do have a general interest in the topic. Yeah, it would be interesting to hear from the project which created the fork, how hard they tried not to fork. They claimed they worked really hard at it, but what did the hardship entail? It seems Redpanda says they was basically zero effort. Someone is not exactly being honest here...
> it's sad to see you leave when you can already host 99.1% of them on your site. You just have to call it Redpanda Connect. Additionally, I am not sure about the content copyrights of the docs. I'd double check. My proposal would be to have this work for multiple vendors. /2
One does not simply buy Open Source Software.
Until Redpanda actually makes any code changes, the ~three now-proprietary plugins are still available as Open Source Software: just browse to the commit before they slapped their license at the top.
These are all MIT and bit-for-bit identical to the now-proprietary plugins:
- Splunk HEC: https://github.com/redpanda-data/connect/blob/e653dc3f8a6eee...
- Snowflake: https://github.com/redpanda-data/connect/blob/e653dc3f8a6eee...
- Kafka topic logger: https://github.com/redpanda-data/connect/blob/e653dc3f8a6eee...
It would be interesting if there was a “no takebacks” enhancement to popular open-source licenses. Maybe the license could only change with a supermajority quorum of contributors.
The only exception to this is when corporate-backed projects sometimes insist that contributors assign copyright before accepting their contributions -- not sure if that's what's going on here, though.
What does happen with MIT or BSD projects is that since these licenses are not "viral" (in the sense that they do not require modifications or derivative works to be released under the same license), and because contributors do own the copyright to their own code, anyone can take an MIT/BSD project, and modify it or build their own work on top of it, then release their own version under a different license applicable to their work.
But that doesn't retroactively change the license for anything that was already BSD/MIT, it just produces a new work that mixes BSD/MIT-licensed code that was already out there with new code that is under a different license.
So no one can ever "take back" anything that already existed: they can only control their own subsequent work built on top of it.
github.com/redpanda-data/connect/v4@v4.28.0/internal/impl/snowflake/output_snowflake_put.go github.com/redpanda-data/connect/v4@v4.28.0/internal/impl/splunk/template_output.yaml
But also in an apparently unrelated file (Kafka seems to fall under Apache 2 from the website):
github.com/redpanda-data/connect/v4@v4.28.0/internal/impl/kafka/topic_logger.go
Now I am a bit puzzled. What's up with this?
I am furiously rewriting my way out of Benthos but I would like to keep the FreeBSD port in shape :D
A trip down memory lane:
Software licenses aren’t even required under the Copyright Act. It explicitly gives you permission to do that which you are supposedly licensed to do.
