from Hacker News

Bento: Open-source fork of the project formerly known as Benthos

by pauldix on 5/31/24, 5:26 PM with 68 comments

  • by jeffail on 5/31/24, 6:27 PM

    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

  • by mihaitodor on 5/31/24, 6:50 PM

    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.

  • by chambers on 5/31/24, 8:27 PM

    > Changed the name of the project from Benthos to “Redpanda Connect”, and prohibited anyone from using the term “Benthos.” https://x.com/emaxerrno/status/1796219957589786810

    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.

  • by ko_pivot on 5/31/24, 10:27 PM

    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.

  • by jauntywundrkind on 5/31/24, 6:14 PM

    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?

  • by NortySpock on 6/1/24, 2:31 AM

    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.

    [1] https://gwern.net/complement

  • by disintegrator on 5/31/24, 7:11 PM

    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.

  • by eatonphil on 5/31/24, 6:04 PM

    Alex, the CEO of Redpanda, responded.

    https://x.com/emaxerrno/status/1796593469743620444

  • by xyzzy_plugh on 6/1/24, 2:49 AM

    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:

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

  • by dangoldin on 6/1/24, 2:44 AM

    FWIW - Redpanda open sources their core product - https://github.com/redpanda-data/ while WarpStream keeps their core product proprietary - https://github.com/warpstreamlabs

  • by teeray on 6/1/24, 1:40 AM

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

  • by olgeni on 6/1/24, 4:00 PM

    The text "Licensed as a Redpanda Enterprise file under the Redpanda Community" appears in the two RCL-licensed connectors as listed on the web site:

    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

  • by petecooper on 5/31/24, 6:59 PM

  • by User23 on 6/1/24, 8:43 PM

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