Bitwarden is one of the few subscriptions I have in a patron sense - eg: I've never actually needed any of the premium feature's, but I chose to pay anyway as I felt that was a way to contribute to the long term viability of the project.
I'm not immediately upset about the licensing change - I get the need to protect from low effort/value add reselling and things like that. I do still worry if this is a canary for future changes that run counter to the reasons I migrated to bitwarden in the first place (open, robust, trustworthy).
Counter to many other commenters I personally prefer bitwarden over 1password, and certainly over lastpass and roboform, etc.
My only gripe is having to unlock the desktop app separately from the browser extension, which after adopting the ssh agent functionality became kinda annoying.
I missed out on an event recently because it was full. I got a notification that a spot had become available shortly before it started, but I had an hour travel to get there so wasn't viable.
I think tools to enable better discovery are a good thing, but I'm not sure that I like the idea of splatting RSVPs just in case.
I started with plain wireguard then migrated to tailscale, for my use case:
- I was able to get my partner onto the tailnet by telling her to install an app and login. She doesn't know or care what wireguard is, but she can now access some of my self hosted services on her phone.
- I'm able to easily dynamically register machines to the tailnet, such as CI jobs
- I'm able to self host a DNS resolver and have it just work for devices connected to the tailnet
I'm sure I could achieve these goals with plain wireguard, but I feel like I was able to outsource significant complexity to tailscale instead.
I followed a similar trajectory for similar reasons. I was playing with wireguard around 2020 when I learned of Tailscale and since then haven't looked back.
Just the other day I was able to set my sister up with access to my Plex server and the ability to piggyback on my UK internet connection to stream BBC/Channel 4 content from Australia. It took all of 5 minutes to get it working.
Same trajectory, but I've now migrated a lot of my previous tailscale stuff to Cloudflare tunnels -- it opens up the attack vector a _little_ bit (that can be mitigated) and it's app-free (which made it viable for a lot of my non-tech users). Still love tailscale and use it all the time for remote access to very sensitive stuff (ssh).
Interesting. I've obviously heard Cloudflare tunnel, but haven't looked into beyond knowing that it exists. Was going "app-free" the primary motivator in your case for the switch?
I have a few services I've configured static routes for on my router (so my wife can access them without needing to have her phone connected to Tailscale all the time), but other than that it's never been much of a pain point.
Yeah, the app-free nature of tunnels was a huge draw. Cloudflare does effectively MiTM your traffic, so that's a risk you have accept but the tradeoff was worth it for me. Between that an the secondary authentication you can put in front of your services, I felt much better about opening my self-hosted stuff to to relative 'public'.
What are people's thoughts/experiences about dual licencing?
Eg: is there a clean way to dual license such that hobbyist, and exploratory work (eg: a proof of concept done in a commercial setting) are allowed, but using it in production requires a fee?
If you've done this, has it been successful? Obviously there's been many projects relicense over recent years (terraform, redis, etc) - but it's less clear to me if this is a viable path for new projects starting out, or if it just kills adoption from the beginning.
I think it definitely hurts adoption. No hobbyist or experimenter wants to delve into legalities head first by first having to understand the licensing terms of software, whereas permissive licenses like MIT and Apache 2.0 are easily-understood and familiar.
The solution is probably to be more selective what you're open sourcing if you're planning to build a business. And what you open source, you do it under a permissive license so people don't feel limited should they wish to play around with it.
A more restrictive license might be more apt if you don't really want to open source, but you must for regulatory reasons.
Will hobbyists and experimenters that has no interest in understanding licenses go out of their way to locate specific licensed code, or are they more likely to just ask the AI/agent to cobble together stuff without care of any licenses?
"The solution is probably to be more selective what you're open sourcing if you're planning to build a business."
Fully agree, FOSS maintainers are - in the grand economic scheme of things - beggars high on altruism. The whole model of FOSS from the position of a non-corporate sponsored developer was already broken and with the advent of AI is now most probably broken beyond-repair. Buy-me-a-coffee with a <0.01% hit rate compared to open feature requests/gh issues on some of the more popular projects out there, all while companies like atlassian - using FOSS to run their business on for free - can charge 50k EUR for a single 1h migration call. Time is the most valuable resource one can waste, something you get to realize once all the mental gymnastics wear off(either by itself or due to less fortunate life situations)
Excuse me but as both a hobbyist and commercial software developer I say that the gpl (any version) is quite simple enough. There is no need to go all the way to bsd/mit just to get safety and clarity and freedom from encumberance.
The only people who avoid gpl and talk about mit as being the only safe option, are exactly the people no one should care about. They are the people for whom free isn't free enough, and they must steal even when it's already free.
That is not "adoption" anyone needs to care about.
right but the GPL explicitly allows commercial use, which isn't what the original comment was about ("use in production requires a fee"); i agree with the previous comment that such a license is hard to assess for a hobbyist, but the GPL is not such a license (hence yes it's simple enough)
Even though it's technically allowed, a lot of companies are afraid of it. Not GPL2 - that's used a lot, because tivoization lets them ignore the spirit of it. But they fear GPL3 and AGPL.
You can also just do a crayon license. "All rights reserved, noncommercial use allowed." Nobody's stopping you. If and when Debian wants to ship your package, ask them for proper legal advice about changing it, they have lawyers.
Companies that make physical products are afraid of GPLv3 because of the anti-tivoization clause. Cloud companies aren't, but they're afraid of the AGPLv3, because of the anti-cloud-tivoization clause.
In practice AGPL might achieve that. It does allow commercial use, but a lot of big businesses, especially big tech, will not use it. On the other hand it is a clear, OSI approved, FOSS license.
Well, the language is clear enough. What's not clear are the implications of the language. And, honestly, the sensible default for a lot of companies is just not to go there. And big companies tend not to operate on hopes and prayers to avoid distracting and expensive lawsuits. Without going into details I have enough familiarity with the space to know that a lot of open source-friendly companies either avoid AGPL entirely or discourage its use.
Yes. The clean way is to use the strongest copyleft license you can find, probably AGPL. Even if corporations are technically allowed to use it, they don't want to risk touching it with a three-meter pole. Then you offer to sell them a different license. Hobbyists and OSS folks usually have no issue with AGPL.
Do you have data on that last bit, or just a guess? As a hobbyist and OSS developer I treat AGPL as a rabies infected animal. I may have uses for it, but I'll keep it EXTREMELY segregated from everything else.
This means you have only solved the problem for large companies, and specifically those who have money and who have a functioning procurement system that's developer-driven. Which is a very narrow use case.
Again, that only works for large companies, and for companies that can exists even if their service is downloadable.
Which fine, you can choose to take that political stance. But that's a stance of "I want to change the world to my liking", not "I want to help the world/people".
Up to you, of course, but I prefer to help not only large companies.
Sure, but for anything except large companies it has a bootstrapping problem. I'm absolutely not going to use AGPL software in a test one-person trying to sell a service kind of deal. So if it takes off, I'm already on a non-AGPL stack, so why reach out at that point to get a commercial license for software I don't even use?
And hell, even without money involved, I'm not going to make a hobby project with AGPL software either. Not only may I have small parts of the project I've not opensourced, but AGPL is untested in how far the virality goes. Are my backup cronjobs in scope? I certainly don't want to be the test case for this. Even if I win against an AGPL troll, I'll still lose.
If you are trying to monetize your software, the biggest factor is whether or not your customer trusts you.
MIT and source out on GitHub is the easiest way to build trust. You will find that some people simply "steal" your work in this arrangement, but much like with movie piracy I don't think they ever intended to compensate you or anyone else.
So, we wind up alienating all potential customers because we are so worried about preventing ideological crime.
People will steal your ideas and they will get away with it. The more you react to this in first order terms, the more it will destroy you.
Most money in software is made with support contracts, not the initial sale.
After many years of thinking about this, I have arrived in the exact same place. I think the SQLite team learned this in the early days, and have done very well for themselves, giving away all of their source code for the product itself, free of charge, and then having folks pay for consulting and enhancements, which they remain particularly strong at because of their closed, comprehensive regression test suite.
>MIT and source out on GitHub is the easiest way to build trust. You will find that some people simply "steal" your work in this arrangement, but much like with movie piracy I don't think they ever intended to compensate you or anyone else.
You've chosen the license which allows "stealing", why did you do that if you don't like that? Nobody forced you to do that, I hope.
How can I trust the person who published their code with the strict legal terms, but becomes sad when other people use their code exactly as the author said it could be used?
Every once in a while I read discussions about licenses, and puzzled every time why the author of the software chooses free license when the freedom of copying and distribution is seem to them as pirating. If the license is not suitable for you, why choose it?!
Licenses are about legal possibilities. You're looking for social/moral terms instead if I understood you correctly (something like CoC).
How does MIT build any more trust than a copyleft licence like AGPL? At the very least AGPL stops people "stealing" your work without contributing back their changes?
AGPL does not do anything to force people to contribute their changes back. They have to make the changes available, however that's very different from actually contributing back. It is not hard to make a low quality contribution that the upstream would for very good reason refuse even though it 'works'.
The poster child for this is chromium which is GPL because it has clear and obvious roots in the old KHTML code of 20 some years ago. In theory you can contribute to Google movement and I suppose some people do but realistically Google controls it completely and they will do whatever they want. even though the source is available it is effectively not a contribution back.
By "contribute back" I was referring more generally to the commons.
The chrome example actually proves my point, the KDE project, or anyone for that matter, can take the changes Google made to their code. If KHTML was MIT it's likely that wouldn't be the case
Practically though, there is no difference. The KDE project has lost control over the web browser, even though they started it. It's an all or nothing. They can take all of chrome or they can take nothing. There is no in between. If KDE and Google disagree on the direction of the web browser, Google wins. There is no control. There's no advantage to open source, other than it's free. It may as well be a closed source project for all the good it does.
You can't be stealing what is given away for free.
Developers that choose copileft license want to see al changes shared under the same license.
Developers that choose permissive want their code to be of use to as many developers as possible for whatever they want to use it for.
I like the AGPL but don’t often use it. (I did recently license two coding harnesses I wrote as AGPL.)
A long time ago, I didn’t mind huge tech companies getting rich partially via open source, now I do. In the USA the collusion between government and big tech is starting to smell a little bit like fascism. Sorry, I have only complaints, not any good answers.
>A long time ago, I didn’t mind huge tech companies getting rich partially via open source, now I do.
Is the concern that anybody will be earning money on your software (just that), or that you won't get any money, or that they will earn money and don't give back the code?
If the company earns money and opens the code, is that OK for you?
Just for you and for everyone information, Richard Stallman himself told people not only to sell their own software, but the software written by others as well!
> Actually, we encourage people who redistribute free software to charge as much as they wish or can. If a license does not permit users to make copies and sell them, it is a nonfree license. If this seems surprising to you, please read on.
AGPL, just as all other GPL, does not prohibit selling the software. If you goal is to make your software unsellable, please use your own licensing terms (there's nothing wrong with that!!!)
> Eg: is there a clean way to dual license such that hobbyist, and exploratory work (eg: a proof of concept done in a commercial setting) are allowed, but using it in production requires a fee?
Yes, it's called language. Contracts are nothing but text, so why don't you just write down what you think should be the rules around using your software by other people?
I get the urge of a lot of developers to pick an existing third party license from the shelf, but just as you can write your own code - and are not required to use ready-made libraries/frameworks - you can write your own open source license for your software.
It stops companies from building high-revenue products for free, while not being as scary as AGPL/LGPL from the business perspective, and completely unrestricted for everyone else (despite not being technically an open-source license).
Once you decide on a non-free license, in the FSF sense, in the DFSG sense, and in the open source sense, does the details of the license matter much? You want as many people to pay as possible, and you do not wish for others to compete with you providing this software.
It's pretty much a standard non-free commercial license, which exact wording will matter only to purchasing department of your customers. It will be inconsequential to the broader open source community. Literally thousands of those exist and the specific wording matters very little.
It doesn’t have to be binary. A license like this allows for 99% of the personal and commercial use that a project will ever see, while giving the author leverage over large corporations - which is the main gripe people have. It is not ideal for libraries or things that would be redistributed, but then you have other options.
Some things in life are binary. You either allow people to build new products and businesses on your work or you don't. Would you allow me to extend the product with new features? "It depends" is a form of "no". It is not a position to sustainably work from.
If you frame the licensing space as for either personal or commercial use, perhaps your point of view makes sense, but this is not a useful framing for most people, and it is specifically not something the open source community cares about.
If you wish to keep leverage over others then you do not wish to have them compete with you on the same product. That is a valid position to have, but it is squarely on the non-free part of the licensing spectrum. You don't want to play within the open source community and they don't want to play with you. All anyone owe others is to make that clear.
This is why open source is rapidly becoming obsolete ;) There have been source-available/fair source/whatever-you-name-it approaches before.
They were attacked by OSI zealots every time because it's not real open source. Which is true, but the unsaid - or well, only sometimes mentioned - other half is that these open source enthusiasts would you rather have a bog standard all-rights-reserved commercial licence than a relatively open licence without the four freedoms!
I can't claim to read other people's thoughts, but my hunch is that this happens because it's too "close" to an open source licence so they view it as competition, while they view commercial software as either a straightforward enemy or they don't care about it whatsoever.
The history aside, this approach just makes the open source community more and more irrelevant each day, especially with the advent of "vibecode your own dependencies up". The 4 freedoms come from a place where they were about users, but gigantic corporations have shoehorned themselves into being users, and instead of the community defending against it, they think the freedom to exploit the maintainers' work while contributing nothing back is more important than keeping the commons free and shared. :P
The freedom to host open-source software is more important than contributing back to the original project: it's where the actual value of open source comes from. Would you host your website behind Apache or Nginx if you couldn't just switch providers and keep the same web server? Would you ever pick up Postgres or MySQL if you couldn't actually pay a company to host that for you, knowing that if they screwed up, you could switch to a provider that did it better?
From a pure engineering reliability perspective, coupling your technology choice to your vendor gives that vendor too much leverage (as we've seen with, for example, VMware).
This isn't about defending the big companies at all. It's about defending the right of hosting providers to compete on hosting a variety of software. In the alternative world of entirely commercial licenses, or entirely BUSL-styled licenses, you would be shackled to the specific vendors that happened to create the technology that you wanted to leverage. This is a scenario where the customer invariably loses.
Let's not get everything mixed up here - I singled out BUSL exactly because it does not prevent competing services, especially at small scale. In fact it would encourage small business and individual usage vs big cloud providers. It also has a conversion clause, so worst case scenario you have a slightly outdated MIT-licensed release to pick up from.
The EUPL the author mentions, the AGPL and others are the ones that directly prevent competing services.
That said, indeed it might not be an ideal choice for that kind of cloud-hosted software if you want to maximize adoption.
> The EUPL the author mentions, the AGPL and others are the ones that directly prevent competing services.
To support sibling comment: no it doesn't?
But your point about the revenue cut off in the BUSL is worthwhile (assuming we're talking about a licensor that is leveraging the additional use grant). I just disagree that it's a remedy because it basically punishes a business for being successful, by changing the rules upon which it was built. I'd be very curious to hear of anybody who has licensed software under the BUSL and has ended up getting a license from companies that meet those revenue thresholds.
It's worth noting that the BUSL, by default, with no additional use grant, prohibits the use of the software in production. So I actually think you have the two licenses reversed. The BUSL prohibits production use and competing services by default unless an additional use grant is specified and then it is only allowed under the revenue threshold specified in the additional use grant.
The AGPL has no prohibition whatsoever on the deployment of competing services.
It is expected that you use the license with an Additional Use Grant. For example, Hashicorp says:
> You may make production use of the Licensed Work, provided Your use does not include offering the Licensed Work to third parties on a hosted or embedded basis in order to compete with HashiCorp’s paid version(s) of the Licensed Work.
Or, for a revenue threshold:
> You may make production use of the Licensed Work, provided that your use is solely for an application or system developed or operated by an entity (including its affiliates) with total annual gross revenues of less than $10,000,000 USD.
That is the whole point - you can define your own limits for commercial usage, while keeping the rest of the license text unchanged.
The AGPL's "viral" property inhibits competition without prohibiting it - companies are just scared of accidentally becoming liable to publish private software sources. As far as I know, that's the reason it is banned at Google, Apple and other major companies [1].
That didn't stop AWS though, which is why we now have SSPL and the BSL.
I think we're agreeing, but you seem to be spinning things:
1. BUSL does not allow production use. Additional Use Grant (optional) is necessary to allow this, and is typcially accompanied by a revenue limit, setting a trap for any business that attempts to use it by changing the rules as they become more successful.
2. The AGPL does allow production use, by default, forever, but requires you publish associated source code when providing the service.
Only one of these licenses bans production use, and that's the BUSL. It can be modified to allow it under certain circumstances, but your original statement, that BUSL allows production use and AGPL prohibits it, is exactly reversed.
At its core it's a question of control. If I use this library or app, will I be safe? Will I be able to repair it, use it in the future, pay someone to fix it? Will it still be developed in a few years?
FOSS is a great answer to the first few questions, but it fails at the last one. As a user, yes, I would prefer a cloud-protection license, if it means that software will still be developed in a few years time. It's not like I want to use this software to compete with the author, I'm happy not to be allowed to do that.
Well, there's no guarantee that there will be sufficient market in a few years for that software development to continue unless you fork it and do so (or pay to have done) yourself.
Yes, you would be allowed to extend the product. There is no 'it depends', the license is quite short and clear. You have to acquire a commercial license once you go over the revenue threshold, that is all.
I find this much simpler to understand than AGPL/LGPL or the linked EUPL.
You might also be interested in the O'Saasy license (https://osaasy.dev/) which is in the similar vein, but simpler.
HashiCorp switched to BUSL license for their products/tools when they already had substantial market share, and they still faced MPL-licensed forks (Terraform -> OpenTofu, Vault -> OpenBao). It will be interesting to see in a few years if those tools notably cut into their share.
I'm not sure a new tool with a BUSL license will get adoption as easily.
I'm sorry - what I meant to say is that it is listed in the SPDX (https://spdx.org/licenses/BUSL-1.1.html) as a recognized license. The revenue gate means it will never be considered an open-source license by the OSI.
I was a bit surprised to read that there was an OSI-approved license with usage restrictions and wondered if I had missed the memo. But you seem to be correct and it's not OSI-approved and therefore is not generally considered to be an open source license.
Good points, the second is very "dual-licensing" in nature. BUSL is certainly the more "mature" option and there's a higher likelihood people came across it in the wild.
The heat around this particular issue has cooled down a bit and I'm not sure anyone is especially happy with the state of affairs. But questions around AI have sucked a lot of the oxygen from the room for now.
This framing ignores the fact that many people pick up technologies because they want to be able to switch the vendor that is hosting it for them. If I'm hosting a LAMP stack from some shared hosting provider, it's easy for me to just move to a different hosting provider because all the software is open source and anybody can host it. This falls apart when companies choose the BUSL, which is why it's not considered OSI open source.
Isn't that what Epic, MiniMax, Z.ai, and others are doing, where a license is free for personal use / low revenue projects, but cost a (steep) fee for commercial use? They don't use dual licenses, but rather a tiered license.
You're basically describing open core. It's hard to get the balance right. Give too much away for free and people won't buy your full product. Give too little away and they can't really properly evaluate it.
Does anyone know what the impact on prompt caching is?
I like the idea of dynamic tool/skill sets, but wonder if it needs to be part of the new session workflow where you would choose a group to activate rather than this dynamic.
One of my primary use cases for tailscale/VPN is that I can happily run stuff (grafana, gitea, etc) and not have to be panicked about monitoring for CVEs - I serve it all over HTTPS but I don't want to put it on the public internet if I don't need to.
I just have envoy proxy with the oauth + jwt filter in front of those services. Envoy does the oidc flow with pocket-id so I can use passkeys for authN. Envoy validates the resulting token and does authorization via ACL. Envoy then sends an authorization bearer jwt with the oidc id_token jwt to the backend (for example grafana). Grafana parses and validates the jwt and sets claims as userinfo (username, groups, email).
I think such setups are at least as secure as having tailscale in front of it and they are web standards conform. I dont need a client app like tailscale, I can just use my normal browser and internet conn.
I always make sure envoy/all other apps are on the latest security patcb anyways.
It's funny you say that, as one of my weekend projects today is setting up https://www.authelia.com/ to achieve the same.
I probably won't allow everything through it (eg: postgres, clickhouse etc can stay on tailscale), but I've been stumbling into use cases where I want to share things with friends or colleagues, and I don't want to put them on my tailnet.
Through my weekend experiments, I've found I can get way better outcomes, and an order of magnitude less cost with my slapped together sandboxed omp setup plus ZDR openrouter models (DeepSeek, Kimi, etc) than I've ever seen from Claude Code at work.
Everything is version pinned and a deliberate choice to change, and a git revert away from changing back.
TBF the models may change underneath me to some extent still, but the cost benefit of running them myself doesn't pan out yet (for agentic coding at least, don't have enough local vram to get a usable context window and generation speed, self hosting on runpod or similar isn't economically sensible for my current consumption though I have tinkered with it)
I think the key part is about aligning incentives and outcomes - if your security and compliance departments are only judged on "were we breached, did we pass our audits" then there's a risk they won't weigh the tradeoffs associated with the decisions around controls implemented to achieve those outcomes.
To use a ridiculous extreme you can't breach a web app that isn't exposed to the internet, but the users can't access it either.
If you can connect/balance those goals to other metrics around cost and productivity, usability, and a realistic threat model, as guardrails then you incentatize cross-team collaboration to achieve the shared org outcomes.
As a developer, I quite like monorepos to a certain size (eg: until they get big enough that the tooling we typically use outside of big tech starts to fall down).
As an AI, I'm not sure that I care? I'd guess that context management can actually be easier if each microservice has a well documented API (openapi/graphql/grpc/asyncapi/whatever) and you provide the agent harness the ability to drop into each polyrepo as required (and give it the ability to access said documentation).
The tedium of making branches / commits / pull requests across 6 repos to land a feature is less problematic to an agent.
Admittedly the way I'm using agents at the moment is more repo orientated where it's sandboxed to a single repo, but conceptually I think polyrepo microservices could end up being a sweet spot.
> The tedium of making branches / commits / pull requests across 6 repos to land a feature is less problematic to an agent.
You're probably not using your microservices correctly if you need to change more than one service at the same time. The whole point of microservices is independently developing and deploying the services. Sweeping changes like that should be done in pieces, one service at a time.
Which is why microservices are best for larger organizations, because it reduces coordination between dev groups.
if service A calls service B, and service B adds a new endpoint, or a new optional argument, service A needs an update to take advantage of it
if a library is used by multiple services, and gets an important bug fix, each service using the library needs to update to get the fix
these are sequences of changes, not literally at the same time or requiring deployment coordination, but when this happens a lot people start asking about monorepos
You have to make the change to service A and B, and then test both and deploy both. You haven't saved any time or effort in a monorepo.
A library needs updating, you still have to update it and then test and deploy every service that relies on it independently. Again you haven't saved any time or effort. In fact you've made it worse, because if those services are maintained by different people, you just forced them to test and deploy on your timeline and priority, not theirs. You actually made the coordination problem worse.
I haven’t worked at a Big Tech monorepo place, but I hope/assume that in the service dependency case, you would touch both in one changeset and the deploy tooling understands the dependency tree and orders the deployments correctly. Without that i agree its the polyrepo approach just with all PRs in the same repo instead of multiple.
In the library scenario, I know tooling like bazel ensures that’s one changeset, not 3+. Tests run for both the changed library and all consumers of it in the same pass. You’re right that it might loop in others for review who weren’t expecting it, but i think that’s the same in a polyrepo approach.
The big thing about monorepos in this case is making a change atomic across a set of projects. Multirepos can't do this 99% of the time and often add a lot more procedure to something close. It's inherently async.
> The big thing about monorepos in this case is making a change atomic across a set of projects.
The thing microservices is supposed to solve is eliminating the need to make atomic changes across services. There is an inherent overhead in doing that, like making your service support both new and old APIs as long as any service exists using the old API. This is the cost of microservices.
The world isn't just backend. There are mobile projects, games, native desktop apps which act together as a suite and web frontends. Also microservices bring up their own host of issues and extra labor. Both are essentially the semantic versioning library update problem, and when you need to propagate a breaking change it create a whole bunch more labor that is significantly reduced in a monorepo vs. a multirepo/microservice world.
The tradeoff is you need to invest into repo scaling, much like a backend service that needs to invest in scaling itself too.
Why not both? Driver-less (or even just with drivers) mini buses, without fixed stops and dynamic routes/stops based on demand.
I guess you don't want to stop more times than needed, so maybe you'd want to cluster the demand somehow into "virtual stops", and you may lack some amenities like shelters.. so maybe the traditional bus route is good enough. Though it feels like it's ripe for optimisation (you know the classic no buses come for 30min then 3 arrive at once, or these buses are all full whilst others are roaming empty)
I'm not immediately upset about the licensing change - I get the need to protect from low effort/value add reselling and things like that. I do still worry if this is a canary for future changes that run counter to the reasons I migrated to bitwarden in the first place (open, robust, trustworthy).
Counter to many other commenters I personally prefer bitwarden over 1password, and certainly over lastpass and roboform, etc.
My only gripe is having to unlock the desktop app separately from the browser extension, which after adopting the ssh agent functionality became kinda annoying.
reply