Oh, for fuck’s sake. Can we have a decent password manager that isn’t tied to a browser or company? I pay for Bitwarden. I’m not being cheap. But open source is more secure. We can look at the code ourselves if there’s a concern.
It is a license problem. The license condition of the SDK which is required to build the client app change to limit the usage of it. The new license states that you can only use the Bitwarden SDK for Bitwarden. It is against the Freedoom-0 of the Free Software Foundation.
The limitation of English language is that it is hard to differentiate between Free (as in Free bear) and Free (as in Freedoom). Also open source which could mean complaining with FOSS and that source is available. This been unfortunately have been abused before.
From the article, it’s a packaging bug, not a change in direction.
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.”
Here is the code in question. Basically, it’s a source-available, but not FOSS internal SDK, with the following language:
The password manager SDK is not intended for public use and is not supported by Bitwarden at this stage. It is solely intended to centralize the business logic and to provide a single source of truth for the internal applications. As the SDK evolves into a more stable and feature complete state we will re-evaluate the possibility of publishing stable bindings for the public. The password manager interface is unstable and will change without warning.
So I think the “bug” here is in not linking the original repo in the NPM package, and there’s a decent chance that this internal SDK will become FOSS in the future once it stabilizes. That said, it’s currently not FOSS, but it’s too early IMO to determine whether Bitwarden is moving in a non-FOSS direction, or if they’re just trying to keep things simple while they do some heavy refactoring to remove redundancy across apps.
Given their past, I’m willing to give them the benefit of the doubt, but I’ll be making sure I have regular backups in case things change.
This need not be the case, though! There’s an open source client on Android called Keyguard. I don’t think the desktop app was at all useful anyway. You can just log into your Vaultwarden through any browser. The desktop app is pointless.
And the whole conversation is about a bug, not a change in direction…
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.”
“You may not use this SDK to develop applications for use with software other than Bitwarden (including non-compatible implementations of Bitwarden) or to develop another SDK.”
Oh, for fuck’s sake. Can we have a decent password manager that isn’t tied to a browser or company? I pay for Bitwarden. I’m not being cheap. But open source is more secure. We can look at the code ourselves if there’s a concern.
Keepass: Am I a joke to you?
Love Keepass. Love that I can sync it however I want. Love that there are multiple open source client options across several operating systems.
Android syncthing announced they’re stopping development this year. Open source got fucked double today
terrible day. There is a fork called syncthing-fork that is under current development. I hope both projects merge.
They have confirmed it was a packaging bug and will be resolved.
Nothing in the article or in the Bitwarden repo suggests that it’s moving away from open source
It is a license problem. The license condition of the SDK which is required to build the client app change to limit the usage of it. The new license states that you can only use the Bitwarden SDK for Bitwarden. It is against the Freedoom-0 of the Free Software Foundation. The limitation of English language is that it is hard to differentiate between Free (as in Free bear) and Free (as in Freedoom). Also open source which could mean complaining with FOSS and that source is available. This been unfortunately have been abused before.
From the article, it’s a packaging bug, not a change in direction.
I was referring to this which started it all.
Here is the code in question. Basically, it’s a source-available, but not FOSS internal SDK, with the following language:
So I think the “bug” here is in not linking the original repo in the NPM package, and there’s a decent chance that this internal SDK will become FOSS in the future once it stabilizes. That said, it’s currently not FOSS, but it’s too early IMO to determine whether Bitwarden is moving in a non-FOSS direction, or if they’re just trying to keep things simple while they do some heavy refactoring to remove redundancy across apps.
Given their past, I’m willing to give them the benefit of the doubt, but I’ll be making sure I have regular backups in case things change.
Its called Keepass. You are welcome
Keepassxc? Vaultwarden?
Isn’t Vaultwarden used with non-free Bitwarden clients?
This need not be the case, though! There’s an open source client on Android called Keyguard. I don’t think the desktop app was at all useful anyway. You can just log into your Vaultwarden through any browser. The desktop app is pointless.
Keyguard isn’t open source. Have a look at their license. It just says “All rights reserved”.
The clients are free.
They now require a non-free Bitwarden SDK component. That’s what this whole conversation is about.
And the whole conversation is about a bug, not a change in direction…
Only the desktop client. And the response is that not being able to compile sans SDK is an issue they will resolve.
I still think this is bad directionally, but we need to see what happens.
Could you ELI5 please?
“You may not use this SDK to develop applications for use with software other than Bitwarden (including non-compatible implementations of Bitwarden) or to develop another SDK.”
This is a condition when using their SDK. This is not considered a free (as in freedom) component because it violates freedom 0: https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms