this post was submitted on 20 Oct 2024
528 points (95.4% liked)

Open Source

30950 readers
406 users here now

All about open source! Feel free to ask questions, and share news, and interesting stuff!

Useful Links

Rules

Related Communities

Community icon from opensource.org, but we are not affiliated with them.

founded 5 years ago
MODERATORS
 

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
[–] fireshell@lemmy.ml 3 points 6 days ago

https://github.com/bitwarden/clients/issues/11611#issuecomment-2436287977

We have made some adjustments to how the SDK code is organized and packaged to allow you to build and run the app with only GPL/OSI licenses included. The sdk-internal package references in the clients now come from a new sdk-internal repository, which follows the licensing model we have historically used for all of our clients (see LICENSE_FAQ.md for more info). The sdk-internal reference only uses GPL licenses at this time. If the reference were to include Bitwarden License code in the future, we will provide a way to produce multiple build variants of the client, similar to what we do with web vault client builds.

https://github.com/bitwarden/sdk-internal/commit/db648d7ea85878e9cce03283694d01d878481f6b

Thank you to Bitwarden for relicensing a thing to GPLv3 License!

[–] andrew_s@piefed.social 128 points 1 week ago* (last edited 1 week ago) (3 children)

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 60 points 1 week ago (3 children)

Um can someone translate what this means?

[–] superkret@feddit.org 116 points 1 week ago (3 children)

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™

[–] CosmicTurtle0@lemmy.dbzer0.com 26 points 1 week ago (1 children)

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 18 points 1 week ago (1 children)

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 11 points 1 week ago (2 children)

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.

[–] Redjard@lemmy.dbzer0.com 12 points 1 week ago (3 children)

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.

load more comments (3 replies)
load more comments (1 replies)
[–] umbrella@lemmy.ml 17 points 1 week ago

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

[–] Redjard@lemmy.dbzer0.com 16 points 1 week ago

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.

[–] TheOubliette@lemmy.ml 47 points 1 week 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.

[–] Natanael@slrpnk.net 22 points 1 week ago

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

[–] umami_wasbi@lemmy.ml 24 points 1 week ago

plan to resolve

timeline unknown, maybe 2124

load more comments (1 replies)
[–] twirl7303@lemmy.world 51 points 1 week ago (9 children)

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.

[–] lemmeBe@sh.itjust.works 8 points 1 week ago

I will change for sure, as well. Let's see.

load more comments (8 replies)
[–] mli@lemm.ee 49 points 1 week ago* (last edited 1 week ago) (1 children)

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.

load more comments (1 replies)
[–] SteleTrovilo@beehaw.org 48 points 1 week ago

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

[–] fl42v@lemmy.ml 46 points 1 week ago (2 children)

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 1 week ago (1 children)
[–] fl42v@lemmy.ml 30 points 1 week ago (2 children)

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.

load more comments (2 replies)
load more comments (1 replies)
[–] rozlav@lemmy.blahaj.zone 40 points 1 week ago (10 children)

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/

[–] Atemu@lemmy.ml 19 points 1 week ago

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.

[–] unrushed233@lemmings.world 16 points 1 week ago (3 children)

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.

load more comments (3 replies)
[–] EveryMuffinIsNowEncrypted@lemmy.blahaj.zone 9 points 1 week ago* (last edited 1 week ago)

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.

load more comments (7 replies)
[–] Lemmchen@feddit.org 35 points 1 week ago* (last edited 1 week ago) (2 children)

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 19 points 1 week ago* (last edited 1 week ago) (6 children)

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.

load more comments (6 replies)
load more comments (1 replies)
[–] EveryMuffinIsNowEncrypted@lemmy.blahaj.zone 22 points 1 week ago (3 children)

Damn, I just switched from Bitwarden to KeepPassXC.

Clearly just in time. Lol.

load more comments (3 replies)
[–] wuphysics87@lemmy.ml 18 points 1 week ago (1 children)

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?

[–] Atemu@lemmy.ml 14 points 1 week ago (5 children)

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.

load more comments (5 replies)
[–] smiletolerantly@awful.systems 16 points 1 week ago (10 children)

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

load more comments (10 replies)
[–] nichtburningturtle@feddit.org 14 points 1 week ago (2 children)

Does this affect valtwarden?

[–] TheOubliette@lemmy.ml 40 points 1 week 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 21 points 1 week 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.

[–] zanyllama52@infosec.pub 13 points 1 week ago

Laughs in keepassxc

[–] wuphysics87@lemmy.ml 13 points 1 week ago

How would the community's reaction be if Bitwarden goes, "Look, we are moving more into the enterprise space, which means using proprietary software to service their needs. Our intention is to keep the enterprise and public versions sandboxed, but there is crossover, and we made a mistake."? I really don't care what they do in the enterprise space. Perhaps I'm an apologist, but seemingly more torn than most other posters.

[–] daggermoon@lemmy.world 12 points 1 week ago (2 children)

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

load more comments (2 replies)
[–] KLISHDFSDF@lemmy.ml 11 points 1 week ago (4 children)

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 (4 replies)
[–] vordalack@lemm.ee 11 points 1 week ago

Dumb it.

Move to something else.

This is how fuckery starts.

[–] umbrella@lemmy.ml 10 points 1 week ago* (last edited 1 week ago) (1 children)

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 11 points 1 week ago (4 children)

KeePassXC is pretty amazing. :)

load more comments (4 replies)
load more comments
view more: next ›