All about open source! Feel free to ask questions, and share news, and interesting stuff!
Community icon from opensource.org, but we are not affiliated with them.
Apparently and according to Bitwardens post here, this is a "packaging bug" and will be resolved.
Update: Bitwarden posted to X this evening to reaffirm that it's a "packaging bug" and that "Bitwarden remains committed to the open source licensing model."
Let's hope this is not just the PR compartment trying to make this look good.
I think even if they do reverse course or it was a genuine mistake, it's easy to lose people's trust forever, ESPECIALLY when it comes to something sensitive like storing ALL of your passwords.
How would the community's reaction be if Bitwarden goes, "Look, we are moving more into the enterprise space, which means using proprietary software to service their needs. Our intention is to keep the enterprise and public versions sandboxed, but there is crossover, and we made a mistake."? I really don't care what they do in the enterprise space. Perhaps I'm an apologist, but seemingly more torn than most other posters.
Laughs in keepassxc
Dumb it.
Move to something else.
This is how fuckery starts.
We need a fully community run password manager with row-level server synchronisation between devices and shared vaults. Maybe a new client for the Bitwarden protocol with Vaultwarden or something new. E.g. 1password's secret key as a second factor is, imho, their best feature. It pretty much eliminates the possibility of the vault being decrypted due to a weak master password.
ITT: A lot of conspiracy theories without much (any?) evidence. Let's see if they resolve the dependency issue before wet get our pitchforks, shall we?
I don't know what the heck you're talking about.
I see overwhelming evidence that they have intentionally made parts of the clients' code proprietary. You can check the client code yourself (for now anyways) and convince yourself of the fact that the bw SDK code is in indeed integrated into the bitwarden clients' code base.
This is the license text of the sdk-internal used in 2024.10.1 (0.1.3): https://github.com/bitwarden/sdk/blob/16a8496bfb62d78c9692a44515f63e73248e7aab/LICENSE
You can read that license text to convince yourself of the fact that it is absolutely proprietary.
Here is also the CTO and founder of Bitwarden admitting that they have done it and are also attempting to subvert the GPL in using sdk-internal:
https://github.com/bitwarden/clients/issues/11611#issuecomment-2424865225
Hi @brjsp, Thanks for sharing your concerns here. We have been progressing use of our SDK in more use cases for our clients. However, our goal is to make sure that the SDK is used in a way that maintains GPL compatibility.
- the SDK and the client are two separate programs
- code for each program is in separate repositories
- the fact that the two programs communicate using standard protocols does not mean they are one program for purposes of GPLv3
Being able to build the app as you are trying to do here is an issue we plan to resolve and is merely a bug.
(Emphasis mine.)
The fluff about the ability to even build the app is secondary, the primary issue is that the Bitwarden clients are no longer free software. That fact is irrefutable.
There's a lot of drama in that Issue, and then, at the very end:
Thanks for sharing your concerns here. We have been progressing use of our SDK in more use cases for our clients. However, our goal is to make sure that the SDK is used in a way that maintains GPL compatibility.
the SDK and the client are two separate programs
code for each program is in separate repositories
the fact that the two programs communicate using standard protocols does not mean they are one program for purposes of GPLv3
Being able to build the app as you are trying to do here is an issue we plan to resolve and is merely a bug.
Um can someone translate what this means?
They claim the SDK and Bitwarden are completely separate, so Bitwarden is still open source.
The fact that the current version of Bitwarden doesn't work at all without the SDK is just a bug, which will be fixed Soon™
Also important to note is that they are creating the same license problems in other places.
They broke f-droid builds 3 months ago and try to navigate users to their own repo now. Their own repo ofc not applying foss requirements, because the android app is no longer foss as of 3 months ago. Now the f-droid version is slowly going out of date, which creates a nice security risk for no reason other than their greed.
Apparently they also closed-sourced their "convenient" npm Bitwarden module 2 months ago, using some hard to follow reference to a license file. Previously it was marked GPL3.
Iirc, once reported, the project has 30 days to remedy or they are in violation of the license. They can't even release a new version with a different license since this version is out under the GPL.
They're trying to argue legal technicalities because acknowledging that they're trying to reduce compatibility with servers like vaultwarden would be bad PR.
Per their new license, anyone that uses their SDK to build a client cannot say, "this is for Bitwarden and compatible servers like vaultwarden". They cannot support those other servers, per their license. Anyone that gets suckered into using their SDK now becomes a force against alternative implementations.
Fuck. Is it difficult to export my data to something like Keypass? Very disappointed to hear this.
Bitwarden has an export functionality. Export to JSON, import in Keepass, done.
There's KeePassXC if you want Linux support (keepass2 file is compat with XC variant).
Thank you! It seems this whole thing was a misunderstanding however. It was an error on Bitwarden's part that they intend to correct. I may still switch to kepassxc later on, mostly to save the money.
Does anyone have experience with keyguard? From a cursory glance, this + vaultwarden seems like a good alternative...
I just tried it out and I'm amazed. It looks and feels just like 1Password, my absolute favorite password manager (before I switched to Bitwarden, because 1Password is proprietary and pretty expensive)
I definitely recommend it
If this is not resolved I will likely switch to another service. Free software compatibility was the main reason I paid for bitwarden over its competitors.
Nobody here talks about keepassxc ? I've been using it for almost a decade, it can be used with sync tools to be shared, I've managed to have db keepass file opened on several computers and it did work well. Gplv3 here https://keepassxc.org/
Keepass isn't really in the same category of product as Bitwarden. The interesting part of bitwarden is that it's ran as a service.
Bitwarden can't be compared to KeePassXC. Bitwarden is fundamentally built around a sync server, whereas KeePass is meant to exclusively operate locally. These are two very different fundamental concepts for, you know, how to actually store and access your passwords.
Ever since BitWarden got mired in capitalism, I've been dreading that something like this would happen.
Damn, I just switched from Bitwarden to KeepPassXC.
Clearly just in time. Lol.
What mobile solution are you using in this scenario?
Thanks for sharing your concerns here. We have been progressing use of our SDK in more use cases for our clients. However, our goal is to make sure that the SDK is used in a way that maintains GPL compatibility.
- the SDK and the client are two separate programs
- code for each program is in separate repositories
- the fact that the two programs communicate using standard protocols does not mean they are one program for purposes of GPLv3
Being able to build the app as you are trying to do here is an issue we plan to resolve and is merely a bug.
I.e. "fuck you and your foss"
A few questions out of ignorance. How different is this to gitlab's open core model? Is this a permanent change? Is the involvement of investors the root of this? Are we overreacting as it doesn't meet our strict definition of foss?
How different is this to gitlab’s open core model?
That's a really good question that I don't immediately have a satisfying answer to.
There are some differences I can point out though:
Is this a permanent change?
It'd be quite trivial for them to do in technical terms: Either license the SDK as GPL or stop using it in the clients.
I don't see a reason for them to roll it back though. This was decided long ago and they explicitly decided to stray away from the status quo and make it closed source.
The only thing I could see making them revert this would be public pressure. If they lose a sufficient amount of subscribers over this, that might make them reconsider. Honestly though by that time, the cat's out of the bag and all the public goodwill and trust is gone.
It's honestly a bafflingly bad decision from even just a business perspective. I predict they'll lose at least 20% but likely 30-50% of their subscribers to this.
Is the involvement of investors the root of this?
I find that likely. If it stinks, it's usually something stinky's fault.
Are we overreacting as it doesn’t meet our strict definition of foss?
They are attempting to subvert one of the FOSS licenses held in the highest regard. You cannot really be much more anti than this.
An "honest" switch to completely proprietary licenses with a public announcement months prior would have been easier to accept.