- 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.
Dump it.
Move to something else.
This is how fuckery starts.
Damn, I just switched from Bitwarden to KeepPassXC.
Clearly just in time. Lol.
I’ll be there in a week or 2 bud. Fuck these companies baiting and then enshitifying it all.
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/
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.
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.
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.
I keep mine in a self hosted Nextcloud instance, DAV sync is built into the app
Ever since BitWarden got mired in capitalism, I’ve been dreading that something like this would happen.
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.
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?
It’s basically your encrypted file, you are to handle synchronisation yourself.
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.
Uh oh. Android user here. Time to jump ship? If so…proton??
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 use a proprietary SDK with their open source apps?
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 GPLv3Being 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.
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.
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.
It means previous versions remain open, but ownership trumps any license restrictions.
They don’t license the code to themselves, they just have it. And if they want to close source it they can.GPLv3 and copyleft only work to protect against non-owners doing that. CLA means a project is not strongly open source, the company doing that CLA can rugpull at any time.
The fact a project even has a CLA should be extremely suspect, because this is exactly what you would use that for. To ensure you can harvest contributions and none of those contributers will stand in your way when you later burn the bridges and enshittify.
What is CLA in this context?
Licensing the source as GPL doesn’t really force the copyright holder (which is 100% BitWarden due to their Contributors Agreement^*, no matter who contributed the code) to do anything - they are absolutely free to release binaries built on the same codebase as proprietary software without any mention of the GPL.
For example if I write a hello world terminal program, release its source code under GPLv3 and then build it and give the built binary to you (and a permission to use it), you cannot force me to give you the source code for that build because I never gave you a GPL licensed binary.
If you were to take my GPLv3 source code and distribute a build of it however, you would have to license your binaries under GPLv3, because that’s the terms of the license I provided the source code to you under. Your users would then have the right to request the source code of those binaries from you. And if you released the build under an incompatible license, I (but not the users) could sue you for violating my license.
Their previous versions, still being under the GPL, would require them to release a change to make it usable on desktops.
License violations are usually not resolved by making the violator comply retroactively, just going forward. And it’s the copyright holder (so BitWarden themselves) who needs to force the violator to comply.
^* this is the relevant part of the CA:
By submitting a Contribution, you assign to Bitwarden all right, title, and interest in any copyright in the Contribution and you waive any rights, including any moral rights or database rights, that may affect our ownership of the copyright in the Contribution.
It is followed by a workaround license for parts of the world where copyright cannot be given up.
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?
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.
pass is enough (+ xdotool + rofi + pass-menu). Synchronization via git or Syncthing.
How does this play with mobile?
as another option this KeePassXC(PC)+radicale+DAVx5 The same for KeepassDX
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.
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.
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.
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.
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.
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.
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.
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 into it 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.
@bitwarden bitwarden locked and limited conversation to collaborators
They also locked the thread 16 hours ago (as of writing this comment), with no explanation.
The explanation is the second-to-last comment before it got locked. 🤦
This hysteria is really stupid.
That “explanation” is unsatisfactory and likely wrong: https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
So they either have to license their SDK under a GPLv3 compatible license, or switch the license of their client to a non-GPL one.
Their “explaination” only mentions why they think can do it, but not why they are doing it.
That may or may not be the case, but the comment I replied to said they locked the thread with “no explanation”.
I would say a proper explanation includes the goal you want to achieve, not just the statement that you think that you are allowed to do something.
