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

Linux

48287 readers
657 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 3 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
[–] fartsparkles@sh.itjust.works 90 points 3 weeks ago* (last edited 3 weeks ago) (3 children)

Cool. They got that sorted nice and quickly.

Edit:

I don’t get why people think they’re suddenly doing stuff under a different license to subvert the open nature of the project. They’ve been totally transparent on what isn’t part of the GPL/AGPL licensed code for years.

SSO, the password health service, organisation auth requests, member access report blah blah have been enterprise features under the Bitwarden License for ages and they architected the projects in a clear and transparent way to build without those features since they added them.

[–] Telorand@reddthat.com 14 points 3 weeks ago

I don’t get why people think they’re suddenly doing stuff under a different license to subvert the open nature of the project.

But then what will I do with my day if I don't have a good reason to be mad at them?

/s

(And thanks for the voice of reason)

[–] doctortran@lemm.ee 6 points 3 weeks ago (1 children)

What they've done in the past has earned them trust, but it is irrelevant to what they intend to do in the future. Bitwarden is growing company, not the scrappy little open source app they once were.

In 2022, a private equity firm injected 100m into Bitwarden. From that point forward, users are rightfully going to scrutinize any action they take because it's 2024 and the tech space is a hellscape of enshitification and acquisitions, thanks in part to VC money. We've seen this story play out too many times to assume there's nothing to worry about.

So yes, people are going to be suspicious. That's not irrational.

[–] nickwitha_k@lemmy.sdf.org 4 points 3 weeks ago

a private equity firm injected 100m

That's all that one needs to know. Once those leeches are involved as investors, it's over. They demand enshitification from our destroy everything that they touch for a quick buck.

[–] Atemu@lemmy.ml 1 points 3 weeks ago (1 children)

Until the situation now, this was limited to the server, not the clients. You could replace the server with Vaultwarden and build it without enterprise features. Not ideal but fine because the server isn't the critical part. It never handles your secrets in any way.

What they tried to do now was integrate proprietary code into the clients that everyone uses. This is a lot more critical as it can access the secrets in plain text.

This also wasn't a "mistake" or "bug", they openly admitted to doing this with the intention of subverting the client code's GPL.

[–] fartsparkles@sh.itjust.works 1 points 3 weeks ago (1 children)

Reference for the admission?

[–] Atemu@lemmy.ml 1 points 2 weeks ago

Two posts up from what I posted: 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.  

  1. the SDK and the client are two separate programs
  2. code for each program is in separate repositories
  3. 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.