Free Software
GNU FSDG and RYF: Freedom, Firmware, and Hardware Reality
GNU's FSDG and the FSF's RYF still shape freedom standards, but they handle firmware poorly, understate modern hardware dependencies, and leave a gap between formal compliance and real user control.
This critique of FSDG and RYF is not a rejection of software freedom. The key issue is their design boundaries: what counts as acceptable freedom today, how exceptions are applied, and whether the current model pushes vendors and communities toward real technical emancipation or only formal alignment.
What the Criteria Actually Require
The GNU Free System Distribution Guidelines (FSDG) require endorsed distributions to remove nonfree software, including nonfree firmware blobs, and to avoid directing users to nonfree repositories or documentation. That creates a high bar built around strict software curation.
RYF applies similar principles to hardware products, requiring that product software be free and installable in modified form. However, the published criteria include an exception for software running on certain secondary embedded processors where post-purchase installation is not intended[1]. That carve-out remains one of the most debated points.
Firmware: Where Theory Meets Physical Devices
Modern laptops, servers, and peripherals depend on layered firmware: Wi-Fi chips, storage controllers, GPUs, embedded controllers, and platform microcode. In many cases, these components are required for baseline functionality, and alternatives are either unavailable or immature.
The criteria produce an asymmetric result. FSDG rejects nonfree firmware delivered by an endorsed distribution, while RYF exempts software in certain secondary processors when the user is not expected to install updates after purchase. Package policy receives an absolute rule; some of the least auditable hardware layers receive an exception.
The key technical issue is where firmware lives. If firmware is loaded by the operating system, communities can at least inspect loading paths, compare binaries, and experiment with replacement workflows at the distribution layer. When firmware is embedded inside secondary controllers, those paths disappear: reverse engineering often requires hardware extraction, bus tracing, undocumented tooling, and legal risk around anti-circumvention rules. In other words, the place where auditability is most difficult is exactly where RYF currently allows an exception.
Adoption Pressure and Distribution Policy
This friction is visible in distribution governance. Debian's 2022 General Resolution on non-free firmware and the Debian 12 rollout prioritized installability on mainstream hardware, with explicit disclosure and user controls. GNU, by contrast, treats this direction as incompatible with free-distro endorsement standards and cites it when explaining non-endorsement.
The deployment objection is straightforward: a standard that causes severe hardware regressions loses adoption and therefore loses leverage over vendors. Lowering the requirement carries the opposite cost by normalizing proprietary lock-in. A useful standard must preserve pressure for replaceable firmware while measuring whether users can run, repair, and update the certified device in practice.
The Scope Critique: Software Freedom vs. Device Freedom
I also challenge their scope. FSDG and RYF primarily assess software licensing and distribution behavior. They cover repairability, diagnostic openness, hardware serviceability, and anti-circumvention pressure less thoroughly, even though those constraints can block legitimate maintenance and reverse engineering.
User autonomy now depends on both code and control over the hardware lifecycle. Right-to-repair advocates have shown how legal and technical restrictions around embedded software undermine ownership even when parts of the stack are open. A criteria framework that does not score those constraints overstates practical freedom.
This is where GPL, FSDG, and RYF diverge in ways that matter. GPL copyleft can protect source-level reciprocity where source is available, and FSDG can block shipping known nonfree blobs in endorsed distributions. But neither mechanism, by itself, solves opaque controller firmware soldered into devices. RYF/FSDG still underweight this boundary: formal software compliance can coexist with components that remain practically unverifiable and hard to study.
Conclusions
The strongest critique of FSDG and RYF is not that they are too strict in principle, but that they are uneven in effect: rigorous where projects can edit package sets, less transformative where control over hardware is actually concentrated.
A revised standard would preserve the current freedom floor, tighten exception paths, and add explicit metrics for repair, recoverability, firmware replaceability, and user-verifiable control across the full device stack. That would move policy from symbolic purity toward measurable freedom outcomes.