I wrote:

> As it happens, as I mentioned, I just recently bought (to play with) a
> reconditioned Zotac CI321 w/4GB RAM and a 64GB SSD for US $125 with 1
> year warranty from Zotac after John Franklin mentioned the Zotac
> C-series here. (TY, John!) It has the Intel ME and Intel FSM problems,
> too.
[...]
> The FSP is a separate problem (for both the Purism laptops and my
> little toy Zotac), and I can't say much about more about that.

I'll do that now.

Long ago, I had a Lucent Silver Wavelan PCMCIA 802.11b wireless card for
my laptops. At the time, this was the most universally best supported
wireless chipset ever, using the orinoco_cs driver starting with the
2.4.3 Linux kernel. Like all NICs of that generation, the card had a
built-in ROM that hooked into hardware initialisation.

Newer cards (and motherboard chipsets) have often had hauntingly similar
functionality to my old 802.11b card, but relegated the ROM
initialisation to a binary-only firmware BLOB that must be hurled into
RAM during hardware recognition -- a change made, as far as I can tell,
just to save a trivial amount of money on ROM costs. It occurred to me
that the functionality of the new BLOBs and of my old Lucent card's ROM
contents was the same. In a few cases, the new BLOBs might even be
exactly the same code, just dd'd to a file from what was formerly burned
into a ROM.

I sometimes have Richard Stallman as a house guest, and I don't _think_
I've yet raised this with him, but I keep intending to. So, here's my
attempt to imagine the conversation:

RM:  Here's my point:  Why are the firmware BLOBs a software freedom
     issue, and the Lucent ROM was not?

RMS:  We at FSF seek freedom to modify in all general-use software, and
    the BLOBs, if they were freed, could give developers ability to
    improve them, the ability to ensure that they are
    freedom-protecting, and the ability to adapt that code to other
    purposes for everyone's benefit.

RM:  Sure, but why wasn't that by the same token an issue for the 
    Lucent ROM code?  And, for that matter, why not CPU microcode?

RMS:  Because those are hardware, and you can't change them.  Maybe
    one day we'll have full visibility into microcode, but one fight
    at a time.

RM:  Fair enough, but are you saying that FSF would have no problem
    with BLOB firmware images if they get burned into ROMs?  I'm
    not clear on why that would matter.  It's the same code doing
    the same functionality.  Also, I'm not sure the ROM code in
    a Lucent Silver could not be changed.  Often, these aren't 
    classic burn-once ROMs but rather EEPROMs.

RMS: [here, I run out of imagination]

The Stallman in my head _might_ have countered that, well, the frontiers
of free software (I almost said 'open source') change over time
depending on what is feasible. Back then, hardware init 'feature' ROMs
were black boxes and we couldn't reasonably dream of changing that.
Now, we may have many obstacles, but we can aspire.

Angling back to the Intel Firmware Support Package: In 1997, it never
would have even occurred to you to object to the (then-current analogue
of the) Intel FSM as a free software issue, because you'd just call it
'the feature ROMs', and it was just an unavoidable black-box feature of
your computer, like the CPU microcode. Twenty years later, a bunch of
people see that as an intolerable affront to freedom-respecting hardware
design, even though nothing has actually changed.

But if that's not a grey area, then I don't know my greyscales.

(In fairness, Libreboot Project clarifies on
https://libreboot.org/faq.html#intel that the FSP handles System
Management Mode, which raises a genuine security concern, in addition to
doing 1997-style hardware initialisation. To quote my favourite line
from 'The West Wing', 'Ah, the rare valid point.')