After Pine64 went to all the trouble to make a series of branded early developer editions for various distros, and ongoing community goodwill outreaches, I didn't expect something like this to happen.
IMHO, any handheld hardware right now wanting to be open and sustainable Linux should probably start by making sure it's solid with PostmarketOS configured with a mainline kernel, as a good test. (PostmarketOS is a litmus test for purity, and has had a bunch of work to make bringing it up easier than the usual server/desktop purity test of Debian.) Working Phosh and Plasma userlands running atop PostmarketOS are good further tests. Supporting additional distros, userlands, and hacking is also important.
(Even if the hardware is something like the Purism Librem 5, which has invested heavily in lots of good distro work, if PostmarketOS with mainline kernel boots cleanly and runs solidly, that's a good sign.)
While Debian has more strict policies on software licensing etc the musl component of postmarketOS pretty much makes sure that no closed source software will ever run in userspace. The main difference is that postmarketOS does deal with firmware for hardware while Debian doesn't. Hopefully we someday get at a point where even the firmware for these devices isn't problematic anymore.
Some distros, such as alpine Linux, use musl libc as their system wide C library.
glibc is pretty much ubiquitous, so any closed source software will be compiled against glibc and will not work with musl c libraries.
That's not to say a vendor couldn't do a muslc build of a closed source software, just that it's pretty much unheard of.
I believe binary compatibility is a goal of musl, being able to run a glibc binary against a musl libc library, but I think that's a long way off.
So an alternative on a musl libc distro is to use something like flatpak that bundles glibc libraries in a sandbox / container.
The side effect the grandparent comment is referring to, is that you have a good idea all the software on your system is open source, other than what you are running in flatpak, as closed source binaries are unlikely to run on your musl system.
> That's not to say a vendor couldn't do a muslc build of a closed source software, just that it's pretty much unheard of.
The ironic thing is that musl makes it easier to do static binaries, so in a world where glibc wasn't older I would have expected to see more proprietary software compiled against musl (albeit, statically linked so that it didn't really matter).