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.

you are viewing a single comment's thread
view the rest of the comments

[–] asap@lemmy.world 0 points 1 week ago (1 children)

What features will depend on the close-source part, and which do not?

There are definitely some terminology issues here.

The SDK is not closed source, you can find the source here: https://github.com/bitwarden/sdk

It might not be GPL open-source, but it is not closed either.

Other than that, I agree with your points. I don't agree with the kneejerk hysteria from many of the comments - it's one of the worst things about FOSS is how quick people are to anger (I am not referring to you here).

But all of that still doesn’t explain what their goal of introducing the proprietary SDK is.

Let's wait and see before we get out the pitchforks.

[–] cmhe@lemmy.world 7 points 1 week ago* (last edited 1 week ago)

The SDK is not closed source, you can find the source here: https://github.com/bitwarden/sdk

It might not be GPL open-source, but it is not closed either.

Sure. To me "source available" is still closed-source, since looking into it might give companies an attack surface for you to have violated their copyright in the future. Happened with IBM in the past: https://books.google.de/books?id=gy4EAAAAMBAJ&lpg=PA15&pg=PA15&redir_esc=y#v=onepage&q&f=false

Let’s wait and see before we get out the pitchforks.

Sure. Bitwarden doesn't owe us anything, but it is still sad to see this decision and better clarification and explanation could have alleviated the breaking of the trust here.