Software libre Soberanía digital Nube Estándares abiertos
1. El problema: dependencia tecnológica del Estado
La Administración española gasta miles de millones al año en tecnologías de la información, una gran parte en licencias y servicios de unos pocos proveedores globales (Microsoft, Oracle, SAP, Amazon, Google, IBM) y en integradores locales que revenden y adaptan. Esto genera tres riesgos: coste (rentas de licencia recurrentes que crecen al cambiar los modelos de suscripción), cautividad (migrar a otro proveedor es caro por formatos propietarios y dependencias técnicas) y soberanía (los datos y servicios críticos dependen de empresas sometidas a jurisdicciones extranjeras, como la ley estadounidense CLOUD Act).
El riesgo geopolítico es real: la decisión de una empresa o de un gobierno extranjero puede cortar servicios críticos (como ocurrió con sanciones a ciertas organizaciones que perdieron acceso a servicios en la nube), o exigir acceso a datos. Para una administración que gestiona historias clínicas, datos tributarios, identidad digital y seguridad social, la dependencia de proveedores no europeos es un riesgo estratégico. La Unión Europea ha respondido con iniciativas (Gaia-X, certificación de nube, Ley de Datos, Ley de Mercados Digitales), con resultados aún modestos.
El problema no es utilizar software propietario cuando es la mejor opción, sino la ausencia de alternativas, la falta de interoperabilidad y la inercia en las decisiones de compra. Una política pública consciente podría reducir la dependencia sin renunciar a la calidad.
2. Qué ofrece el software libre y los estándares abiertos
El software libre (código abierto con licencia que permite usar, estudiar, modificar y compartir) y los estándares abiertos (formatos documentados y sin restricciones, como ODF, PDF/A, HTML, protocolos abiertos) ofrecen: auditoría pública del código, reutilización entre administraciones, menor coste de licencias, independencia del proveedor, posibilidad de adaptar a necesidades locales, y desarrollo de una industria local de servicios. En seguridad, el código abierto permite revisión por muchos ojos, aunque no garantiza ausencia de fallos.
Hay ejemplos nacionales: LinEx en Extremadura (2002), Guadalinex en Andalucía, el sistema de gestión de expedientes de varias diputaciones, las herramientas de identidad y firma electrónica (AutoFirma, Cl@ve), el software de gestión educativa de varias comunidades (Rayuela, Moodle en universidades). Internacionalmente, la Gendarmería francesa migró a Linux, el estado alemán de Schleswig-Holstein ha anunciado una migración a software libre en administración, la ciudad de Copenhague, la Comisión Europea con iniciativas de código abierto y el OSPO europeo. Otros casos, como el de Múnich con LiMux (revertido parcialmente en 2017 por decisiones políticas), muestran los riesgos de proyectos sin respaldo estable.
Las lecciones: el éxito requiere liderazgo político, personal técnico propio, formación y presupuesto sostenido; fracasa cuando se plantea como ahorro inmediato o como cruzada ideológica sin atención al usuario.
3. Costes reales de migrar y de no migrar
Migrar a software libre tiene costes: formación de usuarios, adaptación de aplicaciones, soporte técnico, compatibilidad con formatos propietarios externos, y a menudo una productividad temporalmente reducida. Estos costes son reales y muchas veces subestimados. Además, el «software libre» no es gratuito: requiere mantenimiento, contratación de servicios y personal cualificado. Los ahorros de licencias se compensan en parte con costes de soporte.
Pero el coste de no migrar también es considerable y crece: los proveedores propietarios modifican precios y condiciones con ventaja, imponen suscripciones, dificultan la salida y condicionan la interoperabilidad. En términos estratégicos, la dependencia es un coste oculto que se hace visible cuando hay una crisis. Una estrategia sensata no exige una migración total ni inmediata, sino una política gradual por casos de uso: escritorio de oficinas educativas, servidores, bases de datos, herramientas de colaboración, gestión de contenidos, plataformas educativas, software sanitario y de gestión municipal.
También es necesario considerar la nube: los servicios de computación en la nube de proveedores no europeos ofrecen ventajas técnicas, pero implican dependencia. La construcción de una nube soberana europea o nacional, con operadores locales y certificación de seguridad (Esquema Nacional de Seguridad), reduce riesgos, aunque a un coste mayor en algunos casos.
4. Interoperabilidad, datos abiertos y capacidad técnica del Estado
El Esquema Nacional de Interoperabilidad (ENI) y el Esquema Nacional de Seguridad (ENS) ya fijan principios y requisitos técnicos, pero su aplicación es desigual. Una política seria de interoperabilidad exige: catálogos comunes de servicios y datos, APIs públicas, identificadores únicos y compartición de datos entre administraciones sin pedirlos al ciudadano. La administración debe publicar sus datos en formatos abiertos con licencia libre, como base para investigación, periodismo y emprendimiento (el sector infomediario ya genera valor económico).
La capacidad técnica del Estado es el factor limitante. La Administración ha externalizado gran parte del desarrollo y el mantenimiento a grandes consultoras, y ha perdido personal técnico propio. Esto genera dependencia y encarece. Una política de soberanía digital requiere contratar y retener ingenieros y científicos de datos en la Administración, con carrera y salarios competitivos, y crear equipos nacionales de desarrollo de software público (como el GDS británico o la agencia digital estonia).
La inteligencia artificial añade urgencia: los modelos de IA se concentran en pocas empresas no europeas. Una estrategia nacional de IA debería incluir modelos abiertos, infraestructura de cómputo pública, datos de calidad en español y lenguas cooficiales y reglas de transparencia para su uso por las administraciones. La iniciativa ALIA en España es un paso en esa dirección.
5. Propuesta del taller
El taller propone una política de seis puntos. Uno: regla de «primero código abierto» en nueva contratación TIC, con justificación escrita para elegir propietario. Dos: estándares abiertos obligatorios para documentos, identidad, datos e interoperabilidad. Tres: repositorio nacional de software público reutilizable, con licencia libre y mantenimiento compartido. Cuatro: compra pública agregada de servicios TIC y de nube con requisitos de soberanía. Cinco: capacidad técnica propia del Estado con equipos de desarrollo y carrera específica. Seis: educación digital con software libre en escuelas y bibliotecas, para formar a los ciudadanos en herramientas abiertas.
Es una política de coste moderado, resultados a largo plazo y alta rentabilidad estratégica. No pretende erradicar el software propietario sino evitar la dependencia total. Un Estado que no controla su infraestructura digital no controla plenamente sus decisiones.
Tres: una estrategia de talento y formación de empleados públicos en tecnologías abiertas. Cuatro: portabilidad e interoperabilidad obligatorias en los sistemas públicos, para evitar el bloqueo con un proveedor. Cinco: reutilización de desarrollos entre administraciones mediante un repositorio común. Seis: evaluación pública del ahorro y de los riesgos de cada migración. La experiencia de algunas ciudades y países, como Múnich, Dinamarca o la gendarmería francesa, muestra tanto éxitos como reveses, por lo que conviene proceder de manera gradual y basada en pruebas piloto. Lo esencial es que la administración mantenga el control sobre sus datos y sus sistemas, que son infraestructura crítica.