this post was submitted on 25 Oct 2024
243 points (96.9% liked)

Linux

48323 readers
637 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
AgreeableLandscape@lemmy.ml
nooter692@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r@lemmy.nz
243
Bitwarden update: sdk-internal now GPL, sdk/sdk-secrets to remain proprietary but not used in clients (github.com)
submitted 4 weeks ago by Atemu@lemmy.ml to c/linux@lemmy.ml
22 comments fedilink hide all child comments
 

@brjsp thanks again for submitting the concern here. 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.

The original sdk repository will be renamed to sdk-secrets, and retains its existing Bitwarden SDK License structure for our Secrets Manager business products. The sdk-secrets repository and packages will no longer be referenced from the client apps, since that code is not used there.

This appears at least okay on the surface. The clients' dependency on sdk-internal didn't change but that's okay now because they have licensed sdk-internal as GPL.

The sdk-secrets will remain proprietary but that's a separate product (Secrets Manager) and will apparently not be used in the regular clients. Who knows for how long though because, if you read carefully, they didn't promise that it will not be used in the future.

The fact that they had ever intended to make parts of the client proprietary without telling anyone and attempted to subvert the GPL while doing so still remains utterly unacceptable. They didn't even attempt to apologise for that.

Bitwarden has now landed itself in the category of software that I would rather move away from and cannot wholeheartedly recommend anymore. That's pretty sad.

you are viewing a single comment's thread
view the rest of the comments
[–] Miimikko@lemmy.world 23 points 4 weeks ago* (last edited 4 weeks ago) (9 children)

Uhh what does this mean for us dummies? For reference I run a self hosted vaultwarden server and connect to it with Bitwarden clients.

[–] N0x0n@lemmy.ml 9 points 4 weeks ago (3 children)

I think right now it doesn't mean anything :/. It's more a 'wait&see' situation... However as many many other stories in the past, this doesn't sound good and bitwarden is slowly and carefully following the 'enshitification' path !

Keep an eye open and get ready to switch to another password manager (maybe a fork?).

[–] Buckshot@programming.dev 14 points 4 weeks ago (2 children)

Yeah I'll willing to give them the benefit of the doubt on this one. Could very easily believe that a dev added the reference without realising the implications and they fixed it very quickly. Will be watching for any future attempts though.

[–] deadcade@lemmy.deadca.de 3 points 4 weeks ago (1 children)

If this was the case, the phrashing around the issue would've likely been different. Yet bitwarden remained very vague, and even locked github comments on the issue.

Especially considering that a move like this alienates their core target demographic (people who use FOSS), they would've been much more open and much quicker if it wasn't intentional.

I will personally be switching, likely to KeePassXC.

[–] fartsparkles@sh.itjust.works 4 points 4 weeks ago* (last edited 4 weeks ago)

They highlighted it was a bug and said it would be fixed very soon after it was flagged. It was addressed in a matter of days. You can build the server with the /p:DefineConstants=“OSS” flag still and you can build the clients with the bitwarden_license folder deleted again (now they’ve fixed it).

I don’t understand why you’re throwing FUD about this. Building without the Bitwarden Licensed code has been possible for years and those components under that license have been enterprise focused (such as SSO). The client is still GPL and the server is still AGPL.

This has been the way for years.

load more comments (5 replies)