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.

  • asap@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    6 hours ago

    Gitlab has demonstrated its commitment to keep the core of their product, though limited in features, free and open source. As of now, BW’s clients cannot even be compiled without the proprietary SDK anymore.

    None of that makes Bitwarden not open source. Not only that, they specifically state this is a bug which will be addressed.

    I would go as far as to say that Bitwarden’s main competitive advantage and differentiation is that it’s open source. They would be insane to stop that.

    • cmhe@lemmy.world
      link
      fedilink
      arrow-up
      5
      ·
      3 hours ago

      None of that makes Bitwarden not open source.

      Yes, it does, because it violates its own license GPLv3 by having proprietary build-/runtime dependencies.

      If it was under a different, maybe more permissive, open source license, then maybe it would still be open source, but as of right now i likely breaks its own license terms.

      Not only that, they specifically state this is a bug which will be addressed.

      From what they state, they think that because executables that share internal information via standard protocols does somehow not break GPL3 terms compared to two libraries that share internal state via the standardized C ABI which does. And they seem to not consider that a bug, just the build-time dependency.

      • asap@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        arrow-down
        1
        ·
        edit-2
        3 hours ago

        Sorry that’s my mistake - I should have said “source available”, rather than “open source”. IMO, being source available is the critical component of a password manager like Bitwarden, and is what I meant when I referred to their main competitive advantage.

        They might also choose to be open source and fix this specific issue and return to GPL-compatibility, but remaining source available would seem to be the more critical factor.

        • cmhe@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          3 hours ago

          So you meant to say:

          I would go as far as to say that Bitwarden’s main competitive advantage and differentiation is that it’s source is available.

          That is not true, there are a lot of other password management software out there where the client source code is either open source or source available. For instance keyguard: https://github.com/AChep/keyguard-app?tab=License-1-ov-file#readme which is an alternative proprietary bitwarden client, where the source is also available. Also the Proton Pass client is under GPLv3.

          I would argue that the main advantage of bitwarden compared to others is that it is open source and has an open source server for self-hosting (vaultwarden). Which of course makes it difficult in terms of business strategy with their VC funding. But maybe becoming a non-profit org and getting money from donors, the strategic funds of EU and other governments, etc. might be an alternative way.

          • asap@lemmy.world
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            3 hours ago

            I’m not aware of any other enterprise password management where the server source is available and auditable. Proton certainly is not.