Software libre
FSDG y RYF de GNU: libertad, firmware y realidad del hardware
Las FSDG de GNU y el RYF de la FSF siguen siendo referencias en libertad de software, pero abordan mal el firmware, infravaloran las dependencias del hardware moderno y dejan una brecha entre cumplimiento formal y control real del usuario.
Esta crítica a FSDG y RYF no rechaza la libertad de software. La cuestión central son sus límites de diseño: qué se considera libertad suficiente hoy, cómo se aplican las excepciones y si el modelo actual empuja a fabricantes y comunidades hacia una emancipación técnica real o solo hacia una alineación formal.
Qué exigen realmente los criterios
Las Free System Distribution Guidelines (FSDG) de GNU exigen retirar software no libre, incluidos blobs de firmware no libre, y evitar que la distribución dirija al usuario hacia repositorios o documentación no libre. Es un listón alto, basado en una curación muy estricta del software.
RYF aplica principios similares al hardware comercial: exige software libre en el producto y capacidad práctica para instalar versiones modificadas. Sin embargo, su texto público incluye una excepción para cierto software en procesadores embebidos secundarios cuando no se prevé instalación tras la compra[1]. Ese punto sigue siendo uno de los más discutidos.
Firmware: donde la teoría choca con los Dispositivos
Portátiles, servidores y periféricos modernos dependen de múltiples capas de firmware: chips Wi-Fi, controladoras de almacenamiento, GPU, controladores embebidos y microcódigo de plataforma. En muchos casos, esos componentes son necesarios para la funcionalidad básica y las alternativas libres son inexistentes o todavía inmaduras.
Los criterios producen un resultado asimétrico. FSDG rechaza el firmware no libre entregado por una distribución avalada, mientras RYF exime el software de ciertos procesadores secundarios cuando no se espera que el usuario instale actualizaciones después de la compra. La política de paquetes recibe una regla absoluta; algunas de las capas de hardware menos auditables reciben una excepción.
La cuestión técnica clave es dónde reside el firmware. Si el firmware lo carga el sistema operativo, la comunidad al menos puede inspeccionar rutas de carga, comparar binarios y experimentar con sustituciones desde la capa de distribución. Cuando el firmware está embebido en controladores secundarios, esos caminos desaparecen: la ingeniería inversa suele requerir extracción física, trazado de buses, herramientas no documentadas y riesgo legal por normas anti-elusión. Es decir, justo donde auditar es más difícil es donde RYF hoy mantiene una excepción.
Presión de adopción y políticas de Distribución
La fricción se ve en la gobernanza de distribuciones. La Resolución General de Debian de 2022 sobre firmware no libre y su implementación en Debian 12 priorizaron la instalabilidad en hardware común, con información visible para el usuario y controles explícitos. GNU, en cambio, considera esta dirección incompatible con sus criterios de aval para distribuciones libres y la cita al explicar su no recomendación.
La objeción de despliegue es clara: una norma que provoca recortes severos de compatibilidad pierde adopción y, con ella, capacidad de presión sobre los fabricantes. Rebajar el requisito tiene el coste opuesto, pues normaliza el bloqueo privativo. Una norma útil debe conservar la presión a favor de firmware sustituible y medir a la vez si los usuarios pueden ejecutar, reparar y actualizar en la práctica el dispositivo certificado.
La crítica de alcance: libertad de Software frente a Libertad del Dispositivo
También cuestiono su alcance. FSDG y RYF evalúan principalmente licencias y políticas de distribución de software. Cubren en menor medida la reparabilidad, la apertura del diagnóstico, la mantenibilidad del hardware y la presión legal anti-elusión, aunque esas restricciones pueden bloquear la reparación legítima y la ingeniería inversa.
La autonomía del usuario hoy depende tanto del código como del control del ciclo de vida del dispositivo. El movimiento por el derecho a reparar ha mostrado cómo restricciones legales y técnicas en software embebido vacían de contenido la propiedad material del equipo. Un marco que no mida ese eje sobreestima la libertad práctica.
Aquí es donde GPL, FSDG y RYF se separan de forma relevante. El copyleft de la GPL puede proteger reciprocidad de código cuando el código fuente está disponible, y FSDG puede impedir distribuir blobs no libres en distros avaladas. Pero ninguno de esos mecanismos resuelve, por sí solo, el firmware opaco soldado en controladores del dispositivo. RYF/FSDG siguen infravalorando ese límite: puede haber cumplimiento formal de software y, aun así, coexistir con componentes prácticamente no verificables y difíciles de estudiar.
Conclusiones
La crítica más fuerte a FSDG y RYF no es que sean demasiado exigentes en teoría, sino que su efecto es desigual: muy rigurosos donde el proyecto controla paquetes y menos transformadores donde se concentra el control real del hardware.
Una norma revisada mantendría el suelo actual de libertad, endurecería las excepciones y añadiría métricas explícitas de reparación, recuperabilidad, reemplazo de firmware y control verificable por el usuario en toda la pila del dispositivo. Así, la política pasaría de la pureza simbólica a resultados medibles de libertad.