[kstrauser]

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.

[klabb3]

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.

[Zambyte]

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 :(

[jeffail]

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.

[kstrauser]

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.

[pessimizer]

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.

[layer8]

Mirroring doesn’t constitute a fork.

[demosthanos]

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.

[agallego]

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."

[12_throw_away]

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.

[1] https://x.com/emaxerrno/status/1796219957589786810

[scblock]

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.

[demosthanos]

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.