La Unión Europea tiene sobre la mesa el borrador de una inminente ‘Ley de Resiliencia Cibernética‘, con la que busca reforzar sus defensas contra ciberataques. Un objetivo con el que está de acuerdo organizaciones como la Linux Foundation o la ‘Electronic Frontier Foundation’ (EFF)… ambas, sin embargo, se han posicionado en contra del borrador por las graves repercusiones que puede tener sobre el desarrollo de software libre.

Mirándolo por encima, el proyecto está lleno de buenas palabras, y recoge una serie de preocupaciones necesarias tras observar los problemas generados por el descubrimiento de vulnerabilidades en componentes fundamentales del ecosistema de software (todos recordamos el fiasco de Log4J y la reacción que eso generó).

Así, se establecen una serie de buenas prácticas para los “productos con elementos digitales” en el mercado común europeo:

• Asegurar el producto durante toda su vida
• Apegarse a un marco coherente de ciberseguridad.
• Mostrar transparencia de ciberseguridad
• Garantizar que los usuarios usen los productos de forma segura.

Así dicho, y a bote pronto, ningún problema. Pero, ay, ese último punto… parece haber sido escrito por alguien que ni tan siquiera concibe la existencia del software libre. ¿Cómo garantizas que un software no puede ser mal usado cuando cualquiera puede leer y manipular su código?

Es cierto que, en algunos artículos, el texto parece eximir de parte de estos requisitos al ‘software no comercial’, pero es que ‘abierto’ y/o ‘libre’ no es un concepto opuesto a comercial: hay software open source que se vende directamente, o que se monetiza mediante servicios de consultoría/soporte.

Pero, incluso así, los colaboradores que realizan sus aportaciones de código a proyectos de software libre no pueden ser equiparados a “proveedores“: son simples voluntarios que pueden, de hecho, no tener ni edad para trabajar.

Y, como recuerda la mismísima Fundación Python, las empresas que usan su código lo obtienen de repositorios públicos, por lo que no notifica a los miles de programadores que contribuyeron al mismo del uso que le dan. Imputar responsabilidades a los programadores en ese contexto parece una locura.

Se presenta aquí exactamente el mismo problema que comentábamos hace unos días al analizar otra importante normativa tecnológica de la UE que está próxima a su aprobación, el reglamento regulador de la IA, que recientemente ha sido enmendado introduciendo cambios potencialmente desastrosos para los proyectos open source…

…todo debido a que los legisladores ven toda la industria del software a través de la lente del software privativo, en el que el software es inmodificable y en el que cualquier error tiene detrás un responsable concreto e identificable (la compañía propietaria de la aplicación), el cual, además, puede pagar abultadas tasas para superar múltiples procesos burocráticos previos al lanzamiento público del software.

En resumen, o estamos ante un caso de absoluto desconocimiento producto de un cierto analfabetismo digital… o sencillamente ante un sesgo pro-privativo que busca expulsar del mercado a los proyectos open source, hoy en día fundamentales en todos los ámbitos del software.

El pasado mes de abril, una carta conjunta de diversas organizaciones pro-software libre explicaba esto mismo en términos más diplomáticos:

“Escribimos para expresar nuestra preocupación por el hecho de que gran parte de la comunidad de código abierto haya estado subrepresentada durante el desarrollo de la Ley de Resiliencia Cibernética […]. El software de código abierto representa más del 70% del software presente en productos con elementos digitales en Europa. Sin embargo, nuestra comunidad ha contado con el beneficio de una relación establecida con los colegisladores.

[…] Con esta ley, más del 70% del software en Europa está a punto de ser regulado sin una consulta en profundidad”.

Por último, otro problema más de este borrador, que va más allá de las categorías de software propietario/abierto: esta ley requerirá que los proveedores informen sobre vulnerabilidades detectadas, y que lo hagan, además, dentro de las 24 horas desde su detección, lo que podría no hacer más que difundir la manera de explotarlas y aumentar los daños que la ley pretende evitar.

En el mejor de los casos, puede forzar a las empresas a optar por parches chapuceros para salir del paso en ese margen de tiempo, generando así nuevas potenciales vulnerabilidades.

En Ciberpro | En esta web consigues alternativas open source a software y servicios que usan las empresas en su día a día