La UE acaba de poner el software de código abierto en el centro de la soberanía tecnológica europea. Nosotros ya estábamos preparados.
La cifra que debería hacer reflexionar a cada CIO europeo
Recientemente, la Comisión Europea publicó el Paquete de Soberanía Tecnológica Europea. Incluye la Ley de Chips 2.0, la Ley de Desarrollo de la Nube e IA, una Hoja de Ruta Estratégica para la Digitalización e IA en Energía y, por primera vez en la historia de la política digital de la UE, una Estrategia de Código Abierto de la UE completa.
El dato principal en la hoja informativa: 264.000 millones de euros gastados anualmente en productos y servicios de terceros países. Esa es la cifra que debería hacer que cada CIO europeo y responsable de compras se detenga y lea el documento con atención. No son 264 millones. Son 264.000 millones. Cada año. Que fluyen principalmente hacia un puñado de grandes proveedores de software y nube propietarios, organizaciones cuyas condiciones de servicio, precios, hojas de ruta de producto y políticas de acceso a datos se deciden en salas de juntas sin rendir cuentas a las instituciones o ciudadanos europeos.
La presidenta de la Comisión, Ursula von der Leyen, lo expresó claramente: «No podemos permitirnos depender de otros para las tecnologías que mantienen en funcionamiento nuestros hospitales, nuestras redes energéticas estables y nuestros servicios seguros. Se trata de proteger a nuestros ciudadanos, defender nuestros intereses y tomar nuestras propias decisiones».
Eso no es una declaración de política tecnológica. Es una declaración geopolítica. Y llega en un momento en el que la presión geopolítica sobre la infraestructura digital europea es mayor que en cualquier otro desde el RGPD.
El código abierto ya no es una nota al pie
Los documentos anteriores de estrategia digital de la UE mencionaban el código abierto de pasada. Un punto aquí, una referencia al ecosistema de Software Libre y de Código Abierto (FOSS) allá. El Paquete de Soberanía Tecnológica es diferente. La Estrategia de Código Abierto de la UE sitúa el código abierto en el centro de la soberanía tecnológica europea. La Ley de Desarrollo de la Nube e IA reafirma el compromiso de la Comisión de trabajar hacia un entorno digital abierto, colaborativo y resiliente.
La Comisión traza explícitamente una línea entre el vendor lock-in y la vulnerabilidad estratégica, planteando la concentración de la infraestructura digital de la UE en manos de unos pocos proveedores propietarios dominantes no solo como un problema de competencia, sino como una vulnerabilidad estratégica. Es un cambio importante. Durante años, el argumento a favor del código abierto en la contratación pública era económico (menor coste total de propiedad) o ideológico (bienes digitales comunes). El Paquete de Soberanía Tecnológica lo convierte en un asunto estratégico. La dependencia de software propietario de proveedores que no controlas limita la soberanía digital. Esa es la postura de la Comisión, en un documento de política pública.
La hoja informativa también destaca que hay 3 millones de contribuidores de código abierto en Europa desarrollando soluciones digitales. Esa es la fuerza laboral. Ahora la estrategia, los contribuidores y la voluntad política están alineados.
Lo que realmente exige la «soberanía»
Aquí quiero ser preciso, porque «soberanía digital» se ha convertido en una etiqueta que cualquier proveedor de nube pone en su centro de datos de Frankfurt y da por terminado el asunto.
La verdadera soberanía tiene cuatro requisitos. El Paquete de Soberanía Tecnológica, para su mérito, aborda los cuatro.
- Debes poder ejecutar el software tú mismo.
Una «nube soberana» donde el código es propietario y el proveedor puede cancelar tu licencia, cambiar las condiciones o acceder a tus datos cuando quiera, no es soberana. Es una tenencia con lenguaje de marketing. Esto aplica sin importar dónde tenga su sede el proveedor. Un vendor lock-in propietario con centro de datos en Frankfurt sigue siendo un lock-in. El código abierto con capacidad de autohospedaje es el punto de partida. La Ley de Desarrollo de la Nube e IA introduce un marco de evaluación de soberanía precisamente porque la Comisión entiende esta diferencia. - Debes entender qué hay dentro del software.
La seguridad en la cadena de suministro no es una palabra de moda. Es la cuestión de si sabes qué código de terceros se ejecuta en tu infraestructura, de dónde viene y si ha sido auditado. Los SBOM (listas de materiales de software), las compilaciones firmadas y las políticas de divulgación de vulnerabilidades son la expresión operativa de la soberanía en el software. - Debes tener una gobernanza verificable.
Un proveedor que dice «estamos comprometidos con el código abierto» sin una carta de gobernanza publicada, sin un consejo asesor comunitario, sin un proceso definido para la toma de decisiones, está haciendo una promesa de marketing, no un compromiso estructural. La Estrategia de Código Abierto aborda esto exigiendo capacidades organizativas y de gobernanza que sostengan los proyectos de código abierto a lo largo del tiempo. - Debes tener claridad legal.
Las licencias de código abierto no son todas iguales. La licencia Apache 2.0 es permisiva, segura para compras públicas y compatible con la mayor variedad de requisitos empresariales y del sector público en Europa. AGPL es una licencia copyleft, lo que significa que el software que la incorpora puede estar obligado a liberarse bajo los mismos términos (a menudo un obstáculo en la contratación pública propietaria). Entender tu stack de licencias es parte de la higiene soberana en las compras.
Lo que construimos antes de que llegara la política
ownCloud se fundó en 2010 en Alemania. Lleva dieciséis años implementándose en escuelas europeas, organismos gubernamentales, instituciones de investigación y nubes del sector público. Millones de usuarios confían en oCIS.
El 5 de mayo, un mes antes de la publicación de este paquete, lanzamos la Oficina de Programas de Código Abierto (OSPO) de Kiteworks. Todo lo que presentamos en el lanzamiento de nuestra OSPO encaja directamente con lo que ahora exige el Paquete de Soberanía Tecnológica a nivel de política:
Apache 2.0 por defecto.
oCIS utiliza la licencia Apache 2.0. Los nuevos repositorios se crean por defecto bajo Apache 2.0. Sin riesgo copyleft en tus compras. Sin ambigüedad de licencias utilizada como palanca comercial. Lo dejamos por escrito en nuestro manifiesto.
CLA retirado, DCO adoptado.
Los contribuidores mantienen sus derechos de autor. Esto es clave para la soberanía porque significa que ningún proveedor posee todo el código. El código pertenece a quienes lo escribieron, licenciado al mundo bajo Apache 2.0.
Carta de gobernanza publicada.
No es lenguaje aspiracional. Es un documento con roles definidos, procesos de toma de decisiones, resolución de conflictos, cronograma del Consejo Asesor Comunitario y un periodo de comentarios públicos de 30 días para cualquier cambio de política. Explica explícitamente que Kiteworks dirige la hoja de ruta y detalla los mecanismos comunitarios para influir en esa dirección. Ese es el compromiso estructural que exige la Estrategia de Código Abierto.
SBOM, compilaciones firmadas, VDP.
La seguridad en la cadena de suministro no es teórica para nosotros. Publicamos una política de divulgación de vulnerabilidades, gestionamos un programa de recompensas de errores en YesWeHack, generamos SBOM por versión, firmamos nuestras imágenes de contenedores y publicamos registros de gestión de parches. A principios de este año gestionamos un compromiso en la cadena de suministro (CVE-2026-33634, Trivy) con un informe público de incidente, notificaciones a clientes afectados en su idioma e imágenes actualizadas dentro de la ventana de exposición. Eso es soberanía bajo presión, no solo en la presentación de marketing.
12 documentos publicados.
Visión, misión, manifiesto, carta de gobernanza, política de contribución en IA, política de divulgación de seguridad, guía de contribución, lecciones aprendidas, código de conducta, participación, empoderamiento, visión de producto (más información en nuestra página OSPO). Cada compromiso está por escrito y es verificable públicamente.
Por qué la OSPO es la estructura adecuada
El Paquete de Soberanía Tecnológica aborda el código abierto a nivel de política. Las OSPO (Oficinas de Programas de Código Abierto) son la estructura organizativa que convierte la política en acción dentro de empresas e instituciones públicas.
La Estrategia de Código Abierto de la Comisión es el paso más importante de Europa hasta la fecha para usar el código abierto como vía hacia un futuro digital soberano y resiliente. Pero una estrategia sin implementación es solo un documento. La OSPO de Kiteworks existe para hacer que la implementación de ownCloud sea concreta: una política de seguridad publicada, una vía definida para contribuidores, una estructura de gobernanza comunitaria y un modelo de soporte comercial que hace sostenible el producto de código abierto sin comprometer su apertura.
Los cuatro elementos de nuestro modelo comercial responden directamente a lo que el sector público europeo necesita para implementar código abierto de forma responsable:
- Soporte y SLA.
El código es gratuito. Que alguien responda a las 2 a.m. cuando tu sala de datos virtual falla, no lo es. Los niveles de soporte ofrecen a las organizaciones del sector público la respuesta contractual que necesitan para infraestructuras críticas. - Compilaciones reforzadas y SBOM.
Al auditor no le basta con el enlace de GitHub. Necesita un SBOM firmado, un registro de gestión de parches y una declaración del proveedor. Nosotros entregamos los tres. - Documentación de cumplimiento.
Las organizaciones públicas en Alemania y en toda la UE operan bajo estos marcos. Nuestras suscripciones de Kiteworks incluyen el mapeo de cumplimiento, el soporte para auditorías y el contacto dedicado de cumplimiento que hacen que ownCloud sea auditable en contextos regulados. - Protección legal.
Apache 2.0 es permisiva. Nuestras suscripciones de soporte añaden indemnización de propiedad intelectual para las organizaciones que necesitan un proveedor que respalde la licencia.
La cifra que importa
264.000 millones de euros. Cada año. Que van a proveedores cuyas hojas de ruta, precios y condiciones las organizaciones europeas no pueden influir de manera significativa.
El Paquete de Soberanía Tecnológica no va a cambiar esa cifra de la noche a la mañana. Los procesos legislativos llevan tiempo. Los ciclos de compras son largos. Los hábitos institucionales son difíciles de cambiar.
Pero la dirección está marcada. La UE quiere fortalecer la capacidad europea en semiconductores, IA, computación en la nube y código abierto. La Estrategia de Código Abierto, los requisitos de soberanía de la Ley de Desarrollo de la Nube e IA, el mandato de código abierto en el sector público: estas son las condiciones estructurales para que existan alternativas abiertas, gobernadas y auditables como estándar.
El problema nunca fue dónde tiene su sede el proveedor. Es si puedes auditar el código, bifurcarlo si lo necesitas, verificar la cadena de suministro y ejecutarlo en tu propia infraestructura bajo tu propio marco legal. El vendor lock-in falla en las cuatro pruebas. El código abierto, bien hecho, supera las cuatro.
ownCloud ha sido esa alternativa desde 2010. La OSPO convierte los compromisos de gobernanza y comunidad en algo estructural, no solo verbal. Y el Paquete de Soberanía Tecnológica, publicado recientemente, confirma que lo que hemos estado construyendo es exactamente lo que ahora exige la política digital europea.
El momento no es casualidad. El problema lleva años siendo visible. Nosotros llevamos tiempo trabajando en la respuesta.
—
Lee la hoja informativa de Soberanía Tecnológica de la UE: ec.europa.eu/commission/presscorner
ownCloud OSPO: kiteworks.com/opensource · owncloud.com/blogs
Prueba oCIS: github.com/owncloud/ocis · owncloud.dev
David Walter es VP de la Oficina de Programas de Código Abierto en Kiteworks, donde lidera la gobernanza, las licencias y la participación comunitaria de código abierto para ownCloud. Forma parte del ecosistema ownCloud desde 2014.