Verificación de edad en Linux: por qué ignorar las leyes es más difícil de lo que parece

Cuatro líneas de bash para descargar Arch, un servidor de mirrors gestionado por voluntarios desde algún punto de Europa, y una ley firmada en Sacramento que dice que ese sistema operativo tiene que saber cuántos años tienes antes de dejarte usarlo. Ahí está la pregunta que lleva meses quemando hilos de foros: ¿por qué no se ignora directamente?

La verificación de edad en Linux ha pasado de ser una discusión teórica a un problema legislativo concreto con fechas de entrada en vigor reales. Entender por qué algunos mantenedores se mueven —aunque sea para buscar exenciones— requiere mirar más allá de quién firma la ley y fijarse en dónde está la infraestructura.

#Qué dicen exactamente las leyes

Tres jurisdicciones, tres enfoques distintos. No es lo mismo estar en el radar de California que en el de Brasil.

California (AB 1043, «Digital Age Assurance Act»): firmada en octubre de 2025 y con entrada en vigor el 1 de enero de 2027, obligaba a los proveedores de sistemas operativos a recopilar la fecha de nacimiento o franja de edad del usuario durante la configuración inicial del dispositivo y compartir esa «señal de edad» con las aplicaciones instaladas. La redacción original era tan amplia que metía en el mismo saco a Ubuntu y a Windows.

La presión de la comunidad open source fue suficiente para que en mayo de 2026 avanzara AB 1856, una enmienda que redefine «proveedor de sistema operativo» para excluir explícitamente a quienes distribuyan software bajo licencias que permitan copiar, redistribuir y modificar el código. La Electronic Frontier Foundation (EFF) aplaudió la exención pero advirtió que la misma ley ampliaba el régimen de control de edad a navegadores web y sitios.

Colorado (SB 26-051): va por el mismo camino que California, con entrada en vigor el 1 de julio de 2028 y una exención para software open source ya incorporada en el texto final. Más tiempo, menos presión inmediata, pero el precedente está ahí.

Brasil (Ley 15.211/2025, «ECA Digital»): en vigor desde el 17 de marzo de 2026 y es la más agresiva de las tres. No hay exención para open source. La ley aplica a cualquier producto o servicio digital que sea «susceptible de ser accedido» por menores —una formulación tan elástica que cubre sistemas operativos, tiendas de aplicaciones y servicios en línea—, independientemente de dónde tenga sede el proveedor. Las sanciones llegan hasta 50 millones de reales por infracción o el 10% de los ingresos obtenidos en Brasil. La ANPD (Agencia Nacional de Protección de Datos) es el organismo encargado de aplicarla.

#Por qué «ignorarlo» es más complicado de lo que parece

El argumento de la desobediencia civil tiene cierta lógica romántica. The Pirate Bay lleva dos décadas funcionando a trompicones. Los trackers de torrents de 2003 sobrevivieron a la RIAA. ¿Por qué Linux no puede hacer lo mismo?

Porque la infraestructura del software libre moderno no está diseñada para resistir presión legal de la misma forma que lo está un servidor anónimo en una jurisdicción opaca.

El primer vector de riesgo no es una multa al mantenedor. Es una orden judicial dirigida al proveedor de infraestructura. Cloudflare, GitHub, Fastly o AWS están radicados en suelo estadounidense o europeo. Un juez de California puede ordenarles que suspendan el servicio a un proyecto concreto sin tocar a ningún desarrollador individual. Eso es perfectamente ejecutable y no requiere extradiciones ni tratados internacionales. Fedora, Ubuntu, Linux Mint y docenas de distros más dependen de esa infraestructura para servir ISOs y paquetes.

El segundo problema es la diferencia entre proyectos con personalidad jurídica y proyectos sin ella. Debian, Fedora (Red Hat / IBM), Ubuntu (Canonical), openSUSE (SUSE)… todos tienen entidades legales con sede física, cuentas bancarias y contratos con patrocinadores corporativos. Un litigio, aunque sea absurdo y probablemente perdible, cuesta tiempo de abogados y genera incertidumbre que los sponsors detestan. Arch Linux o Gentoo tienen una exposición mucho menor en ese sentido —y de hecho han sido los más lentos en reaccionar a estas presiones—, pero tampoco tienen los recursos para pelearlo en un tribunal si la cosa escala.

El tercer punto es geográfico. Los mirrors de las grandes distros están distribuidos por todo el mundo, pero el nodo raíz, los DNS autoritativos o los servicios de firma de paquetes suelen estar en jurisdicciones con legislación activa. No es que te persigan a ti. Es que cortan el grifo en el origen.

#El campo birthDate en systemd y por qué la comunidad se incendió

En marzo de 2026, el proyecto systemd mergeó el PR #40954, que añadía un campo opcional birthDate a los registros JSON de usuario gestionados por systemd-userdb. Campo opcional. Solo editable por el administrador del sistema. systemd no verifica nada por sí solo; se limita a proporcionar el esquema para que otros componentes del escritorio —portales D-Bus, controles parentales— puedan leerlo de forma estandarizada.

La reacción fue, digamos, desproporcionada.

Foros, listas de correo y hilos de Reddit ardieron con acusaciones de capitulación ante los gobiernos. Se crearon forks («Liberated systemd»), se reavivó el debate sobre Devuan y Artix como alternativas a systemd, y el desarrollador que firmó el PR sufrió acoso con doxxing incluido. Todo esto por un campo de metadatos que, técnicamente, hace lo mismo que añadir un campo personalizado a /etc/passwd: almacenar un dato localmente sin enviarlo a ningún lado.

El argumento de Lennart Poettering —que si las aplicaciones van a necesitar manejar lógica de edad es mejor que lo hagan desde una fuente estandarizada y local antes que cada aplicación construya su propio mecanismo oscuro— tiene una coherencia técnica que es difícil de rebatir. Otra cosa es si ese razonamiento compra premisas que nadie debería comprar. Los críticos no estaban discutiendo el campo en sí: estaban discutiendo qué infraestructura estás normalizando para que exista.

#La analogía con la piratería: válida, pero incompleta

La piratería lleva décadas ignorando la legislación de derechos de autor con un éxito relativo. ¿No debería funcionar lo mismo para Linux?

Parcialmente. Pero hay diferencias estructurales que cambian el cálculo.

Los trackers de torrents y los sitios de descarga directa operan históricamente desde jurisdicciones diseñadas para ser opacas —o desde infraestructura tan dispersa que desmantelarla requiere coordinación internacional prolongada—. The Pirate Bay ha sobrevivido, sí. Pero sus fundadores tienen condenas penales reales, lleva 15 años saltando de dominio, y está bloqueado a nivel de ISP en decenas de países. «Sobrevivir» a ese nivel de fricción continua es un proyecto diferente a distribuir un sistema operativo de forma fiable a millones de usuarios.

Una distribución Linux necesita que sus mirrors funcionen de forma predecible, que los repositorios de paquetes tengan tiempos de respuesta razonables y que las firmas GPG sean verificables. Todo eso depende de infraestructura que no está en un servidor anónimo en las Seychelles.

#Cómo han respondido las distros

El abanico de reacciones es amplio y bastante ilustrativo de cómo distintos proyectos ponderan el riesgo.

En el extremo resistente, proyectos como Artix Linux, MX Linux o la recién creada Ageless Linux han declarado explícitamente que no implementarán ningún mecanismo de verificación de edad, citando incompatibilidad filosófica con el ethos open source. Algunos derivados de Arch han optado por el geoblocking —bloquear acceso desde jurisdicciones con enforcement activo— como forma de evitar la exposición legal sin tocar el código. Solución práctica para el proyecto; bastante incómoda para el usuario brasileño que solo quería descargar un ISO.

En el extremo pragmático, Ubuntu (Canonical) y Fedora han explorado implementaciones mínimas basadas en interfaces D-Bus locales: el sistema operativo expone una señal de edad que las aplicaciones pueden consultar, pero sin cuentas centralizadas ni datos enviados a ningún servidor. La idea es cumplir la letra de la ley con el mínimo impacto posible en la arquitectura del sistema. Puede que no sea la postura más heroica, pero tiene cierta lógica si el objetivo es que el sistema llegue a los usuarios en California sin interrupciones.

#¿Resistencia o pragmatismo? La pregunta que nadie responde bien

Hay dos posturas legítimas en este debate, y ninguna sale completamente indemne del escrutinio.

La resistencia principista —»no implementamos nada, que legislen lo que quieran»— funciona mientras la infraestructura aguante. Si llega el día en que un juez ordena a Cloudflare suspender el servicio a una distro concreta, el principio no paga el hosting de emergencia ni migra los mirrors en 48 horas. Los proyectos que optan por esta vía están apostando a que el enforcement nunca llegará a ese punto. Puede que tengan razón. Puede que no.

El pragmatismo minimalista —»implementamos la señal mínima requerida, local, sin telemetría»— tiene el problema de que normaliza la existencia de la infraestructura. Aunque hoy sea un campo opcional en systemd-userdb, la próxima ley puede asumir que esa infraestructura ya existe y construir sobre ella algo más intrusivo. Eso es exactamente el argumento del «slippery slope» que la comunidad lleva meses repitiendo, y no es tan paranoico como parece cuando miras el historial legislativo de los últimos diez años en estas materias.

Lo que sí está claro es que el espacio para «ignorarlo simplemente» se ha reducido. No porque las leyes sean irresistibles, sino porque la infraestructura del ecosistema open source moderno tiene puntos de presión concretos y ejecutables que los crackers de software de 2003 no tenían. La piratería sobrevivió décadas porque operaba desde los márgenes. El software libre quiere operar en el centro, y ese es un lugar con reglas distintas.

Esto lo escribo en julio de 2026. AB 1856 todavía no ha pasado por el Senado de California, la ANPD brasileña puede publicar nueva normativa técnica en cualquier momento, y la situación del geoblocking en algunas distros menores cambia cada pocas semanas. Si llegaste aquí seis meses después, verifica el estado actual de las exenciones antes de asumir que tu distro favorita está en tierra segura.