@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.
…or they’re just bad at PR. It’s not a skill everyone has.
…or they made an honest mistake and don’t care to put it back on F-droid for reasons to which we are not privy. I bring up these counter-examples not as a way to point out where I’m right and you’re wrong, but to point out that there are other candidate explanations, and it’s not justified to infer that malfeasance is the only likely possibility.
I also understand why you would cynically think that Bitwarden might succumb to Capitalism—I too live in a late-stage-capitalism country—but that’s not a forgone conclusion, and I say again that we don’t need to be imagining villains when there’s plenty of objectively real ones at which to point a finger already.
I think it is unlikely that they are simply bad at PR and not trying to do damage control for something they would like to push anyways eventually. Why are they creating a proprietary element in the first place? Is the selling point of their product not that it is open source? They are making some changes.
An honest mistake of hosting their entire own repo and writing up documents for it? It isn’t just off F-Droid, they are doing their own thing.
Yes you are suggesting that people give them the benefit of the doubt. And I am saying that would be unreasonable given the facts.
Bitwarden has already succumbed to capitalism, it is a product by and for a for-profit company. It is, with few exceptions, just a question of when they will have a profitability crisis and need to find avenues by which to increase revenues or decrease costs. Sometimes that takes 15-20 years, sometimes it takes 3.
I have not followed their finances but I would be curious to know what they are doing at the moment. Could be seeking to get bought out, could be looking for new funding, could be working around the needs of a major client, could be something else.
As always, when a project is backed by a company we should approach it tentatively because while they will provide support for it for some time they will eventually be tempted to do something shady to increase profit. Or to just be profitable at all, which investors always want ASAP when interest rates are high. And then we will need to fork it and see if it is feasible without VC backing. To my knowledge the only other viable path for an open source company is to become an industry standard where the major monopolies decide to not fight about it and instead say, “it is fine as it is and won’t be profitable but it is a useful thing to share costs on”. Docker, Inc. is somewhere along that path, scraping together products at the periphery of the software while the industry monopolies more or less share the core project in its various compatible forms. And Docker similarly tried to ham-fistedly seek profit sources like when it tried a silly fee scheme for Dockerhub and created a small exodus that the monopolies ate up (e.g. GitHub).