Bento: Open-source fork of the project formerly known as Benthos(warpstream.com) |
Bento: Open-source fork of the project formerly known as Benthos(warpstream.com) |
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.
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.
@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
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.
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).
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.
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 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.
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.
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.