The SDK is not closed source, you can find the source here: https://github.com/bitwarden/sdk

It might not be GPL open-source, but it is not closed either.

Sure. To me “source available” is still closed-source, since looking into it might give companies an attack surface for you to have violated their copyright in the future. Happened with IBM in the past: https://books.google.de/books?id=gy4EAAAAMBAJ&lpg=PA15&pg=PA15&redir_esc=y#v=onepage&q&f=false

Let’s wait and see before we get out the pitchforks.

Sure. Bitwarden doesn’t owe us anything, but it is still sad to see this decision and better clarification and explanation could have alleviated the breaking of the trust here.

So you meant to say:

I would go as far as to say that Bitwarden’s main competitive advantage and differentiation is that it’s source is available.

That is not true, there are a lot of other password management software out there where the client source code is either open source or source available. For instance keyguard: https://github.com/AChep/keyguard-app?tab=License-1-ov-file#readme which is an alternative proprietary bitwarden client, where the source is also available. Also the Proton Pass client is under GPLv3.

I would argue that the main advantage of bitwarden compared to others is that it is open source and has an open source server for self-hosting (vaultwarden). Which of course makes it difficult in terms of business strategy with their VC funding. But maybe becoming a non-profit org and getting money from donors, the strategic funds of EU and other governments, etc. might be an alternative way.

Ok, lets take it step by step:

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

I think they meant executable here, but that also doesn’t matter. If both programs can only be used together and not separate, and one is under GPLv3, then the other needs to be under GPLv3 too.

• code for each program is in separate repositories

How the code is structured doesn’t matter, it is about how it is consumed by the end-user, there both programs are delivered together and work together.

• the fact that the two programs communicate using standard protocols does not mean they are one program for purposes of GPLv3

The way those two programs communicate together, doesn’t matter, they only work together and not separate from each other. Both need to be under 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.

Not being able to build a GPLv3 licenses program without a proprietary one, is a build dependency. GPLv3 enforces you to be able to reproduce the code and I am pretty sure that the build tools and dependencies need to be under a GPLv3 compatible license as well.

But all of that still doesn’t explain what their goal of introducing the proprietary SDK is. What function will it have in the future? Will open source part be completely independent or not? What features will depend on the close-source part, and which do not? Have they thought about any ethical concerns, that many contributors contributed to their software because it under a GPL license? How are they planning on dealing with the loss of trust, in a project where trust is very important? etc.

None of that makes Bitwarden not open source.

Yes, it does, because it violates its own license GPLv3 by having proprietary build-/runtime dependencies.

If it was under a different, maybe more permissive, open source license, then maybe it would still be open source, but as of right now i likely breaks its own license terms.

Not only that, they specifically state this is a bug which will be addressed.

From what they state, they think that because executables that share internal information via standard protocols does somehow not break GPL3 terms compared to two libraries that share internal state via the standardized C ABI which does. And they seem to not consider that a bug, just the build-time dependency.

Well, then it would be nice to hear from them an explanation on why they decided to violate the GPLv3 on their client, by coupling it with proprietary code in a way that disallows building and/or usage without that proprietary component.

They would be insane to change that.

Yes. And i hope that they recover from it soon.

I would say a proper explanation includes the goal you want to achieve, not just the statement that you think that you are allowed to do something.

That “explanation” is unsatisfactory and likely wrong: https://www.gnu.org/licenses/gpl-faq.html#MereAggregation

So they either have to license their SDK under a GPLv3 compatible license, or switch the license of their client to a non-GPL one.

Their “explaination” only mentions why they think can do it, but not why they are doing it.

An interesting concept would be if all hand on the 12 clocks would work, but the hands of the clock in the middle are stuck at 12 position, this way the hands in the middle would point to the clock showing the correct time.

So similar to kakoune? I tried that for a while, but it was missing some features so I went back to vim/neovim.

I need to know vi anyway, because that is available everywhere (as part of busybox), so using vim/nvim for bigger systems just fits.

What about Lua/Luajit?

In most scripting languages you have the interpreter binary and the (standard) libraries as separate files. But creating self-extracting executables, that clean up after themselves can easily be done by wrapping them in a shell script.

IMO, if low dependencies and small size is really important, you could also just write your script in a low level compiled language (C, Rust, Zig, …), link it statically (e.g. with musl) and execute that.

So generally the pro of coreboot is that it is open source, but the con is that it is open source.

What I mean by that, you can fix any issues yourself, however, if you are unable to do it yourself, you have to wait until someone does it for you and often what features are available and stable are a hit and miss.

Compared to proprietary bioses, the company has some kind of standardized process for developing the bios. So you often get want you would expect. However, if the money flow from the pc vendor to the bios vendor drys up, you, or the community of owners. will not be able to fix any issues.

Linux support should be the same, regardless if you choose proprietary or open source bios. But that depends on how well the coreboot was ported to the platform. So officially supported coreboot bioses are likely better than others.

Personally, if all other attributes are equal, would go with coreboot, because I like to support vendors that offer that choice, and IMO a open source solution, that you can review and build yourself is intrinsically more secure than a binary blob, where you have to blindly trust some corporation. But other security minded people might disagree, which is fine.

Check if you find anything about this in the kernel log (dmesg).

Well, the issue with that is that achievements are global over all playthroughs, so it doesn’t really work as a checklist.

Sure there are some interesting achievment, like the Stanley parable ones. For instance: ‘Go outside: Don’t play the game for 5 years’ (https://thestanleyparable.fandom.com/wiki/Achievements)

I only play single player games, but couldn’t care less about achievements. It is all about exploration, story, game mechanics and modding for me.

People treat achievements as if they are a status symbol. I mean sure, if you don’t know what else to do in a game, they can give you some goal, but IMO the game itself should encourage you to reach the goal, not some external badge. The experience doing the task should be the reward in of itself.

Not the drama itself should influence your judgment, but how they will deal with it.

Whenever people work together on something, there will be some drama, but if they are dealing with it, then that should be fine.

Nix and NixOS are big enough, that even if it fails, there are enough other people that will continue it, maybe under a different name.

Even it that causes a hard fork, which I currently think is unlikely, there are may examples where that worked and resolved itself over time, without too much of burden on the users, meaning there are clear migration processes available: owncloud/nextcloud, Gogs/Gitea/Forgejo, redis/valkey, …

As I said, it is not impossible to move away from gh compared to many other cases in other industries, just that it is more difficult than necessary because vendor-lockin is allowed.

If vendor-lockin was illegal, companies had more incentives to use established or create new standards to facilitate simpler migration between software stacks, without changing the external interface.

For instance allowing your own DNS name to be used as the repo/project basepath instead of enforcing github.com, Allowing comments, reviews, issues and pull requests via email or other federated services, instead of enforcing github accounts to do so, providing documented, stable and full-featured APIs for every component of their software, so that it is easy to migrate and pick and choose different components of their while stack from possible different vendors, …

There are so many ways that would improve the migration situation, while also providing more ways for other ideas to compete on a level playing field. If a bright engineer has an idea for improving one component from github, they should not be required to write a whole separate platform first.

Well the reason for that is the vendor-lockin and centralized technology.

If your project for instance uses a similar development method as the linux kernel does, e.g. sending and reviewing patches via mailing lists and providing url to push and pull git repos from, it is quite easy to switch out the software stack underneath, because your are dealing with quasi-standart data: Mbox, SMTP, HTTP(s) and DNS. So you can move your whole community to a different software stack by just changing some DNS entries and maybe provide some url rewrite rules without disrupting the development process.

I am not saying that the mailing list development process is the right one for every project, but it demonstrates how agnostic to the software stack it could be.

If vendor-lockin is made illegal, the service providers would have more incentives to use or create standardized APIs, so that their product can be replaced by competitors. So switching to or from github/gitlab/… becomes easier.

It has more than you expect, if your project is established on github and want to move away you have to deal with:

• migration of issues
• migration of pull requests
• migration of all review comments etc
• migration of the wiki
• migration of the pages
• convince all contributors to possible create a new account somewhere else
• changing of the project urls. I don’t think github offers a url rewrite service
• forks on github will not have the new destination as the fork base
• change the ci and release process
• because you cannot add url rewrite rules to your old gh project, you might need to only ‘archive’ the project there with manually written text, to point to the new destination, for people to find it

You don’t know what a “monopoly” is.

What the author is probably searching for is “vendor-lockin”, which is an anticompetitive practice for so long that it became the way many companies rely their business on. It favors established products over new-comers by making switching offerings difficult/expensive or even impossible, thus better products often have no chance of competing in a field, that was dominated by a single supplier for a while.

IMO there should be strict regulations and high fines associated with it, because it hinders innovation massively across all industries.

The cost of switching away from github for a project is high, but not as high as in other fields.