«Nos pasamos a Linux». «Apostamos por el software libre». Estas frases surgen cada vez que un comité aborda la soberanía del software, y se pronuncian con tono de obviedad, como si el código abierto resolviera la cuestión por su mera naturaleza. Resuelve una parte. Deja otra parte intacta y, a veces, desplaza el problema sin resolverlo. La soberanía no se juega en la oposición entre software propietario y libre. Se juega capa por capa: quién controla qué y si es posible salir de ello.

Lo que el código abierto garantiza realmente

El software libre se basa en cuatro libertades, formalizadas por la Free Software Foundation: ejecutar el programa para cualquier fin, estudiar su funcionamiento, redistribuirlo y modificarlo para luego difundir las versiones modificadas. El código abierto, tal y como lo define la Open Source Initiative, abarca un ámbito similar. Estas libertades no son teóricas. Dan lugar a tres propiedades concretas.

En primer lugar, la auditabilidad. El código fuente es legible y, por lo tanto, verificable. Una organización que lo desee puede examinar lo que un programa ejecuta realmente, sin tener que fiarse de la palabra del editor. Para un sector regulado, esta transparencia tiene valor probatorio.

En segundo lugar, la ausencia de una licencia revocable. Una licencia libre —GPL, Apache, MIT— no se extingue por decisión unilateral. El editor no puede cortar el acceso a una versión ya obtenida, ni prohibir su uso de la noche a la mañana. La continuidad no depende de la buena voluntad de un tercero.

Por último, la posibilidad de crear una bifurcación. Si el proyecto cambia de rumbo, se cierra o cae en manos hostiles, el código sigue estando disponible y alguien puede retomar su desarrollo. La comunidad de mantenimiento, cuando existe, reparte esta carga entre varios colaboradores y varias organizaciones.

Lo que no garantiza

Ninguna de estas libertades es un servicio. El código abierto no incluye soporte técnico, ni garantía de corrección, ni hoja de ruta. La libertad de modificar solo es válida para quien sabe hacerlo, y la libertad de auditar solo es válida para quien dispone de los medios para ello. Leer el código fuente de un núcleo, un hipervisor o una base de datos para asegurarse de que no contiene fallos requiere competencias poco comunes y una inversión continua. El código disponible no es el código auditado.

La seguridad sigue la misma lógica. Un software libre no es seguro por el mero hecho de ser abierto; es seguro cuando personas competentes lo leen, lo prueban y lo corrigen a lo largo del tiempo. El episodio de la vulnerabilidad crítica de log4j en 2021 —un componente presente en innumerables sistemas y mantenido por un puñado de voluntarios— nos ha recordado que un componente abierto y omnipresente puede seguir sin recibir la financiación ni la supervisión necesarias. La apertura hace posible la auditoría, pero no la lleva a cabo.

Y, sobre todo, el código abierto no dice nada sobre la infraestructura. Un software libre siempre se ejecuta en algún lugar, en máquinas, en una red, bajo una jurisdicción. La licencia del código y la vinculación jurídica del proveedor de alojamiento son dos cuestiones distintas, y la primera nunca responde a la segunda.

Los casos en los que el OSS realmente cambia algo

El software libre influye en la soberanía cuando actúa sobre las palancas adecuadas. Tres situaciones lo demuestran.

El despliegue local. Un software libre instalado en una infraestructura que controla la propia organización elimina la dependencia de un proveedor de servicios remoto. El código está in situ, bajo una legislación elegida, sin que se realice ninguna llamada saliente a un tercero. Este es el caso que más se acerca a la independencia real.

La auditabilidad normativa. Para una autoridad sanitaria, un banco o un operador de importancia vital, poder presentar el código exacto que procesa datos sensibles no es una comodidad, sino que a veces es una obligación. Un componente propietario sellado impide aportar esta prueba; un componente abierto la permite.

La ausencia de una licencia revocable. Un servicio propietario crítico puede ver cómo cambian sus condiciones, cómo sube su precio o cómo se interrumpe su acceso por decisión de un editor o como consecuencia de una medida de extraterritorialidad. La licencia libre protege de este riesgo a la propia capa de software. No protege al resto.

Los casos en los que no cambia nada

Por el contrario, la etiqueta «código abierto» no ofrece ninguna garantía de soberanía en varias situaciones habituales.

El software libre implementado en las instalaciones de un tercero. Una base de datos o un orquestador libre que se gestiona como servicio gestionado en una infraestructura ajena está sujeto a la legislación de dicho operador, exactamente igual que un producto propietario. El código es abierto, pero la dependencia sigue siendo total. La naturaleza de la licencia no cambia en nada la vinculación jurídica de quien explota la máquina.

La dependencia de componentes propietarios. Un sistema operativo libre que solo arranca con controladores propietarios, microcódigos firmados o un firmware cerrado no es autónomo. La capa visible es abierta, pero se apoya en componentes que no se pueden leer, reproducir ni sustituir. La libertad se detiene ante la primera pieza sellada del hardware.

La falta de capacidad de mantenimiento interno. La libertad de bifurcar un núcleo crítico solo tiene valor para quien realmente puede mantenerlo. Una empresa muy regulada o un actor del sector de la defensa que no cuente con la ingeniería necesaria para retomar el desarrollo de un sistema operativo cuyo editor se retira se ve dependiente de un proveedor, ya sea abierto o no. El derecho a modificar no implica la capacidad de hacerlo.

En estos tres casos, la propiedad que importaba —el control de la capa y la posibilidad de salir de ella— no está garantizada por la licencia. Depende de dónde se ejecute el software, de en qué se base y de quién sepa gestionarlo.

Por lo tanto, la pregunta clave nunca se refiere a la etiqueta. Se plantea capa por capa, desde el hardware hasta el servicio: quién la controla, en virtud de qué derecho, y qué ocurre el día en que ese control se interrumpe. El software libre orienta algunas de estas respuestas en la dirección correcta. Pero no escribe las demás por ti.

L’Estado francés ha tomado su decisión, y eso cambia la escala

El debate ha salido de los foros. En 2026, la dirección interministerial de lo digital, la DINUM, pide a cada ministerio un plan de reducción de las dependencias digitales extraeuropeas. El perímetro es amplio: puestos de trabajo, herramientas colaborativas, antivirus, inteligencia artificial, bases de datos, virtualización, equipos de red. El cambio del sistema operativo, de Windows a Linux, es solo la capa más visible de un proyecto más profundo.

En torno al sistema operativo, el Estado impulsa su propia pila: Tchap para la mensajería, Visio para la videoconferencia, FranceTransfert para los archivos, agrupados en la Suite numérique. La seguridad social ya ha migrado a 80 000 agentes hacia estas herramientas. El objetivo declarado supera los dos millones de agentes de aquí a 2027. El detonante no es un capricho técnico. El regreso de las tensiones comerciales en 2025 reavivó la cuestión de la jurisdicción, y la de la CLOUD Act se volvió demasiado visible para ignorarla.

La gendarmería lo hizo hace veinte años

La novedad es la magnitud, no el principio. La Gendarmería Nacional funciona con Linux desde 2008, con GendBuntu, una versión de Ubuntu adaptada a medida. En junio de 2024 equipaba 103 164 puestos, es decir, el 97 por ciento del parque. El ahorro es claro: alrededor de dos millones de euros anuales menos en licencias, y un coste de propiedad reducido en torno al 40 por ciento.

El detalle que importa no es la cifra, es el método. La gendarmería no cambió de golpe. Empezó ya en 2004 por los componentes sin dolor, el navegador, la suite ofimática, la mensajería, el tiempo necesario para que las competencias internas y la gobernanza se construyeran. El sistema operativo llegó al final, sobre un terreno preparado. En 2026, la DINUM cita explícitamente este modelo como la pauta a seguir para los demás ministerios. La soberanía del software no se compra, se construye, capa por capa, a lo largo de años.

Abierto no significa seguro

Queda una trampa, y es exactamente la que este artículo señala desde el principio. Elegir Linux y el código abierto elimina una dependencia. No regala la seguridad. Una herramienta soberana no es una herramienta segura por construcción. Todavía hay que auditarla, fortalecerla, mantenerla, con tanto rigor como cualquier software propietario, a veces más, ya que la responsabilidad deja de subcontratarse a un editor.

La mensajería del Estado lo aprendió a su costa, al descubrir que el origen francés y el código abierto nunca eximían del trabajo de seguridad. Es incluso lo contrario: la libertad de mirar bajo el capó impone el deber de hacerlo. El código abierto hace la seguridad verificable, no la garantiza. Quien no verifica hereda una dependencia que creía haber suprimido, con la ventaja añadida de la ilusión de estar protegido.

Ese es todo el sentido de «no basta». Linux es una condición, no una respuesta. La respuesta reside en lo que se hace con la libertad que él hace posible: la competencia que se conserva, las capas que se controlan de verdad, y la seguridad que se asume en lugar de delegarla.

Fuentes

  • Free Software Foundation, definición de software libre, gnu.org
  • Open Source Initiative, Open Source Definition, opensource.org
  • Apache Software Foundation, vulnerabilidad Log4Shell (CVE-2021-44228), diciembre de 2021
  • ANSSI, recomendaciones sobre la seguridad de las plataformas de software, cyber.gouv.fr