Comment by jeffail | Hacker News Reader

Comment by jeffail | Hacker News Reader

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.

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.

Mirroring doesn’t constitute a fork.

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.

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

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.

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

Are you (and redpanda) committing to not relicensing any other benthos components in the future?

If you are committing to that then you should say so.

Hashicorp commited to keeping the MPL, then switched licenses anyway. Such a commitment would need to be contractual for me to believe it.

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.

Reply on news.ycombinator.com