It should only apply to clients, but we could have a best-case criteria that also applies to servers.
I think from a pure privacy perspective source-availability should be sufficient.
Why YubiKeys arenât open-source:
Why 1Password isnât open-source:
Open source is better. With a source available model, people wonât be as incentivized to look at the code since they canât use it for their own purposes, while itâs the opposite with open source e.g. vaultwarden devs probably monitor a lot of changes in the bitwarden code. It will have more eyes looking at its changes this way.
The thing is that we actually do not. We list open source as a requirement for a few things, but we have never exactly esthablished what that means.
This is because Open source means a lot of different things for a lot of different people, which is what that discussion is for.
In any case, it looks like we will be following the OSI model, but is has not been decided yet.
At the time your post here said âOur definition of Open-source follows the OSI definitionâ but I see that pull request was recently closed.
If the project wants to evaluate whether the open-source criterion should be changed to source-available, that is one thing, but it makes little sense to change the agreed-upon definition of open-source (not to mention the confusion it would cause). Even projects like FUTO accept the OSI definition of open-source and instead market themselves as source-available or source-first.
Again, we never had defined definition, which is what that thread is for. It came to light because of running issues with existing youtube clients in comparison to GrayJay.
And as an added note, nothing is official until its live on the site. 
I was only referring to the same topic that you originally linked. While I admit I was incorrect in saying that PG already had an agreed-upon definition of open-source, in practice, the OSI definition has been the de facto definition.
Regardless, open-source is a word and PG is not a dictionary; the OSI definition is already widely recognised. If PG wants to abandon requiring open-source in favour of source-availability, that is a different question entirely.
I donât think its a great precedent to just claim something is de facto to sidestep a conversation you rather not have in a rush to create a criteria with no clear benefit. If you want the OSI definition to be the definition PG uses as its standard, get it approved.
Otherwise, there should be a discussion and agreement of what is meant by open source (if thats the term people even want to use) in terms of this criteria before its even considered to move forward.
Well letâs just mini analyze the current case for the recommended password managers that are not open source and they are on the list.
1Password
The product even as an online closed source password manager has endured in time. But it is and will probably always be an online closed source password manager. Only by that definition nobody will be surprised if something like what happened to LastPass happen also to 1Password.
There are plenty online open source alternatives with good reputation already like Proton Pass and Bitwarden that keep listing 1Password makes no longer sense.
Strongbox
Thatâs an one-man freemium project which source isnât available to build the app, even some parts are posted on their GitHub page.
Only because of that, should mark the project shady.
The only reason is it listed it is because of the iOS + macOS support, compared to the real open source iOS password manager KeePassium which is also lately got audited by Cure53 that doesnât have macOS support.
Though, they both are using the KeePass protocol that it is cross-platform so it makes no sense to list an inferior password manager. (KeePassium with KeePassXC for iOS-macOS combo is more than enough for example)
Lastly about the talks to divert the topic of requiring also open source for hardware keys and what is the real meaning of open source is just whatever.
Hardware keys are already in another section of the guide, they can have their own criteria as long as there are not enough options at the moment.
And trying to solve in this thread the meaning of open source, just to keep a paid online closed source password manager and a shady freemium password manager on the recommendation list is just absurd.
As i have repeated above PG, as in the Team, has not made a clear decision yet on what definition we will follow, this is why that thread is created, currently it is to vague, which is the problem we are now trying to fix.
I know that this thread and that thread have different purposes. Its why that thread has to be complete before this one, in my opinion, as we already have an issue with requiring opensource when we have never defined what that means in the first place, which is problematic.
Wasnât me, lol.
Itâs been concerning how many people in this thread refuse to see this as problematic.
I will try and respond to the benefits you listed but, it seems like the point of these benefits, in this context, have been lost. I am questioning the benefits of why open source should be a criteria for password managers, not the benefits of open source in general.
Not sure this should even be considered a benefit. There are still so many challenges in the way for this type of âcontinuityâ to be successful that it makes the benefit improbable, including loss of expertise, fragmentation, and lack of financial support.
This is why audits are already a criteria.
You say this like there isnât a massive expertise gap for the majority of users preventing them from realizing this benefit. This benefit is also a double edged sword, the availability of source code can create a false sense of security, potentially leading to less rigorous internal verification processes.
I donât really think thatâs fair to say. Thereâs not any reason software developers would suddenly stop caring about security just because something is open source. They donât even need to take contributions if they donât want to.
I did not say there was. The issue isnât a lack of caring, the issue is a false sense that âif we do slip up, the community will catch usâ which can lead to less rigorous verification. Which I think is fair to point out. I think this attitude is very prevalent in the open source community, that nothing bad can happen with the code because the community is always reviewing it.
Well thatâs why we require audits from reputable third parties. Which are much more important than the product being open source.
/me Points frantically in the direction of Heartbleed
Which I pointed out.
Which goes directly to my point that