[HN Gopher] Bento: Open-source fork of the project formerly know...
___________________________________________________________________
Bento: Open-source fork of the project formerly known as Benthos
Author : pauldix
Score : 124 points
Date : 2024-05-31 17:26 UTC (5 hours ago)
(HTM) web link (www.warpstream.com)
(TXT) w3m dump (www.warpstream.com)
| eatonphil wrote:
| Alex, the CEO of Redpanda, responded.
|
| https://x.com/emaxerrno/status/1796593469743620444
| mananaysiempre wrote:
| @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.
| rdtsc wrote:
| >@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...
| mananaysiempre wrote:
| 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.
| agallego wrote:
| 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.
| agallego wrote:
| 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.
| halostatue wrote:
| 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.
| kstrauser wrote:
| 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
| cedws wrote:
| Might be better to make some kind of official statement instead
| of posting on Xitter where anonymous readers can't read past
| the top level Xit.
| jauntywundrkind wrote:
| 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?
| jeffail wrote:
| 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
| cbsmith wrote:
| Yeah, trying to decide if this is a fight between two companies
| or a real thing.
| jeffail wrote:
| 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
| kstrauser wrote:
| 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.
| jeffail wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Mirroring doesn't constitute a fork.
| agallego wrote:
| 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."
| klabb3 wrote:
| 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 wrote:
| 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 :(
| chuckadams wrote:
| > 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.
| pokstad wrote:
| 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!
| psanford wrote:
| 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.
| gigatexal wrote:
| 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.
| mihaitodor wrote:
| 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.
| petecooper wrote:
| >Bento
|
| A trip down memory lane:
|
| https://en.wikipedia.org/wiki/Bento_(database)
| disintegrator wrote:
| 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.
| kstrauser wrote:
| I'm sure lots of users of the affected plugins saw no reason
| why those would change, either.
|
| I think the new owners have established a precedent that
| they're will make to make such drastic changes.
| chambers wrote:
| > 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.
| agallego wrote:
| 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.
| ko_pivot wrote:
| 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.
___________________________________________________________________
(page generated 2024-05-31 23:00 UTC)