- cross-posted to:
- linux@lemmy.ml
- cross-posted to:
- linux@lemmy.ml
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.
You must log in or register to comment.
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”
Pretty much the opposite
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.
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!”
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.
Does this affect valtwarden?
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.
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.
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.
What does this change for you?
Seems to change nothing for all my devices which is a cheap offering at $10/year.
The direction that the company is taking. Clearly that Bitwarden feels like other open source projects are diverting revenue from them.
That’s a small step towards enshittification. They close this part of the software, then another part until slowly it is closed source.
We’ve seen this move over and over.
Stopping your business with Bitwarden over that issue sends a message that many customers don’t find this acceptable. If enough people stop using their service, they have a chance to backtrack. But even then, if they’ve done it once, they’ll try it again.
Your current price is 10$/year now. But the moment a company tries to cull any open source of their project is the moment they try to cash it in.
That’s a small step towards enshittification
Going away from opensource model that you built your business over is a pretty big step.
And incredibly stupid as well.
How will anyone know what they add to the code now? That’s the problem, and with our fucking passwords no less. They can fuck right off. In my environment alone they will be loosing upwards of 3,500 dollars yearly, 700,000 if I can convince my boss to dump them for the company as well.
In my environment alone they will be loosing upwards of 3,500 dollars yearly, 700,000 if I can convince my boss to dump them for the company as well.
And move to what?
Anything, even Proton. The point is making a statement. If you start as OSS, you can fuck right off when you decide to come back sideways locking code down.
I will change for sure, as well. Let’s see.
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.
KeePassXC is pretty amazing. :)
can u selfhost it?
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.
It’s basically your encrypted file, you are to handle synchronisation yourself.
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/
No Android app though?
No excuse to not look into it now. Hopefully it uses Android autofill.
It does support autofill
Ty, exploring alternative tools. I really don’t like last pass due to their lax data security and 1 Password for the same reason.
Bitwarden still earns my $10/year.
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.
Store your database in a nextcloud instance and it’s that too
Nope. Since the entire database is contained in a single file, it can’t sync multiple edits properly, leading to sync conflicts. Because KeePass was built around local database files, whereas Bitwarden uses actual synced databases, where individual updates can be uploaded, instead of causing conflicts or overwriting the entire db.
Conflicts haven’t been an issue for years, all modern iterations of KeePass (XC, kp2a, DX) support automatically merging in the latest before saving.
I’ve been using it for years this way across several devices, it’s incredibly solid
Do you sync it across your devices using Syncthing? That’s what I’m thinking of doing.
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.
I just switched over. Honestly, I like it even more than Bitwarden. Then again, I don’t sync my stuff between devices because I’m old I guess. Lol. It makes it easier to switch because I don’t have to deal with stuff like Syncthing.
Uh oh. Android user here. Time to jump ship? If so…proton??
As with all of their services, the back-end is closed-source.
For the purposes of user freedom, it’s not that critical as the back-end merely facilitates the storage and synchronisation of encrypted data. This is different from the bitwarden case where they’re now including freedom disrespecting code into the most critical part of their software: the clients which handle the unencrypted data.
Fact of the matter remains however that Proton Pass restricts your freedom by not allowing you to self-host it.If you are fine with not being able to self-host, I’d say it’s a good option though. Doubly so if you are already a customer of their other services.
Proton has demonstrated time and time again to act for the benefit of its users in the past decade and I see no incentive for them to stop doing so. I’d estimate a low risk of enshittification for Proton which is high praise for a company of their size.
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.
I know little about Proton Pass, but how confident are you they don’t also used a proprietary SDK with their open source apps?
Proton pass client doesn’t currently use a proprietary SDK, but they also haven’t made the same blunder as Bitwarden, which they’ve since fixed, but still not a good look.
On another note - I did export/import all my passwords into proton pass and WOW the speed and UX feels so much better. I’m still sticking with Bitwarden as they’ve been really good so far, but there’s a real good alternative should they ever “turn evil”.
Damn, I just switched from Bitwarden to KeepPassXC.
Clearly just in time. Lol.
What mobile solution are you using in this scenario?
I’ll be there in a week or 2 bud. Fuck these companies baiting and then enshitifying it all.
Dumb it.
Move to something else.
This is how fuckery starts.
pass is enough (+ xdotool + rofi + pass-menu). Synchronization via git or Syncthing.
I’m familiar with pass and familiar-ish with rofi. What do the other two do?
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 wmI 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 entrypassmenu: extremely useful and wonderful dmenu script.
I was copying and pasteing from pass but that looks much cooler, thanks!
How does this play with mobile?
There’s an Android app, but it’s not being developed any more https://github.com/android-password-store/Android-Password-Store
There’s an iOS app as well https://mssun.github.io/passforios/
They have a list with all the clients and other tools on their website
https://www.passwordstore.org/#otherbesides everything else, the end of support for syncthing-android, yes, that’s a real blow to the gut.
as another option this KeePassXC(PC)+radicale+DavX5 The same for KeepassDX
Radicale+DavX5 is for calendars and contacts, no? How does this work for passwords
for passwords no way, as you noted it is for calendars and contacts
Integration with Android
The GnuPG implementation for Android is called OpenKeychain. To configure it, just go to the “key management” menu and import the previously created secret key. The only drawback of OpenKeychain for me personally is that there is no fingerprint unlocking.
The pass implementation for Android is called android-password-store, or simply APS.
Install and launch APS. Before synchronizing the password store, go to the “Settings” menu. There we will need the following items:
-
Git server settings. The resulting URL should be the same as that specified on the repository page on github. Authorization type -OpenKeychain. -
Git utils. In this section, specify the username and email from the gpg key. -
OpenPGP provider. SelectOpenKeychain. -
Autofill.
Now you can clone. Select “clone from server” on the main screen, specify the desired location of the repository, check the git settings.
Of course, pass is not that easy to set up. However, this price buys confidence that the tools we use will not one day be declared obsolete, will not change their data format, and will not be left without support.
-
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).
Okay, we’ll I’ve been using vaultwarden. When should I switch to something new, and what’s a good alternative?
I just exported my data from BitWarden and imported into ProtonPass. Was pretty easy. Hate the color palette of the app and browser extension though, lol.
I can’t imagine that’s any more free than bitwarden?
GPL’d clients. Everything is encrypted/decrypted on the client before sending/receiving to/from the server. I may later switch to a self-hosted solution, but don’t want to set one up right now (was using BitWarden’s cloud before).
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.
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:
- Gitlab has demonstrated its commitment to keep the core of their product, though limited in features, free and open source. As of now, BW’s clients cannot even be compiled without the proprietary SDK anymore.
- Gitlab was always a permissive license (MIT) and never attempted to subvert its original license terms
- Gitlab-EE’s “closed” core is actually quite open (go read the source code) but still squarely in the proprietary camp because it requires you to have a valid subscription to exercise your freedoms.
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.
Gitlab has demonstrated its commitment to keep the core of their product, though limited in features, free and open source. As of now, BW’s clients cannot even be compiled without the proprietary SDK anymore.
None of that makes Bitwarden not open source. Not only that, they specifically state this is a bug which will be addressed.
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 stop that.
None of that makes Bitwarden not open source.
Yes, it does, because it violates its own license GPLv3 by having proprietary build-/runtime dependencies.
If it was under a different, maybe more permissive, open source license, then maybe it would still be open source, but as of right now i likely breaks its own license terms.
Not only that, they specifically state this is a bug which will be addressed.
From what they state, they think that because executables that share internal information via standard protocols does somehow not break GPL3 terms compared to two libraries that share internal state via the standardized C ABI which does. And they seem to not consider that a bug, just the build-time dependency.
Sorry that’s my mistake - I should have said “source available”, rather than “open source”. IMO, being source available is the critical component of a password manager like Bitwarden, and is what I meant when I referred to their main competitive advantage.
They might also choose to be open source and fix this specific issue and return to GPL-compatibility, but remaining source available would seem to be the more critical factor.
So you meant to say:
I would go as far as to say that Bitwarden’s main competitive advantage and differentiation is that it’s source is available.
That is not true, there are a lot of other password management software out there where the client source code is either open source or source available. For instance keyguard: https://github.com/AChep/keyguard-app?tab=License-1-ov-file#readme which is an alternative proprietary bitwarden client, where the source is also available. Also the Proton Pass client is under GPLv3.
I would argue that the main advantage of bitwarden compared to others is that it is open source and has an open source server for self-hosting (vaultwarden). Which of course makes it difficult in terms of business strategy with their VC funding. But maybe becoming a non-profit org and getting money from donors, the strategic funds of EU and other governments, etc. might be an alternative way.
