385

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

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

84 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.

(page 2) 36 comments

sorted by: hot top controversial new old

[-] andrew_s@piefed.social 103 points 18 hours ago* (last edited 18 hours ago)

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.

[-] someguy3@lemmy.world 47 points 18 hours ago

Um can someone translate what this means?

[-] TheOubliette@lemmy.ml 43 points 15 hours ago

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.

[-] superkret@feddit.org 85 points 17 hours ago

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™

[-] umbrella@lemmy.ml 11 points 12 hours ago

further translating it: they are closing it down but trying to make it look like they arent

[-] CosmicTurtle0@lemmy.dbzer0.com 16 points 14 hours ago

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.

[-] GissaMittJobb@lemmy.ml 12 points 11 hours ago

Given that they own all of the source code (CLA is required to contribute), they can just stop offering the code under GPL, unless they happen to have any GPL dependencies not under their control, in which case this would not be viable.

[-] CosmicTurtle0@lemmy.dbzer0.com 7 points 10 hours ago

Switching licenses to future versions doesn't invalidate previous versions released under GPL.

I'm not a lawyer but I deal with OSS licenses for work and I don't know if there's ever been a case like this, that I can think of anyway.

Their previous versions, still being under the GPL, would require them to release a change to make it usable on desktops. Again, I'm not a lawyer here but there is a lot of case law behind the GPL and I think the user who made the issue could take them to court to force them to make the change if they don't respond in 30 days.

load more comments (5 replies)

load more comments (1 replies)

[-] Natanael@slrpnk.net 21 points 17 hours ago

The main program is open, but the development tools are not

[-] umami_wasbi@lemmy.ml 21 points 18 hours ago

plan to resolve

timeline unknown, maybe 2124

[-] unbroken2030@lemmy.world -2 points 17 hours ago

There is always a very vocal minority itching to cause as much drama as possible. It's very discouraging to see in general. I agree with and want more FOSS, but I'm not sure I'd ever consider making it myself; it's not worth extra stress personally.

[-] KLISHDFSDF@lemmy.ml 9 points 12 hours ago

Looks like I might be moving to Proton Pass after all! I'll give them some time to see what they do about this, but will happily give my money to someone else and migrate friends/family as well.

load more comments (2 replies)

[-] umbrella@lemmy.ml 7 points 12 hours ago* (last edited 12 hours ago)

i was about to replace my glorified encrypted text file for a password manager. guess relying on 3rd parties in a late-stage capitalist world is not a viable alternative.

ill stay with my encrypted text file until they privatize encryption. by then ill probably be carving my passwords out on stone. or burning down the servers of these fucking pigs trying to make us identify ourselves for everything on the internet now.

[-] EveryMuffinIsNowEncrypted@lemmy.blahaj.zone 10 points 11 hours ago

KeePassXC is pretty amazing. :)

[-] umbrella@lemmy.ml 2 points 11 hours ago

can u selfhost it?

[-] EveryMuffinIsNowEncrypted@lemmy.blahaj.zone 8 points 10 hours ago* (last edited 10 hours ago)

I would assume so. According to the page Documentation and FAQ,

Why is there no cloud synchronization feature built into KeePassXC?

Cloud synchronization with Dropbox, Google Drive, OneDrive, ownCloud, Nextcloud etc. can be easily accomplished by simply storing your KeePassXC database inside your shared cloud folder and letting your synchronization service of choice do the rest. We prefer this approach, because it is simple, not tied to a specific cloud provider and keeps the complexity of our code low.

load more comments (1 replies)

[-] SteleTrovilo@beehaw.org 44 points 18 hours ago

Ever since BitWarden got mired in capitalism, I've been dreading that something like this would happen.

[-] fl42v@lemmy.ml 41 points 18 hours ago

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"

[-] zante@lemmy.wtf 19 points 18 hours ago

Pretty much the opposite

[-] fl42v@lemmy.ml 25 points 17 hours ago

I doubt it. What'll probably happen is them moving more and more of the logic into the SDK (or adding the back-end of new features there), and leaving the original app to be more or less an agpl-licensed ui, while the actual logic becomes source-available. Soo, somewhat red-hat-esque vibes: no-no, we don't violate no stupid licenses, we just completely go against their spirit.

[-] refalo@programming.dev 7 points 17 hours ago

go against their spirit

I think this is more of a failure of the license itself. It's not a good look to allow something explicitly and then go "no not like that!"

[-] fl42v@lemmy.ml 9 points 16 hours ago* (last edited 16 hours ago)

I'm not sure you can classify this as a failure, as explicitly prohibiting interfacing with non-agpl stuff would greatly limit the amount of stuff you can license under it, perhaps up to the point of making it generally unusable. As for "not like that"... Well, yeah. But you can't deny it's misleading, right? Free software kinda implies you can modify it whatever you want, and if it's a free ui relying on a source-available middleware... Turns out, not so much.

Although, a posdible solution would be require explicitly mentioning if you're basically a front-end for something; but I'm not sure if it can be legally distinguished from the rest of use-cases.

[-] DoucheBagMcSwag@lemmy.dbzer0.com 4 points 12 hours ago

Uh oh. Android user here. Time to jump ship? If so...proton??

load more comments (1 replies)

[-] nadiaraven@lemmy.world 4 points 12 hours ago

Okay, we'll I've been using vaultwarden. When should I switch to something new, and what's a good alternative?

[-] nichtburningturtle@feddit.org 11 points 17 hours ago

Does this affect valtwarden?

[-] TheOubliette@lemmy.ml 37 points 15 hours ago

Yes because it is about, ultimately, making the major clients incompatible with vaultwarden on both a legal and technical level.

A likely outcome if they don't reverse course is a split where FOSS Nerfs fork the clients and have to maintain their own versions. That's the outcome Bitwarden wants. This reeks of a bazinga, "how dare they benefit from our work and take our users", which is hilarious for a FOSS ecosystem that almost universally benefits corporations with free labor.

[-] subtext@lemmy.world 20 points 17 hours ago

Vaultwarden is only the server, no? So any clients that you use to access Vaultwarden are built and maintained by 8bit solutions a.k.a. Bitwarden, including the desktop client that is the subject of this post.

load more comments