Biwarden is changing license on its SDK. What is the impact on Vaultwarden?

[elmuz]

After being a happy Bitwarden user for many years, I am in the process of self-hosting the server and finally moving to Vaultwarden. This morning I woke up with the following unpleasant news.

Now I am not a super expert so I'm here to ask for your opinion. Given bitwarden/sdk-sm#898 and bitwarden/clients#11611, how things are going to change from Vaultwarden perspective and the way people are interacting with it?

[driftywinds]

I would like to know too!

[mpaguilar]

Are there any forks of the existing free client?

[vlad196]

This is the right question. While there are no alternative clients, vaultwarden depends on bitwarden.

[ThowZzy]

Would this mean we need alternative clients ? So another client on all the stores, browser extensions...

[Silentely]

The official personnel have provided a new response, but the topic has already been locked. Please stay tuned for further updates.
“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.”

[ySp-chld]

if that response is true, then it's fine to continue to use bitwarden client code for now because GPL code cannot be shipped with more restrictive license making the restrictive license non applicable but I'm no lawyer :
bitwarden/sdk-sm#898 (comment)

[pheiduck]

See: https://www.phoronix.com/news/Bitwarden-Open-Source-Concerns 😉

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."

[Hate9]

Honestly, I'm kinda hoping this results in VW-branded forks of the official clients. I like the VW branding more anyway, and I was kind of surprised there weren't prominent client forks already.

Now, the question is, will it be easier to maintain full forks of the apps themselves, or to just do GPL reimplementation of the SDK and keep the client forks synced with upstream?

[stefan0xC]

Now, the question is, will it be easier to maintain full forks of the apps themselves, or to just do GPL reimplementation of the SDK and keep the client forks synced with upstream?

Maintaining full forks of all the clients would be too cumbersome I think. So as long as this is still only a "packaging bug" it would probably be easier to maintain soft forks that just remove the dependency on the SDK (if this bug is not fixed upstream) but I have not looked much into it. Either way I would not want to cry wolf when the clients have not been relicensed yet (cf. #4918 (reply in thread)).

[stefan0xC]

Update: bitwarden/clients#11611 (comment)

Given that they have now dual-licensed the referenced code under the GPL-3.0 bitwarden/sdk-internal#10 it would be possible to maintain a "deblobbed" version of the npm package if deemed necessary (assuming that the proprietary code is still shipped with the package).