Let’s see how it turns out. Instead of attacking.
that’s unfortunate. Was considering switching to bitwarden for their browser extension but now I’m definitely not doing so anymore
As this story develops and we receive more clarity , I would like to say that even if a service or a product decides to make their code proprietary doesn’t necessarily mean that the service or product is going to be bad. Yes there maybe issues regarding its transparency but all trust is not lost and if they provide us good services at a very cheap price , only closing source wouldn’t be a deal breaker.
Also to consider that bitwarden is a company and would be spending a lot on the developers and employee cost to make this project up and running.
Doing a business with opensource model and products might not be profitable venture for everyone (we already have seen an example with skiff) and the ways to monetize it maybe difficult while tackling competition in the market. Also i am not sure how profitable is there business and team offerings So in the long term a closed source approach may help the company to better sustain the project and ensure its survival.
I am not aware at this point the reasons behind such decision but i would rather use a service which ensures its long term sustainability of the product and promises continuous improvement than the one which would keep false promises.
Being a bitwarden user for a long time i would certainly want them to have a more sustainable business model than fail on promises at later point.
This is hugely concerning. I guess this is just what happens with VC companies. Extremely disappointing
At least BW is only a password manager; users aren’t locked in as it should b e easy to export your database and switch to something else.
Proprietary is not the same as source available with restrictions. If the code is still available for public viewing, this is what is most important for security and privacy.
How they combined a GPLv3 license with a restrictive one and if that’s even GPL compatible, I have no idea. From my super brief view in the commit, it looks like the SDK is opt-in, so default builds don’t include it? Not sure. But the client is still GPLv3, so that’s as free as you get for client code.
Overall, saying it’s proprietary is just plain wrong. It may violate Freedom 0 of GPL, but so does FUTO with their software.
I consider FUTO to not be open source. I think there are benefits of open source software that go beyond security and privacy concerns, hence why i am extremely disappointed with this pivot
I agree it’s disappointing for similar reasons, at least in terms of freedom. However, I’ll take source available over proprietary if it’s coming from corpos. Even then, the client is still GPLv3, with the SDK their source available license, so the SDK can be swapped from a OSS one (I believe).
Also, cloud based password managers are possibly the most sensitive applications you can possibly run and therefore any potentially negative change should be taken very seriously by everyone who uses it.
If let’s say an emulator became proprietary, you could just put it in a sandbox, deny the network permission and forget about it, but you can’t just brush something like this off for a password manager that must connect to the internet and by design is to be highly trusted by the user.
Only way to validate server side code is indeed running the code is through AGPL. With this, their server code is a combination of AGPL and their business like license. In other words, while you don’t have the freedom to fork and rebrand, you’ve got the freedom to request the source code for audit and validation. That’s pretty good for security and privacy.
The Bitwarden SDK, which is a core component of their apps has already been proprietary for a long while.
See:
- sdk/LICENSE at 6460db27b098bf58983632430380c0a2886d3796 · bitwarden/sdk · GitHub
- bitwarden (!15353) · Merge requests · F-Droid / Data · GitLab
ianal but since the apps are actually GPL-3.0 this can do two things:
- make the clients “look but don’t touch” since they depend on a proprietary blob, effectively becoming source available
- or since GPL is toxic, actually invalidate the license of the proprietary blob, since they author it too
I’ve been bringing this up in my chat over the past few weeks and getting people to switch, because it is not a good direction.
What password manager do you recommend?
Yeah, but one problem is that now people will be less incentivized to look at the codebase if they can’t do anything with it. I’m not saying that it’s necessarily the end of the world but it’s a problem, in my opinion
The tried and true KeePass and KeePassXC: GPL without a bullshit CLA and offline as God intended.
4 posts were split to a new topic: Financial side of privacy-focused FOSS software and projects
Isn’t Proton Pass proprietary (at least the backend?)
They locked the GitHub discussion too. This is not a good sign
A post was merged into an existing topic: Financial side of privacy-focused FOSS software and projects