Desktop version 2024.10.0 is no longer free software · Issue #11611 · bitwarden/clients
github.com
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: Y...

@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-secret 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.

  • Lojcs@lemm.ee
    446·
    27 days ago

    They literally said the issue was an unintentional bug and then fixed it. How is that damage control?

    • Atemu@lemmy.mlOP
      2·
      25 days ago

      One does not “accidentally” build a proprietary SDK for months and make the clients depend on it, intentionally violating the GPL.

      They even publicly admitted to doing precisely that, defending their GPL violation with dubious claims how the GPL supposedly works.

    • Redjard@lemmy.dbzer0.com
      23·
      27 days ago

      They were doing the same on other repos for months.
      Both their npm module and android client.
      On android they tried to get people to add their own fdroid repo because the official fdroid has not had updates for 3 months due to the license changes.

      Edit: Looking at it now compared to 4 days ago, they apparently got frdoid to remove bitwarden entirely from the repo. To me this looks like they are sweeping it under the rug, hiding the change pretending it has always been on their own repo they control.

      Next time they try this the mobile app won’t run into issues, the exact issues that this time raised awareness and caused the outcry on the desktop app, which similarly is present in repos with license requirements.

      If they were giving up on their plan, wouldn’t they “fix” the android license issue and resume updating fdroid, instead of burning all bridges and dropping it from the repo entirely, still pushing their own ustom repo? Where is the npm license revert?