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.
Unfortunate. Is Proton Pass now the only big option for a cloud synced password manager?
Although proprietary isn’t inherently bad (1pass for ex.), it doesn’t bode well for future. Plus I like seeing the software I use.
Off topic rant
Yet another FOSS software that wasn’t able to monetize well. The chokehold of big tech has not only been surveillance and weaponization of data, it’s also addicting users to “free” services.
Lots of larger conversations are needed, if projects like this are to survive mass adoption. FUTO is one direction, Linux is another, Proton is one more. Hopefully projects go the Linux (corporate sponsorship) or the Proton (aggressive monetization and marketing, targeting business users). Depending on FOSS users won’t sustain any project since nobody pays lol. Serious FOSS projects need to shed the hobby project label and start actually focusing on finances a lot.
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?)
Yes, exactly. This happens to be a good read and one of the few areas I agree with Andy Yen on unconditionally: Sustaining Proton’s mission over time | Proton
Profit is not a bad word, and if you don’t understand this early, you will have to either compromise ideals or go bust.
Yes backend is proprietary. But I’d take a transparent company with regular audits over a company that makes their stuff proprietary suddenly without informing anyone. At least one of them has my trust and clear about threat model from the beginning 
Also seems to be a pattern with Bitwarden: Open-Source-Confusion-Cases/cases/bitwarden-passwordless.md at 2a4776fe64a1bdb1a8fdc71b536c7ad5b8cc2a91 · ssddanbrown/Open-Source-Confusion-Cases · GitHub