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.

  • cmhe@lemmy.world
    link
    fedilink
    arrow-up
    8
    ·
    2 months ago

    Well, then it would be nice to hear from them an explanation on why they decided to violate the GPLv3 on their client, by coupling it with proprietary code in a way that disallows building and/or usage without that proprietary component.

    They would be insane to change that.

    Yes. And i hope that they recover from it soon.

    • asap@lemmy.world
      link
      fedilink
      English
      arrow-up
      5
      ·
      edit-2
      2 months ago

      Well, then it would be nice to hear from them an explanation on why they decided to violate the GPLv3

      Lucky for you, they provided that explanation:

      1. This is a bug/mistake.
      2. Our goal is to make sure that the SDK is used in a way that maintains GPL compatibility.
      3. We will fix this.
      • cmhe@lemmy.world
        link
        fedilink
        arrow-up
        5
        ·
        2 months ago

        Ok, lets take it step by step:

        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

        I think they meant executable here, but that also doesn’t matter. If both programs can only be used together and not separate, and one is under GPLv3, then the other needs to be under GPLv3 too.

        • code for each program is in separate repositories

        How the code is structured doesn’t matter, it is about how it is consumed by the end-user, there both programs are delivered together and work together.

        • the fact that the two programs communicate using standard protocols does not mean they are one program for purposes of GPLv3

        The way those two programs communicate together, doesn’t matter, they only work together and not separate from each other. Both need to be under 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.

        Not being able to build a GPLv3 licenses program without a proprietary one, is a build dependency. GPLv3 enforces you to be able to reproduce the code and I am pretty sure that the build tools and dependencies need to be under a GPLv3 compatible license as well.

        But all of that still doesn’t explain what their goal of introducing the proprietary SDK is. What function will it have in the future? Will open source part be completely independent or not? What features will depend on the close-source part, and which do not? Have they thought about any ethical concerns, that many contributors contributed to their software because it under a GPL license? How are they planning on dealing with the loss of trust, in a project where trust is very important? etc.

        • asap@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          ·
          2 months ago

          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.