@brjsp thanks again for submitting the concern here. We have made some adjustments to how the SDK code is organized and packaged to allow you to build and run the app with only GPL/OSI licenses included. The sdk-internal package references in the clients now come from a new sdk-internal repository, which follows the licensing model we have historically used for all of our clients (see LICENSE_FAQ.md for more info). The sdk-internal reference only uses GPL licenses at this time. If the reference were to include Bitwarden License code in the future, we will provide a way to produce multiple build variants of the client, similar to what we do with web vault client builds.

The original sdk repository will be renamed to sdk-secrets, and retains its existing Bitwarden SDK License structure for our Secrets Manager business products. The sdk-secrets repository and packages will no longer be referenced from the client apps, since that code is not used there.

This appears at least okay on the surface. The clients’ dependency on sdk-internal didn’t change but that’s okay now because they have licensed sdk-internal as GPL.

The sdk-secret will remain proprietary but that’s a separate product (Secrets Manager) and will apparently not be used in the regular clients. Who knows for how long though because, if you read carefully, they didn’t promise that it will not be used in the future.

The fact that they had ever intended to make parts of the client proprietary without telling anyone and attempted to subvert the GPL while doing so still remains utterly unacceptable. They didn’t even attempt to apologise for that.

Bitwarden has now landed itself in the category of software that I would rather move away from and cannot wholeheartedly recommend anymore. That’s pretty sad.

  • Atemu@lemmy.mlOP
    link
    fedilink
    arrow-up
    1
    ·
    1 month ago

    Also, their client is still open

    *is open again. The clients they distributed were not open source until they open sourced sdk-internal. The fact that you couldn’t even build it with only open code even if you wanted to was a bug but that’s a rather minor issue in comparison.

    I also fully believe that they would not have GPL’d sdk-intenral without public pressure. Even when they were originally called out they were pretty clear that the integration of proprietary code was intentional and done with the knowledge that it would typically violate the GPL.

    If you don’t see what’s ethically wrong with even attempting to subvert the GPL, I don’t think you’ve understood open source.

    • Telorand@reddthat.com
      link
      fedilink
      arrow-up
      1
      ·
      1 month ago

      You might not have read the other comments, but I do QA for a living. Devs fucking up commits is why I continue to have a job. Also, companies/maintainers aren’t required to capitulate to every bug report. It’s possible that whoever made the original comments didn’t understand why it was such a big deal and/or didn’t know of an alternative way to structure their software; public pressure made them look a little harder.

      Like I said in my first comment: you do you. Bring out the pitchforks. The fact that there’s reasonable candidate explanations other than malicious intent says to me that the internet is overreacting—again.

      Though, when has the internet ever done that, amirite? /s

      • Atemu@lemmy.mlOP
        link
        fedilink
        arrow-up
        1
        ·
        22 days ago

        That would be a reasonable explanation if we didn’t get an admission this was done very much intentionally so, with only the inability to even build being an unintended side-effect from the founder and CTO himself.

        I’d invite you to actually read the two comments they made in the thread I linked, I get the feeling that you didn’t.