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.

  • wuphysics87@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    2 months ago

    A few questions out of ignorance. How different is this to gitlab’s open core model? Is this a permanent change? Is the involvement of investors the root of this? Are we overreacting as it doesn’t meet our strict definition of foss?

    • Atemu@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      2 months ago

      How different is this to gitlab’s open core model?

      That’s a really good question that I don’t immediately have a satisfying answer to.

      There are some differences I can point out though:

      • 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.
      • Gitlab was always a permissive license (MIT) and never attempted to subvert its original license terms
      • Gitlab-EE’s “closed” core is actually quite open (go read the source code) but still squarely in the proprietary camp because it requires you to have a valid subscription to exercise your freedoms.

      Is this a permanent change?

      It’d be quite trivial for them to do in technical terms: Either license the SDK as GPL or stop using it in the clients.

      I don’t see a reason for them to roll it back though. This was decided long ago and they explicitly decided to stray away from the status quo and make it closed source.

      The only thing I could see making them revert this would be public pressure. If they lose a sufficient amount of subscribers over this, that might make them reconsider. Honestly though by that time, the cat’s out of the bag and all the public goodwill and trust is gone.
      It’s honestly a bafflingly bad decision from even just a business perspective. I predict they’ll lose at least 20% but likely 30-50% of their subscribers to this.

      Is the involvement of investors the root of this?

      I find that likely. If it stinks, it’s usually something stinky’s fault.

      Are we overreacting as it doesn’t meet our strict definition of foss?

      They are attempting to subvert one of the FOSS licenses held in the highest regard. You cannot really be much more anti than this.

      An “honest” switch to completely proprietary licenses with a public announcement months prior would have been easier to accept.

      • asap@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        2 months 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
          1
          ·
          2 months 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.