405

Bitwarden Desktop version 2024.10.0 is no longer free software (github.com)

submitted 20 hours ago by pnutzh4x0r@lemmy.ndlug.org to c/opensource@lemmy.ml

94 comments fedilink hide all child comments

Pull request #10974 introduces the @bitwarden/sdk-internal dependency which is needed to build the desktop client. The dependency contains a licence statement which contains the following clause:

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 violates freedom 0.

It is not possible to build desktop-v2024.10.0 (or, likely, current master) without removing this dependency.

top 50 comments

sorted by: hot top controversial new old

[-] daggermoon@lemmy.world 6 points 3 hours ago

Fuck. Is it difficult to export my data to something like Keypass? Very disappointed to hear this.

[-] smiletolerantly@awful.systems 12 points 5 hours ago

Does anyone have experience with keyguard? From a cursory glance, this + vaultwarden seems like a good alternative...

[-] bilb@lem.monster 6 points 5 hours ago

I have some! I use a self hosted vaultwarden and just two days ago I saw and installed KeyGuard out of curiosity. So far, I can say KeyGuard is a nicer looking and feeling app and... it works. So as long as their intentions are pure, you can use "bitwarden" without using any of their software or infrastructure.

[-] smiletolerantly@awful.systems 2 points 5 hours ago* (last edited 5 hours ago)

Just tried it, and it seems you can't edit or add items without a premium subscription??

Or am I missing something?

Edit: Apparently only when installing via the Play Store. Very weird decision.

[-] bilb@lem.monster 4 points 5 hours ago* (last edited 5 hours ago)

Ah, yeah, I installed it from their github with obtainium. I think open source/libre app that charges people to install with the play store is a model a few others have tried as well.

[-] smiletolerantly@awful.systems 2 points 5 hours ago

I don't think it's unreasonable to want to be paid, but a mandatory subscription when using the most common install method does irk me the wrong way

[-] bilb@lem.monster 2 points 4 hours ago

I haven't looked into it at all, but that just seems so strange. Who would pay that when the original Bitwarden app is still there for free? Most people who would even know about KeyGuard would know how to install it from somewhere else. Is it essentially a donation?

[-] smiletolerantly@awful.systems 3 points 2 hours ago

It would be if it's a one-time payment, but it's a yearly subscription, and not a cheap one!

[-] qaz@lemmy.world 1 points 4 hours ago* (last edited 4 hours ago)

License

The source code is available for personal use only.

That doesn't really seem like an improvement, although do they say they're planning on releasing it under the FSL.

[-] smiletolerantly@awful.systems 1 points 2 hours ago

Ah damn it -.-

Too bad, the app is really nice to use :/

[-] fireshell@lemmy.ml 2 points 4 hours ago* (last edited 4 hours ago)

pass is enough (+ xdotool + rofi + pass-menu). Synchronization via git or Syncthing.

[-] tetris11@lemmy.ml 1 points 10 minutes ago

How does this play with mobile?

[-] guillem@aussie.zone 1 points 1 hour ago

I'm familiar with pass and familiar-ish with rofi. What do the other two do?

[-] fireshell@lemmy.ml 1 points 29 minutes ago* (last edited 9 minutes ago)

A small script for entering passwords into various windows via rofi, I take passwords from pass.

Example script:

#!/bin/bash
# Sample file rofi_pass.sh
passwords=$(find /home/fireshell/.password-store/ -type f -name *.gpg)
selected_pass=$(echo -e "$passwords" | awk -F "/" '{printf "%s > %s\n", $5, $6}' | rofi -dmenu -p Pass)
item=$(echo "$selected_pass" | awk '{printf "%s/%s", $1, $3}' | sed 's/\.gpg//g')
data=$(pass show $item)
pass=$(echo -e "$data" | head -n1)
login=$(echo -e "$data" | grep -e "^login: " | sed 's/^login: //g')
xdotool type "$login"
xdotool key Tab
xdotool type "$pass"

In awesome wm I bound a key that calls it like this:

awful.key({ modkey}, "p", function () awful.spawn.with_shell("/home/fireshell/Scripts/rofi_pass.sh") end    ,
{description = "rofi pass", group = "launcher"}),

I turn on the computer, press the key combination and the script works, or I run this script from the terminal (~/Scripts/rofi_pass.sh), select the password - it works (if necessary, pinentry is called to enter the main password), after that I press the key combination, select the desired entry

[-] Lemmchen@feddit.org 23 points 10 hours ago* (last edited 3 minutes ago)

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?

[-] Atemu@lemmy.ml 10 points 6 hours ago* (last edited 6 hours ago)

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.

[-] asap@lemmy.world 3 points 5 hours ago* (last edited 4 hours ago)

That would be an issue if they were not open source. Them making their own SDK proprietary is not a pitchfork issue.

Open source !== Non-proprietary

I would go as far as to say that Bitwarden's main competitive advantage and differentiation is that it's open source. They would be insane to change that.

[-] cmhe@lemmy.world 1 points 2 hours ago

Well, then it would be nice to hear from them an explanation on why they decided to violate the GPLv3 on their client, by coupling it with proprietary code in a way that disallows building and/or usage without that proprietary component.

They would be insane to change that.

Yes. And i hope that they recover from it soon.

[-] asap@lemmy.world 3 points 2 hours ago* (last edited 2 hours ago)

Well, then it would be nice to hear from them an explanation on why they decided to violate the GPLv3

Lucky for you, they provided that explanation:

This is a bug/mistake.
Our goal is to make sure that the SDK is used in a way that maintains GPL compatibility.
We will fix this.

[-] cmhe@lemmy.world 1 points 1 hour ago

Ok, lets take it step by step:

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

I think they meant executable here, but that also doesn't matter. If both programs can only be used together and not separate, and one is under GPLv3, then the other needs to be under GPLv3 too.

code for each program is in separate repositories

How the code is structured doesn't matter, it is about how it is consumed by the end-user, there both programs are delivered together and work together.

the fact that the two programs communicate using standard protocols does not mean they are one program for purposes of GPLv3

The way those two programs communicate together, doesn't matter, they only work together and not separate from each other. Both need to be under 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.

Not being able to build a GPLv3 licenses program without a proprietary one, is a build dependency. GPLv3 enforces you to be able to reproduce the code and I am pretty sure that the build tools and dependencies need to be under a GPLv3 compatible license as well.

But all of that still doesn't explain what their goal of introducing the proprietary SDK is. What function will it have in the future? Will open source part be completely independent or not? What features will depend on the close-source part, and which do not? Have they thought about any ethical concerns, that many contributors contributed to their software because it under a GPL license? How are they planning on dealing with the loss of trust, in a project where trust is very important? etc.

[-] asap@lemmy.world 1 points 1 hour ago

What features will depend on the close-source part, and which do not?

There are definitely some terminology issues here.

The SDK is not closed source, you can find the source here: https://github.com/bitwarden/sdk

It might not be GPL open-source, but it is not closed either.

Other than that, I agree with your points. I don't agree with the kneejerk hysteria from many of the comments - it's one of the worst things about FOSS is how quick people are to anger (I am not referring to you here).

But all of that still doesn’t explain what their goal of introducing the proprietary SDK is.

Let's wait and see before we get out the pitchforks.

[-] cmhe@lemmy.world 1 points 1 hour ago

The SDK is not closed source, you can find the source here: https://github.com/bitwarden/sdk

It might not be GPL open-source, but it is not closed either.

Sure. To me "source available" is still closed-source, since looking might give companies an attack surface for you to have violated their copyright in the future. Happened with IBM in the past: https://books.google.de/books?id=gy4EAAAAMBAJ&lpg=PA15&pg=PA15&redir_esc=y#v=onepage&q&f=false

Let’s wait and see before we get out the pitchforks.

Sure. Bitwarden doesn't owe us anything, but it is still sad to see this decision and better clarification and explanation could have alleviated the breaking of the trust here.