by exiguus on 8/4/25, 9:26 PM with 66 comments
by woodruffw on 8/4/25, 10:57 PM
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...
by burnt-resistor on 8/4/25, 10:23 PM
Many people also seem to think Atlassian Jira and Confluence are OSS when they're absolutely not.
by evanjrowley on 8/4/25, 11:36 PM
by einpoklum on 8/4/25, 11:02 PM
The common case is considering projects which have one element that is FOSS and another that isn't. For example: ProtonMail, who apparently offer a FOSS mail client. They never presumed to offer mail server software; and FOSS mail server software is available. So a button calling them out for not being really FOSS kind of misses the mark. You don't see an entry like that for, say, GMail - so if Proton did not provide a client at all, they would have faired better.
Another specific case is that of Signal. The client and server are FOSS, but they're designed for no federation, so you can't (?) use a modified Signal client with the vanilla clients, and you definitely can't add a server to the network. This effectively prevents modified versions of Signal from being usable. So, is it really FOSS? The site's verdict is: Unqualified yes, Green button.
by exiguus on 8/4/25, 10:26 PM
by kiitos on 8/4/25, 11:57 PM
by ethan_smith on 8/5/25, 1:35 AM
by zzo38computer on 8/5/25, 12:15 AM
I think these articles are good, but I do have some other comments.
For some programs, there is the possibility that some parts can potentially work without non-FOSS but is difficult to separate. (This can also be a different problem in case you only want one part of the program.)
A program can also be Free but "trapped", in case it requires proprietary compilers to compile it (although it is often possible to work around this; sometimes easily and sometimes more difficult).
For some games that have non-FOSS parts, there is also the issue of if the non-FOSS parts can execute arbitrary code or otherwise do things outside of the game itself, that is not necessarily desirable (e.g. a Game Boy Advance emulator might be FOSS, although the programs it emulates might or might not be FOSS, but either way do not affect the rest of the computer nor the internet and other stuff like that); and, also the consideration of whether the software can be used without the non-FOSS parts (if you can replace them; e.g. a FOSS game engine might be made as a clone of a non-FOSS game engine that can use the original game files but you can also make your own fully FOSS games using it too).
There is also some that may require non-FOSS to access, even if the software itself is FOSS. Proprietary (or overly complicated, even if FOSS) communication channels are also not mentioned (although another comment on here does mention it), and I think it probably is a concern (not one that necessarily makes the project itself to be not FOSS, but still might be worth mentioning), even if it does not make the program itself to be not FOSS, it can make it difficult to contribute or to use it.
Being FOSS does not necessarily mean that you intend to run the program on your computer; you might only want to view the code, or modify it before running it, or use your own program (or a different FOSS program) as a substitute.
Programs can be "open core" but the non-FOSS part is still clearly distinct from it (which is the case for SQLite). (In the case of SQLite, they also mention the non-FOSS test suite; they are not needed to run the program, but it may make it difficult to make your own changes and then test it. However, some programs do not have a real test suite at all, anyways.)
by oever on 8/4/25, 11:10 PM
This is a big improvement over projects that are hosted on GitHub. For those, the license may be FOSS, but the spirit is not, because anyone that wants to contribute upstream is lured onto a proprietary platform.
The license and terms of service of a project's community communication channels are not listed under the concerns. (https://isitreallyfoss.com/concerns/) This is understandable: traditionally and strictly, the license is the only thing that matters.
by Der_Einzige on 8/5/25, 1:29 AM
Ultimately, most people use the term "open source" to mean "freely downloadable" or similar. Sorry I guess that the gnulag[1] never happened.
by the_mitsuhiko on 8/4/25, 11:28 PM
by throwaway323929 on 8/5/25, 3:30 AM
When you're not being paid to do something, the only benefit you get aside from software you use yourself is friendly peer recognition, and when it becomes too abrasive, when people are treating you like politicians and trying to scare you into adopting their political views, when users come in and trash talk your project like they're your boss because you didn't implement some feature they want, a lot of people just give up and leave. I largely left the space because of this, and a lot of really good OSS contributors I knew did too.
I'm not sure what the solution is at this point but it's probably not a continuation of the entitlement mentality, purity tests and witch hunts that this site is perpetuating.
by aguacaterojo on 8/5/25, 12:45 AM
by sroerick on 8/4/25, 10:43 PM
by jeeyoungk on 8/5/25, 12:46 AM
I don't have a skin in the game, but I personally think that the definition of FOSS is too rigid and strict and is not evolving. There has been many challenges over time (LGPL's linking exception, tivoization, AGPL trying to fight against SaaS, Open Core business models, ...); and we are really bestowing very harsh moral standards for people who are trying to do the right thing.
For me, Sentry, being 10+ years in its existence (I used it ever since its logo was a Starcraft II unit), never participated in the usual enshitification of the software, being labeled as "NOPE" is disingenuous. I would gladly pay for Sentry because I love the software, and I also know that if shit hits the fan, I can self-host it (though the configuration for self-hosting got progressively difficult over time, but that's the complexity of modern SaaS stack). I can make similar arguments to other tools in this site that I'm familiar with.
by firesteelrain on 8/5/25, 12:33 AM
You get what you pay for
by sho_hn on 8/4/25, 10:26 PM
by sanex on 8/4/25, 11:44 PM
