Un software libre se define por cuatro libertades fundamentales: ejecutar el programa, estudiar su código fuente, redistribuirlo y distribuir versiones modificadas. Esta base jurídica y técnica, formalizada por la Free Software Foundation, estructura hoy un ecosistema que supera con creces el círculo de los desarrolladores. Las noticias digitales de 2026 muestran que el código abierto es ahora un asunto regulatorio, industrial y geopolítico por derecho propio.
Cyber Resilience Act: lo que el CRA cambia para los proyectos de código abierto
Desde el 11 de septiembre de 2026, las obligaciones de notificación del Cyber Resilience Act (CRA) europeo han entrado en vigor. Los fabricantes de productos que contienen elementos digitales deben notificar las vulnerabilidades que se explotan activamente y los incidentes graves, según un calendario escalonado hasta 2027.
El punto más estructurante para el mundo del software libre se refiere a la creación de una categoría jurídica específica: los open source software stewards. Este término designa a las entidades que apoyan de manera sistemática y sostenible un proyecto de código abierto con fines comerciales. Los desarrolladores individuales y los contribuyentes voluntarios quedan fuera del ámbito de las obligaciones.
La distinción parece clara sobre el papel, pero plantea preguntas concretas. Un actor que publica y mantiene regularmente en espacelibre.net recursos sobre software libre no tiene el mismo estatus que una empresa que integra un componente de código abierto en un producto vendido. En este segundo caso, el integrador puede pasar al estatus de “manufacturer” con plenas obligaciones de conformidad, incluso si el código original es libre.
Esta frontera entre el uso no comercial y la cadena de suministro comercializada se ha convertido en el verdadero tema de conformidad en 2026. Varios análisis jurídicos publicados en los últimos meses subrayan que la integración de un componente libre en un producto vendido transforma el estatus jurídico del actor.
Seguridad de la cadena de suministro de software: un proyecto de código abierto prioritario
La multiplicación de ataques a la cadena de suministro de software ha llevado a la comunidad de código abierto a estructurar sus prácticas de seguridad.
El principio central es la trazabilidad: cada componente integrado en un software debe poder ser identificado, versionado y auditado. Los SBOM (Software Bill of Materials) se están convirtiendo en un estándar esperado por los contratistas, sean públicos o privados.
- La generación y actualización de un SBOM para cada versión publicada permite identificar rápidamente un componente vulnerable en la cadena de dependencias.
- Las herramientas de firma criptográfica del código (como Sigstore) se están generalizando para garantizar la integridad de los paquetes distribuidos.
Para las empresas que utilizan bloques de código abierto, la cuestión ya no es si deben auditar sus dependencias, sino con qué frecuencia y con qué herramientas. La seguridad de la cadena de suministro de software condiciona ahora el acceso al mercado europeo.
Soberanía digital europea y software libre: más allá del discurso
La Unión Europea ha iniciado una consulta para estructurar su ecosistema de software libre, en un contexto donde la soberanía digital sigue dependiendo en gran medida de infraestructuras en la nube estadounidenses. El debate va más allá de la simple preferencia técnica: se trata de quién controla el código de las infraestructuras críticas.
En el lado de las administraciones, el movimiento de migración hacia soluciones libres continúa. El Estado francés mantiene un núcleo interministerial de software libre recomendados, que supera las quinientas referencias. Este catálogo cubre usos que van desde la ofimática hasta la gestión de bases de datos, pasando por la mensajería y las herramientas colaborativas.
El principal obstáculo sigue siendo la dependencia de formatos propietarios y del ecosistema de aplicaciones de los grandes editores. Migrar un puesto de trabajo a LibreOffice o Thunderbird no plantea una dificultad técnica mayor, pero la interoperabilidad con los socios externos que utilizan suites propietarias genera costos de fricción muy reales.
IA y código abierto: transparencia contra “open washing”
La inteligencia artificial se ha convertido en el terreno de confrontación más visible entre enfoques abiertos y cerrados. Varias organizaciones, incluida la Open Source Initiative (OSI), han alertado sobre la práctica de presentar modelos de IA como de código abierto cuando solo publican los pesos de la red, sin los datos de entrenamiento ni el código completo de la pipeline.
El término “open weights” no significa código abierto en el sentido de las cuatro libertades fundamentales. Un modelo cuyos pesos son públicos pero cuyos datos de entrenamiento permanecen en secreto no permite ni la reproducibilidad ni la auditoría independiente. Esta distinción técnica tiene consecuencias directas sobre la confianza que los usuarios y los reguladores pueden otorgar a estos sistemas.
- El EU AI Act, cuyas fechas de cumplimiento llegan en 2026, impone requisitos de transparencia que van más allá de la simple publicación de los pesos.
- Proyectos como los promovidos por la Linux Foundation trabajan para definir estándares abiertos para la certificación de agentes de IA, con un principio resumido en la fórmula “no confíes, verifica”.
La batalla de la IA de código abierto se juega en la propia definición del término “abierto”. Mientras los actores dominantes puedan calificar de código abierto modelos parcialmente abiertos, el mercado seguirá siendo opaco tanto para los usuarios como para los reguladores. Los próximos meses determinarán si los estándares en elaboración lograrán imponer una transparencia verificable, o si la etiqueta “open” seguirá siendo un argumento de marketing sin garantía técnica.
