ok… this is is what your wrote…
if you meant…
then write that.
You have completley changed what you you were saying. I can’t divine that you would decide to change your answer.
My point still stands, you only care about yourself as you have now stated two different times. Thats inherently selfish, it makes sense that you and @Quantum agree.
Seems like your still not understanding my point of view, or what I’m saying (or both 
), but lets just agree to disagree, and just get on with using, or not using BW 
Redis’s backend is licensed under Redis Source Available License 2.0 (RSALv2) Agreement. Bitwarden backend is dual licensed under AGPL and Bitwarden License v1.0 whereas the latter is located under /bitwarden_license folder in source code.
Redis front-end libraries are licensed under MIT, while front-end on Bitwarden is dual licensed under GPLv3 and Bitwarden License v1.0 whereas the latter is located under /bitwarden_license folder in source code.
This is not the same. If it was the same, then it would be the same licenses with the same clauses. I find it disingenuous to lump together licenses solely based on being able to view the source code.
Licenses aside, the goal of enshittification is likely the same, but I’m thinking this will be a slow poison rather than a quick one.
This is my take. I’m cautious, but I’m sticking with it for the time being. If the copy-left aspect of the client or server side code are removed, then I’m off to Proton Pass without hesitation.
Thanks for the correction. I was talking more on the intent, hence the emphasis on “same situation” and not “same license”. The difference here is of course that BW is using more standard licenses for backend dual licensing (which when read in unison is very similar to the redis license) while redis is making a more twisted license. Based on your comparison redis clients seems to be actually more friendly to tivoization than BW clients.
Although I do apologies for the “exact same” comment, must have slipped in while writing.
As a final follow-up, see this commit on May 9, 2022 where they added the dual license capability.
Regardless, anyone who is a paying customer should contact the support and let them know you are considering switching because of this. Vote with your wallet, and let them know paying customers are unhappy with this slow movement away from FOSS. I doubt this will be a huge dent. Corpos listen to money, not philosophy.
Very sad. My consulting company is using passbolt internally and have had a good experience, so perhaps I will go with that for personal too.
What a massive disappointment. Gross.
Another FOSS project, proving that it’s not viable to earn enough money to sustain itself. Most users using FOSS software never donate/pays for the Project, Nor do they want ads in those softwares or might use adblockers to block ads on those softwares and when the software finally either shuts down or go proprietary, makes shocked pickachoo face. Some then even have audacity to harass developers online. If the product is really essential, they may still use any tool in their disposal to block the software from making money. I think it’s a high time where people in FOSS community should understand that money is required for regular development and maintainance of a software and support their favourite projects with monetary support . Yes, some people may start FOSS projects as hobby projects, unless those projects really have some pretty cool way of earning money, the project is not something to be relied on as it can be EOL anytime as most open source software comes with no warranty nor the developer owes anything to anyone when they have an open source software.
i understand this point but bitwarden already got vc funding 2 years back i guess and this case is not exactly like skiff , where they are selling of the foss products and closing the service. Also the CEO afaik is still the same.
I think the founder and CEO plays major role in how the company is run.
Agreed that there maybe new investors who may
have significant influence in what path bitwarden takes forward. (which it already has been following since 2 years) So all may not be lost.
1password a closed source app was already recommended by PG , so i don’t think open source is a mandatory criteria to fulfill as far as they are maintain the security standard and don’t track users.
I contacted support with my concerns and got this reply:
It seems like a packaging bug was misunderstood as something more, and the team plans to resolve it. Bitwarden remains committed to the open source licensing model in place for years, along with retaining a fully featured free version for individual users.
But a lot of people don’t understand this point. For them Free in FOSS means Free as in price. Also if you see most proprietary software are also free because they implement ads to earning. This has caused a massive shift where people expect a software to be free without giving anything back to developers.
To be fair, I think Bitwarden was already making some money. The Problem is they took 100million in VC funding, so they are forced to dramtically increase their profits.
Yeah, that’s why people should fund their favourite FOSS project more so that projects don’t have to beg from VCs which in long turn forces them to then change their entire structure, hence alienating old userbase.
I mean you are right, but at the same time, raising 100 million ? This seems like a receipt for disaster.
Nope. They just make it seem that way on the surface.
Sounds like plenty of money to be financially viable for a long time and make a competitive product that can succeed against entrenched competitors.
Profit isn’t evil.
We have made some adjustments to how the SDK code is organized and packaged to allow you to build and run the app with only GPL/OSI licenses included. The sdk-internal package references in the clients now come from a new sdk-internal repository, which follows the licensing model we have historically used for all of our clients (see LICENSE_FAQ.md for more info). The sdk-internal reference only uses GPL licenses at this time. If the reference were to include Bitwarden License code in the future, we will provide a way to produce multiple build variants of the client, similar to what we do with web vault client builds.
The original sdk repository will be renamed to sdk-secrets, and retains its existing Bitwarden SDK License structure for our Secrets Manager business products. The sdk-secrets repository and packages will no longer be referenced from the client apps, since that code is not used there.
This seems like a fair response - unless there is more discussion, I think the above response answers it
The issue for me isn’t resolved. So far BW has:
From the most end user perspective, maybe sure the issue is resolved. From my trust perspective it’s not. Ultimately my ideas of privacy are dependent on trust. But nothing to discuss I agree, just shady behaviour that should be highlighted for anyone going through the thread.
Stop it, they said it was a bug, move on, I’m still loyal to BW, it’s still open source, every company that respects privacy at some point has had communication problems, Proton, Tuta, Signal, Firefox, DDG, Brave, Orqanic Maps, all of them…
And what are you going to do, change every time, at the slightest error in communication or misinterpretation by the community?
These are the kinds of maneuverings/claims that Microsoft makes, not your usual open source companies.