Lately, it seems like open source is mostly a marketing gimmick of gathering free traction early on without spending tons of money on advertising and then later gradually pulling the rug.
Examples galore. At this point, I'd assume any open source project in past five to eight years taking this trajectory at any point.
https://techcrunch.com/2022/09/06/open-source-password-manag...
This imbalance needs to be recognised.
I adopt a 3-2-1 backup strategy for my Bitwarden password-protected exports, which can be decrypted without needing Bitwarden. In addition, I use a separate non-Bitwarden solution for my MFA secrets. This minimizes damage and facilitates migration in the event Bitwarden degrades, or becomes outright malicious like Raivo. The same would apply to the password manager I'd switch to after Bitwarden in the near future, and any other password manager thereafter.
As far as I can tell, the only competitor with a similar feature set that even claims to be open-source is Proton Pass. But I can't find any information on whether the server side can be self-hosted.
Now I'm gonna move to KeePassXC. What is the recommended way to sync the db with Android? I only have a Raspberry PI server running cloudflared.
IMO, the secret to keeping the passwords synced with KeePass, is to make sure your client has a direct feature to sync the passwords database to a remote server - SFTP, DAV, SMB, etc. Then all you need to do is to set up a single remote file share to serve that file. Or sync manually, assuming your passwords change slowly - KeePass 2 can sync changes automatically between KDBX files.
Thanks for sharing your concerns here. We have been progressing use of our SDK in more use cases for our clients. However, our goal is to make sure that the SDK is used in a way that maintains GPL compatibility.
the SDK and the client are two separate programs code for each program is in separate repositories the fact that the two programs communicate using standard protocols does not mean they are one program for purposes of GPLv3 Being able to build the app as you are trying to do here is an issue we plan to resolve and is merely a bug.
https://github.com/dani-garcia/vaultwarden
Such a shame that this keeps happening with open source projects once the money people step in.
You have absolute freedom in truly open source software at the point of any particular release.
So, you have the freedom to fork or self-build/host at discrete time points.
Assuming software made by a company to remain and persist truly open source (compatible)is idiotic.
Praise the freedoms you have had for this time.
The constant criticisms will likely mean that new companies or new products will never opt for open source in the future . And that is a poorer outcome for the world.
After getting VC funding, the focus also seemed to be more revenue and profit driven. There’s nothing wrong with this choice, but it does push companies in a direction that’s very different from how they started and grew.
Proton Pass looked a little interesting, but its pricing model is always a bit on the higher side (like with other Proton services). I’ve been trying Proton Pass free for a while, and will see if it’s worth switching to as a replacement for Bitwarden (because the latter wasn’t improving in a way that I was waiting for, over many years).
The built-in password manager on iOS is also good enough, but it’s only for passwords and doesn’t support storing, retrieving and filling other types of data.
https://github.com/ProtonMail/WebClients/tree/proton-pass%40...
https://github.com/protonpass/android-pass/blob/1.26.1/LICEN...
I am Sascha, the main developer behind it and we have no VC money nor any plan to do a stunt like this.
Sadly, in my direct experience, VC-backed competitors will just use the bootstrapped firm's open source work as free R&D. Or even use their bootstrapped open source code in a way which directly competes with the bootstrapped business. And they'll hire marketers and directly target the bootstrapped firm's customer base.
When the bootstrapper complains, the VC-backed companies all just proclaim "You shouldn't have chosen an open source license if you didn't want this to happen!" ... which is correct legally (the licenses don't prohibit this behavior), but blatantly ignores the complete destruction of the social contract which makes independent / bootstrapped open source possible.
"The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities."
I get that it's really hard to make money as an open source company. (That's why I am one of your paying customers.)
The exclusion you are putting on your SDK seems very similar to that of the "bitkeeper" version control software used for the Linux kernel for a short time. Look how that turned out.
https://github.com/bitwarden/sdk/issues/898#issuecomment-222...
This was a reply in July, where someone raised this issue already on the SDK repository, which has this license since over a year ago.
But it's a combination of greed and managment iconpetence which leads many succesful open source products from quick wins (after the initial shock) into gradually losing customers to alternative technologies
While there seems to be an alternative, the root cause of Google's hostility to foss apps does not make me optimistic about this being a stable solution in the long run :(
https://forum.syncthing.net/t/discontinuing-syncthing-androi...
https://forum.syncthing.net/t/discontinuing-syncthing-androi...
This is primarily the reason I am careful going deep into the Tailscale ecosystem (which, similar to earlier Bitwarden, is touting a "hey, we are the good guys" horn for now). My network is a critical piece of my infra and I don't want to put too much trust in one company.
You've now answered "Do your lawyers think you can get away with this?". But the questions you're not answering directly, which I think underlie the 'concerns' you're appreciating our sharing, are things like...
- Does the Bitwarden team see no ethical problems with making proprietary a project which many supported and contributed to explicitly because it was open source?
- Given that password management is explicitly a high-trust enterprise, how does your organization intend to navigate the rupture of trust, and subsequent forks and waves of departure, caused by an open-to-proprietary rugpull?
- Is there something that the community could do together which would help your company navigate through the dire situation you must be in to be considering something like this, without resorting to proprietarization?
I know it's his job as CTO right now to be feigning concern, particularly in forums where you can't close the conversation, but the current approach is basically confirming the worst fears ("They believe they can legally do it, and see no problem with their actions"), and that seems like exactly the wrong vibe for a company whose bottom line depends on users trusting the code and the people updating it.
GPL licenses have allowed so-called "mere aggregation", where separate programs are distributed together. Such programs don't have to be all covered by GPL.
On the other hand, if parts are intimately tied to each other such that they are effectively a single program, GPL applies to the whole.
The FSF commentary explains that the judgment depends both on the mechanisms and the semantics of the co-operation. Technical implementation details don't make programs separate if they are intimately designed to work together: "But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."
I'm a premium member @$10/year as well. There goes lost business because of shady practices.
Is there a way to export and move to an alternative?
Assuming they stick with openly auditable code (albeit not FOSS) then it's still than purely commercial options.
Nevertheless, my argument is that it should be cherished that we've had (guessing) best part of a decade of opensource BitWarden that cannot be taken away from us. The FOSS bit is purely temporal ... $now, the exact commit/release/tag/head when an FOSS license is in play, it remains FOSS - it's just the next commit isn't FOSS ... but there's no binding license that says it is/should/has-to remain for future commits.
Nobody's rights are being taken away here.
"Beleiving in FOSS" just needs to be more short-term focussed or prepare for continual dissappointment.
What’s going to change?
* Bitwarden remains committed to
* An open source architecture
Moving to closed source is a high risk move for them. While I haven't paid for software in a long while I can and do pay for the security. Bitwarden stores the information I consider my most precious, and private. Which is why I'm paying for bitwarden. But it's just software, it doesn't matter where the bytes that call themselves "bitwarden" come from. Anybody can fork it and serve up those same bytes. Someone setting up a mirror of bitwarden that only uses open source software will get my money. (Suggestion: if you do this, each to reproduce built instructions that yield the same binaries you are running, and that I download into my various devices would be very nice.) I don't consider my passwords to be secure unless they that are managed by open source software.
Just a long time BitWarden user and subscriber. Content that it'll likely remain openly auditable - which is the principal benefit here - and do not care that the authors want to make it more profitable/sustainable. For a system keeping all my stuff safe, when they're probably fending off nation-state attackers, that's a position that is satisfactory to me.
Re: the dusty account, the Internet seldom offers me stuff I can be bothered to comment on.
* If your monetization model involves a SaaS version of your product, VC-backed competitors can release open source code which extends your AGPL product in ways which compete with your paid SaaS. (The VC funding allows them to do things like this that don’t provide them revenue, and isn’t even part of their core product, but nonetheless takes market share away from bootstrapped competitors.)
* Or if your monetization strategy is open-core, then same as previous bullet, they can build FOSS solutions which reimplement your paid features just to take market share away from you.
* If your AGPL product contains novel techniques or innovations, VC backed competitors can copy those concepts without directly using your code. Free R&D for them.
* If your AGPL product involves a paradigm shift for how to approach a problem, you have to do a ton of outreach and education on how to use your software. Later on, newer VC-backed competitors can just piggyback on all that effort you already did. And then if you have any public customer testimonials, their marketers will directly target those customers.
These aren’t hypothetical situations by the way, this stuff actually happens. It isn’t just big cloud vendors doing it either. And no FOSS license protects you from it.
Some non-OSI "source available" licenses do provide protection from the first two bullets, by way of prohibiting competitive uses, but that doesn't help with the latter two bullets.
And this is the problem now. Even if BW doesn't plan to do this, we'll always be suffixing that kind of sentence with "doesn't plan to do this.. yet". We've seen this happen too often in the past years, and now we have to consider VC-backed open-source as potentially hostile and prepare for the worst, which means we can't trust them as much...
In the latter case, IIUC their CLA (https://cla-assistant.io/bitwarden/clients) allows to do change the license unilaterally. (Not a legal expert, so please correct me if I am wrong.)
If so, then I feel strengthened again in my conviction that permissive licenses (as well as closed-source licenses) and CLAs are bad for both users and developers and should be avoided, if possible.
Because the goal of capital is more capital. Doing ethical things and contributing to commons doesn't align with such goal.
So every time "investors" arrive the outcome is known.
here’s an older of comment of mine for more details: https://news.ycombinator.com/item?id=36022210
Part of my framing for the assessment was "everyone in my family uses 1P and they're happy with it, will this be good enough to convince them to switch." While I ultimately can make the call for the switch, user experience is very important when you're trying to get elderly parents to do something new.
It was not to be.
Aside from the generally poor UX, Bitwarden's clients (on linux, mac, windows, and ios) were also dramatically slower (in every way, from search to login), had fewer features (sorting passwords, favourites, good organization tools to name the most glaring omissions), and I found autofill far less reliable.
I've taken great issue with 1password's way of doing business and dealing with customers over the years. Sadly, and with some regret, I went back, because a password manager (really a secret manager at this point with so much more than passwords in it) is so central to daily life, I feel that I need one that is as as painless as possible.
I wasn't one that used Bitwarden because it was open, I tried to use the best password manager possible.
However, I LIKED that it was Open. And Vaultwarden is a gem. Wish I had the time and skills to make a better front-end for it really.