The problem (for those who are unaware of it)
Moved it to the end, to keep the focus on the solution.
Solution
GNU is a desktop OS that was never completed. Linux is a desktop OS that was never completed.
GNU/Linux is a hybrid OS.
Musl, etc. are libraries that were never OSes.
- So Alpine would be a Community/Linux OS.
- Debian would be a Community/GNU/Linux OS.
- FreeBSD would be a Community/BSD OS.
- Ubuntu would be an Enterprise Community/GNU/Linux OS.
I was thinking ontologically to resolve this problem. It is often confusing to explain to ordinary people why Linux has so and so differences and so and so commonalities, and then the community gets toxic once you get to whether it’s GNU or Linux.
So I think this is a good solution that solves the argument of calling it systemd/Freedesktop/KDE/LightDM/GNU/Linux or the other party that says it’s either GNU or Linux alone.
Why can’t you include GNU in the Community?
Because GNU was an independent OS, and the project did a lot for software freedom, and it was even pivotal to the success of Linux, yet the community does not honour their wish to mention their names, because of aesthetic problems. GNU has never self-identified as a component collection like Freedesktop.
The problem (for those who are unaware of it)
Not everyone may be aware of this, but from the time GNU and Linux based hybrid operating systems became a thing, there was a debate about what they should be called. An OS has a kernel and the userland. Both GNU and Linux were independent operating systems, both of which were never completed.
GNU was a project by FSF under Richard M. Stallman to replace the proprietary UNIX OS. Linux was a hobbyist project by Linux Torvalds to make an OS that would run on the Intel 80386 CPU, while BSD/386 was facing a lawsuit from AT&T for releasing proprietary UNIX source code. GNU was planning to make a microkernel based OS, and it was planning to develop the kernel slowly, while Linus started Linux from the kernel side, with a monolithic architecture.
Since Linux was free software and could run directly on the new hardware, it gained the support of the hacker community, who added patches to the GNU userland to make it work with Linux. But when Linux finally became an OS with the help of GNU, the hacker community said they only care about Linux, not the GNU programs, and gave no recognition to GNU.
Because of this, Stallman asked the distributions to be called GNU/Linux, and that sparked flame wars because of how it is bad to pronounce, and how a distribution has many components beyond just GNU, and that therefore the kernel that runs on the hardware is what should describe the OS, and further several ad-hominem attacks on the personal life and behaviour of Richard Stallman.
Eventually, the name Linux caught on, but sympathizers of GNU are requested to call it GNU/Linux. This continues to be an unresolved, but sidelined dispute that seems unfair to GNU, especially considering most “Linux programs” are actually dependent on GNU GLIBC, and won’t run on the other Musl LIBC based systems. Anytime someone mentions it, because there is no easy solution to it, it turns into a flame war.
I don’t know if grouping disparate projects under the “community” label has any worthwhile benefit. Given the label is meant to classify related operating systems, the label should provide an accurate description of the basis of the system. A simpler solution would be to just say GNU/Linux is a subcategory of Linux (and maybe even sub-sub-categorize by package manager or init system or whatever makes the most sense). Similarly, I think Android and its derivatives are worthy of being its own classification of Linux operating system (as long as you don’t try to claim “it’s not real Linux” or whatever).
With regards to software compatibility, I think it’s rather the other way around - software written for “Linux” usually works on any POSIX operating system, and sometimes even Windows. Unless you’re talking about binary compatibility, which is meaningless in the Linux space anyway.
In practice, as a person who uses Musl LIBC and the Runit init system, most “Linux programs” don’t even work on it, often even if I try to build it from source because of their dependencies on GLIBC. GLIBC is a very hard dependency that most people overlook when writing software.
And many programs even have a hard dependency on systemd, to a lesser extent. Even that too only works on systems with GLIBC, and cannot be used with any other LIBC.
Which is one of the reasons why specified GNU/Linux separately from just Linux for Alpine, instead of calling it Musl/Linux.
If a software is written for just Linux, it will work on either system. But if it is written for GLIBC, it work work on Musl LIBC based systems.
Programs linked dynamically with Musl LIBC won’t work on GLIBC based systems too, but considering the trend of everyone using GLIBC, those who build for Musl LIBC would state it explicitly, compared to programs released for GLIBC, which ambiguously only say that it is built for Linux.