I think the definition of FOSS used here is tendentious: some of these projects (which I have no particular attachment to) are marked as "not FOSS" or "issues exist" because they have components that are disconnected from the basic nature of free and open source software itself.
A recurring one here seems to be that proprietary builds somehow make a project not FOSS. But this is how it's always worked: Red Hat doesn't sell FOSS source, they sell a subscription to a distribution (RHEL) that includes managed, maintained builds. That distribution is in turn restricted[1], while the source behind it remains free.
Perhaps there's an argument to be made that the definition of FOSS should be stronger, and should include some kind of binary freedom, lack of trademark restrictions, etc. But that's not how the term is conventionally applied, and glossing over that convention seems roughly as contentious as when companies try to split the baby and rewrite "open source" to include anti-competitive terms.
In those situations, could someone easily just fork the project, offer builds, and now their version of the project is ideal? If it's easy to do that then it seems like a good ideal. If it is difficult to do then their right it is an 'issue'.
A recurring one here seems to be that proprietary builds somehow make a project not FOSS. But this is how it's always worked: Red Hat doesn't sell FOSS source, they sell a subscription to a distribution (RHEL) that includes managed, maintained builds. That distribution is in turn restricted[1], while the source behind it remains free.
Perhaps there's an argument to be made that the definition of FOSS should be stronger, and should include some kind of binary freedom, lack of trademark restrictions, etc. But that's not how the term is conventionally applied, and glossing over that convention seems roughly as contentious as when companies try to split the baby and rewrite "open source" to include anti-competitive terms.
[1]: https://www.redhat.com/en/resources/red-hat-enterprise-linux...