Hey it's Ash (the maintainer being talked about in the blog). I'm not one for fork drama and I haven't had a chance to fully read the blog so I don't have a lot to say. However, this is a full fork of the entire codebase, which means plugin authors will need to choose one project or the other and are locked in, and is entirely unnecessary on both a technical and legal perspective.
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
I'm not involved in this, either as a developer or as a user.
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.
From the outside just the instant name change alone really reeks of embrace-extinguish imo, even if technically licensing of the core engine is unaffected. Benthos is a broad enough product to have an auxiliary ecosystem around it, with plugins, GUI editors, monitoring etc etc and we’ve seen a LOT of “technically open-core but rendered useless without paid features” type of products in recent years, from those types of companies. I would be extremely unsurprised if they creep in more hostile changes in the future to soften the blow too. I hope I’m wrong.
I actually have been using Benthos quite a bit recently. I have even contributed a little bit to the original project. This is a massive turn off for me. I'm really going to have to wait and see how things go before I keep using it, but I probably wont :(
Sure, if they change the MIT license of the core engine then you could fork it at that point. What they're doing right now is taking on a much larger maintainence burden than potentially necessary and fragmenting the ecosystem at the same time.
You're also at the same risk if you choose to use their fork.
Having to audit every commit in what was a FOSS project to make sure the parts I care about weren't relicensed out from under me sounds like a lot of work.
I use Emacs. If the FSF suddenly started pulling parts of it out, I would not sit there and hope that they didn't come after the bits I need. If someone forked it with strong assurances that I could keep using all of Emacs, I'd probably switch to that work. "Just fork the bits that get taken away" would not be an option I'd consider.
I'm not sure what reason they would have to wait. If they're not interested in changing the architecture and everything on redpanda's side stays MIT licensed, the only maintenance work will be to pull in the changes. Sounds completely risk-free. Sounds like insurance.
A mirror that strips out the branding does. And the way Redpanda is treating their trademark would make me extremely nervous about using software with their branding in it, so that alone is a good reason to start a soft fork.
we trippled the team. added 3 meaningful connectors for CDC and zero-trust as well multi-lang SDK and kept 99% of the connectors available for ppl to make money on... as well as the core engine remaining MIT. This is about them not wanting to depend on redpanda products which is ok, but the whole thing is hard to believe from a company that has no open source products. it's more like "hey, i don't like it."
I dunno ... when you see some guy from RedPanda on twitter throwing around petty "trademark compliance" [1] threats to memory-hole an entire project ... honestly, it would be malpratice _not_ to immediately fork everything.
The best part of this is "X" is such complete garbage that that post has literally zero context to someone unwilling to ever have an account on the tire fire that it is.
You also managed to be completely tone deaf to the way that developers feel about open source projects. A gradual branding transition can be swallowed, but what you chose to do instead is immediately force everyone to stop using the old name under threat of legal action. Adding new plugins that are proprietary can be tolerated, but if you're surprised that relicensing previously open source code prompted a fork you apparently weren't paying attention to the enormous kerfuffles surrounding recent relicenses by better-loved companies than yours.
That sounds like a good idea. I think it would be a better idea to split up the Connect repo into separate repos for the Benthos core framework as MIT and the plugins as a new RPL license instead of a dual license repo. The dual license is very messy.
UPDATE: just watched the blobstream and realized there is exactly a repo called “redpanda-data/benthos” with the MIT components. Nice!
> Some of the code in the core Redpanda Connect repo is still MIT-licensed, and we technically could have kept using some of it, but we couldn’t wait around to find out what the next change would be. We have to ensure that one of our most critical dependencies is being stewarded in a thoughtful and responsible manner. We also cannot, in good conscience, include any software dependencies containing mixed or muddled licensing that could be subject to change (again) at a moment's notice. Our customers deserve more stability and predictability than that.
TLDR: They don't trust Redpanda to not pull the rug again later.
I missed the live stream but did you mention if you'd contribute to the fork or no? can you still contribute to the red panda one if at all? The only thing I care about when choosing something is not if it's proprietary or open source maintained as a passion project it's if the project looks stable and will be viable to depend on for the life of whatever I am building. Hence my question.
This whole thing comes off as tone-deaf and deceptive even to me (who is all for COSS monetizing.) Warpstream was sponsoring Benthos, it sounds like they didn't get a great heads up of this happening, which makes the project owner sound self-serving. Then you renamed the repo and relicensed some connectors all in one go without giving anyone from the community a chance to opine or think about how this affects them.
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.)
You could keep the MIT license but keep changing the interfaces for plugins with which they compete to create friction in maintenance and drive to Redpanda proprietary.
As a freelance engineer who's a long time Benthos contributor and who volunteered a lot of community support for this project in the past several years, I don't think it makes sense to fork it and I'm perfectly happy with the current approach where the core engine (https://github.com/redpanda-data/benthos) is MIT licensed as @jeffail mentioned and 3rd party plugins can live in other people's repos and have various licenses, one example being https://github.com/redpanda-data/connect.
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.
incorrect. the intend is to have it be a project that is thriving, see the last 2 additional partnerships that landed as apach2 connectors: https://redpanda.com/blog/redpanda-connect w/ peerdb, and ockam.
As the founder and CEO - did you not think to stop and look at the market? For example what happened recently with Terraform/OpenTofu, Redis, etc?
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.
That's not the most constructive way of dealing with criticism.
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.
I think forking is reasonable in this case. It’s one thing to change the GitHub org for a project because you aquihired the team, but it is another thing entirely to change the name of the project to match your company name, implying that the project is simply one of your products. The latter clearly gives off “Redis Labs” vibes. ‘Fool me once…’ is a justified reaction.
Most critical to me seems to be the integration relicensing/de-open-sourcing (and the article seems generally to feel the same),
> 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?
It absolutely doesn't need a fork. The entire project is designed specifically to allow vendors and users to have their own ecosystem of plugins and they can all compile and integrate seamlessly. I'll be explaining live in 30 mins: https://www.youtube.com/watch?v=X8nVdUuWZ80
This seems to be the case. You have warpstream who is a former sponsor of Benthos and integrated their product DEEPLY now feeling left out when they talk about things happening in 12 hours and imagine what else could happen in more time; I'd imagine a purchase like this is months in the making. They wrote this blog post that reads like a scorned ex-lover and ends with we did it because you made us.
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.
As a hobbyist Benthos user (and an admirer of Benthos), I'm a bit nervous about the "buyout".
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.
The core is still MIT-licensed and I don't see a great reason why that would change. I've built many plugins for Benthos and Bloblang in the past and I've always been more inclined to use Benthos _as a library_. The Go package is great and the input/output/processor interface are easy to build against. I'm glad that nothing about my ability to do that is changing and I'll be using it again in the future. Benthos is a phenomenal project that is now being sustained by a commercial entity.
@richardartoul > Yesterday there were significant "commercial changes" to the OSS project Benthos, so today we're announcing Bento, the 100% MIT licensed fork of the project formerly known as Benthos.
@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.
>@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.
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...
From WarpStream’s (the forker’s) communications, I can’t tell if this is a hard fork or if they intend to pull changes and keep plugin compat. Perhaps they don’t yet know themselves, which would be nonideal but understandable under the circumstances. And I think that’s the only way we could really measure “trying not to fork” here, so saying that they had tried not to fork before eventually doing so sounds confused on their part.
On the other hand, I am saying all of that because I don’t think not forking at all is really an option in this situation. When the new maintainer is willing to relicense [EDIT: parts of] a piece of FOSS whose previous maintainer they acquired, when they are further trying to impose some weird Orwellian retcon on the name of said piece of FOSS and deleting all of its older resources, this seems to me like a degree of active hostility that wouldn’t be wise to tolerate, and the correct attitude would be “fool me twice, shame on me.” So a fork it is, now we’re just haggling over the hardness.
you may have not read the blog post i wrote. the engine remains MIT because we had customers that had embedded this in their app and it made sense to keep that. it is 100% about not having to call it "redpanda x" https://redpanda.com/blog/redpanda-connect
at the end of the day, there is plenty of ppl that are making money on this that is not us and that's cool too. we just need to retain the brand of the code we maintain. that's really the thing that matters.
> it is 100% about not having to call it "redpanda x"
It sounds frivolous, but these kinds of trademark shenanigans are a pretty big deal IMO. Mozilla's trademark policies already push the boundaries of what's acceptable in open source--people maintain forks like GNU IceCat just to get around them. Redpanda's forced rebranding goes a lot farther, and personally, it would make me think twice about using your stuff in anything I ship.
> we just need to retain the brand of the code we maintain. that's really the thing that matters.
This is... not really possible with most open source licenses? It's probably possible for you to ban me from using the name "Benthos", but I could almost certainly take your code and distribute it as "Frank's No-Name Blob Thingy" if I retained your copyright notices and license text. I mean that's what this fork is doing, after all.
let's call it what it is. warp never reached out. they do not want to have the name "redpanda" in their UI. that's all. They can* make money on 223 out of 225 connectors. More over the engine* remains MIT.
Not sure that you care, but you are doing an absolutely terrible job representing RP in nearly every comment I’ve seen you make on the topic. You need a coach I guess.
Let's call it what it is: Redpanda took a valuable OSS property, hard renamed it, and applied an arbitrary trademark restriction that did not exist the day before‡ and is not strictly controlled by the open source licence in question — in addition to relicensing part of the repository.
I don't have a dog in this fight. I have never used Benthos. But if someone started what Redpanda with a project that I use — commercially or otherwise — I would instantly fork it. I might not make a big announcement about it the way that Warp did, but I would absolutely be "keeping my powder dry" to see what other nonsense who did the first steps would pull.
You may not like what's happened, and Warp's incentives are certainly not pure, but they are reasonable considering what more than a few corporations have done, including Terraform, Elastic, and Mongo. Please stop pretending that you’re the good guys here.
‡ This is similar to Firefox's trademark restrictions resulting in Iceweasel, etc. There are some people who find Mozilla's restrictions applied to choosing different build settings to be excessive. Are you really surprised that people find your renaming and insta-trademark enforcement to be reminiscent of NewSpeak? Doubleplusungood.
For those who have trouble getting an X link to load:
> 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
“Trouble getting an X link to load” … There’s another project that had superb reliability and reputation. Then it got bought, access was restricted to certain parts, and it was renamed to X.
Because "X" is a completely useless tire fire if you don't log in (and I will never create an account) this post is 100% utterly and completely without context. Don't use X.
It feels pretty uncharitable for Redpanda to enforce their terms when they haven't done anything of value with it yet. They made a bold claim that you'll have to pay them to use these features, but you certainly don't as they're still available under MIT licensing.
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:
Yea - I get that argument but these days it's just hard to do infra as true FOSS with the hyperscalers and current cloud economics. There is a community license and and the code is visible. Not saying it's ideal but Redpanda is further into the open source world than WarpStream.
Not really? I'm not a stickler on the term "open source" but they're both proprietary at the end of the day. It's a weird nit to pick. Why even bring it up at all, unless you're desperate to defend Redpanda?
I can see the source code of Unreal Engine too. Does that make them "further into the open source world" than WarpStream too?
I don't have a horse in this particular race but WarpStream's blog post is a lot more charitable towards the project in question, and the open source world in general, than Redpanda's.
> You might be thinking, “Wait a minute, isn’t WarpStream just another corporation? Why should I spend my time contributing to their project if they can just take my contributions at any time and commercialize them?”. Bento is 100% MIT licensed and will stay that way forever.
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.
"No takebacks" is already inherent to the nature of all FOSS licenses. No one, not even a "supermajority quorum", can retroactively change the license to code they don't own the copyright to, and each contributor retains ownership of the copyright to whatever code they've written, individuall.
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.
The Linux kernel is already like that. The two requirements for it are (1) that the license is copyleft rather than permissive, and (2) that the project accepts significant external contributions without requiring a CLA that gives the upstream authors extra rights.
You do this by explicitly not having a CLA and by attributing the underlying copyright to the collective authors. Then even a supermajority is effectively unable to relicense.
This only really works if the contributions were made under a copyleft license like GPL. With MIT, it's perfectly allowed to rugpull like this so long as you bury the original copyright line/disclaimer/etc somewhere in your app's equivalent of chrome://credits.
No, with MIT, you are only releasing your subsequent modifications/derivative works under a new license. You can't retroactively change the license to anything that is already MIT.
This doesn’t help if almost all of the contributions come from a single corporation, and now come with a different license attached. As forks prove, license changes typically affect future contributions, not previous ones.
I'm really hoping this string of "open source project goes proprietary" news stories are helping people see the value of licenses like the GPL, which do prevent you from releasing future contributions under a different license unless you own the copyright to 100% of the original code.
Indeed: if remaining open is valued, people should be looking for licenses that prevent it, not ownership by a foundation or similar. That realistically means the GPL.
Unfortunately that cuts to the root cause of the problem, which is not valuing freedom as in speech, but instead only freedom as in beer (or, in the case of a lot of software, free as in mattress).
> We’re pretty sure this isn’t how copyrights, software licensing, and trademarks work (like, at all), but we also didn’t feel like arguing about it, or getting the lawyers involved.
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.
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