> I've no idea but it would seem logical to me it would
> be much simpler to base Triskamullo on Debian - the
> OS is already free and you'd just need to remove
> the references to non-free from the documentation.
Bingo!
The main problem apeears that FSF has just *too strict* rules. So strict that
it hinders its proprietor. I like FSF being nocompromising in freedom issues,
but turning things into taboos (where one way or the other wouldn't really
affect freedom) is not helping the cause either.
Here are some examples where the word "strict" convolutes into "taboo".
* Conflating the concepts of "system" and "operating system" : The OS may be
free and secure, yet the system may not. E.g. any system using a proprietary
CPU or any other hardware (particularly if it is network related) cannot be
considered as a free and secure system. In assessing freedom of an OS, these
two concepts (OS and h/w) should be clearly distinguished. Currently FSF's
position is that,
"We deny closed hardware/firmware, but will use it if we don't have to it.
If an OS uses a blobby hardware out of necessity without uploading its
firmware, then it is OK; but if it (not run, just TOUCH, i.e. upload) the
firmware, then this OS is not OK."
For something to be successful, it should sit on sound and robust logic. This
logic is just buggy. Uploading a firmware to proprietary hardware, or using a
ROM based proprietary hardware are 100% the same thing, both in terms of
*system's freedom* and in terms of *OS freedom*. In both cases the system is
non-free. In both cases the OS has nothing to do with it (except being an
accomplice - but then isn't *using* a proprietary harware the same?).
Forbidding upload of firmware blobs is just symbolism, and hinders FSF's end
goals with really nothing tenable in return.
* Mixing hardware domain with OS domain: Although firmware is software, it
still belongs to hardware domain from the OS perspective. Proprietary
hardware makes the *system* proprietary, but it has no effect on the *OS*
itself. Mixing these two domains in freeness assessment of an OS leads to
conflictions as mentioned above.
* Firmware blobs: With a piece of proprietary hardware, it is the same
non-free and non-secure system, no matter it runs off of ROM or RAM. Without
a clean definition that clearly distinguishes and draws lines between the
hardware, the software, overall system, and operating system; we end up
logical dilemmas like above. The same goes with microcode updates.
And Debian goes so far as to exclude firmware blobs from main (even if I find
it excess) but it is still not enough for FSF.
* Similar arguments go for other "verboten" things that jxself mentioned.
This may sound like criticising a decision of top echelons of FSF, but wrong
is wrong - I can't help it.
In a nutshell, I think FSF should rewrite the definitions and redraw the
lines between hardware domain and software domain, and between overall system
freedom and operating system freedom. And then align the rules accordingly.
I had talked about it in a dedicated thread in the past, without being able
to persuade anyone. With the introduction of meltdown and spectre (the
necessity of microcode upgrade) and seeing that this strategy leads to a
distro already ancieant before release, maybe FSF would consider this view
again.
Maybe it is too late now to do anything about Flidas, but I hope Trisquel
will start tailcoating Debian main from the next release on.
