diff --git a/site/news/policy.md b/site/news/policy.md
index ff461f1..46c90cd 100644
--- a/site/news/policy.md
+++ b/site/news/policy.md
@@ -67,8 +67,8 @@ So what *is* Canoeboot's policy?
 Canoeboot follows a very conservative and *light touch* approach, when it comes
 to deblobbing coreboot.
 
-Canoeboot only excludes *software* binary blobs, plus CPU microcode updates,
-completely in line with FSF policy. *In practise, it is mostly microcode
+Canoeboot only excludes *software* binary blobs, plus CPU microcode updates.
+*In practise, it is mostly microcode
 updates that Canoeboot's build system deletes, along with coreboot Git history
 so that no traces remain of old revisions; older revisions had many blobs in
 the main repository, but modern coreboot moved almost all of them to third
@@ -117,22 +117,6 @@ purpose of this section is to spread *facts*.
 Not including CPU microcode updates is an absolute disaster for system
 stability and security, and yet, this is one of Canoeboot's key policies.
 
-Making matters worse, that very same text quoted from the FSF RYF criteria in
-fact specifically mentions microcode. Quoted again for posterity:
-
-*"However, there is one exception for secondary embedded processors. The
-exception applies to software delivered inside auxiliary and low-level
-processors and FPGAs, within which software installation is not intended after
-the user obtains the product. This can include, for instance, microcode inside
-a processor, firmware built into an I/O device, or the gate pattern of an FPGA.
-The software in such secondary processors does not count as product software."*
-
-Here, it is discussing the microcode that is burned into *mask ROM* on the CPU
-itself. It is simultaneously not giving the OK for microcode *updates* supplied
-by either coreboot or the Linux kernel; according to the FSF, these are an
-attack on your freedom, but the older, buggier microcode burned into ROM is OK.
-This is absolutely inconsistent.
-
 The CPU already has microcode burned into mask ROM. The microcode configures
 logic gates in the CPU, to implement an instruction set, via special *decoders*
 which are fixed-function; it is not possible, for example, to implement a RISCV
@@ -141,23 +125,11 @@ implement x86, or *broken* x86, and the default microcode is almost always
 *broken x86* on Intel/AMD CPUs; it is inevitable, due to the complexity of
 these processors.
 
-The basis of the FSF's disagreement about microcode *updates* is that they do
-believe otherwise; Stallman himself expressed such ignorance to me, in a recent
-email conversation I had with him, as of January 2nd, 2022. The FSF believes
-that these x86 microcode updates (on Intel/AMD) allow you to completely create
-a new CPU that is fundamentally different than x86. This is not true. It is also
-not true that *all* instructions in x86 ISA are implemented with microcode. In
-some cases, hardcoded circuitry is used! The microcode updates are more like
-tiny one liner patches here and there in a git repository, by way of analogy.
-To once again get in the head-space of the FSF: these updates cannot do the CPU
-equivalent of re-factoring an entire codebase. They are *hot fixes*, nothing
-more!
-
 These processors provide a way to supply microcode *updates*. These updates
 are volatile, and consequently must be applied during every boot cycle. The
 updates fix stability/reliability/security bugs, and their *absence*
 is *technically incorrect*, but Canoeboot excludes them anyway, because that is
-FSF policy. Examples of where these updates fix bugs: on ASUS KCMA-D8/KGPE-D16
+Canoe policy. Examples of where these updates fix bugs: on ASUS KCMA-D8/KGPE-D16
 and ThinkPad X200/T400/T500/W500/X200T/X200/R500/X301, the updates make
 hardware-based virtualization (via `kvm`) completely stable, where it would
 otherwise lead to a kernel panic. They allow those same thinkpads to be run with