Declaración de Debian sobre la Ley de Resiliencia Cibernética
Los planes de la UE para una Ley de Resiliencia Cibernética, que impondría requisitos de seguridad y responsabilidad a los “fabricantes” de software, están generando preocupación entre los desarrolladores de código abierto y las pequeñas empresas. Los comentaristas apoyan en general exigir estándares más altos a los grandes proveedores comerciales, pero temen que las definiciones vagas de “actividad comercial” y la cobertura de proyectos gratuitos o financiados por donaciones expongan a aficionados y organizaciones sin fines de lucro a grandes cargas de cumplimiento y multas. Algunos argumentan que esto podría frenar el desarrollo de código abierto en Europa o empujar a los proyectos a bloquear a usuarios de la UE, mientras que otros sostienen que una regulación significativa ya es necesaria y debe redactarse con cuidado en lugar de abandonarse.
Alcance e intención de la CRA
- Muchos comentaristas coinciden en que partes de la Ley de Resiliencia Cibernética (CRA) abordan problemas reales: prácticas de seguridad débiles, ausencia de responsabilidad legal y software “empresarial” enviado con un rigor mínimo.
- Otros piden pruebas concretas de que sea “mala”; los partidarios dicen que la responsabilidad y los estándares mínimos en software son algo atrasado, igual que en otras industrias reguladas.
Responsabilidad, analogías con seguridad y estándares
- Se repiten analogías con la seguridad alimentaria, la industria aeroespacial, la medicina, los tornillos en los coches, etc.
- Un bando: en otros campos la regulación y la estandarización llegaron primero y los hicieron más seguros; el software debería seguir ese camino, especialmente donde hay vidas en juego.
- Otro bando: la complejidad del software, el cambio rápido y la dependencia de la explotación maliciosa (frente al daño intrínseco como el veneno) hacen que las analogías directas sean débiles y que la regulación sea mucho más arriesgada.
Impacto en FOSS, aficionados y pequeñas empresas
- Preocupación central: la amplia definición de “actividad comercial” de la CRA, que incluye “sin coste” y la monetización mediante soporte, plataformas o datos.
- Temor de que:
- Proyectos de aficionados, herramientas financiadas por donaciones y pequeñas consultoras puedan incurrir en grandes cargas de cumplimiento y responsabilidad.
- Los mantenedores de código abierto (proyectos tipo log4j, OpenSSL) tendrían que seguir procesos “de nivel industrial” sin financiación equivalente.
- Esto podría empujar a muchas personas y pequeñas empresas fuera del mercado de la UE o hacer que dejen de publicar código.
Intentos de crear exenciones
- Según se informa, enmiendas posteriores intentan eximir a los desarrolladores individuales de FOSS, pero:
- Los contribuyentes asalariados y los proyectos con respaldo corporativo o donaciones recurrentes aún podrían ser tratados como “comerciales”.
- Las organizaciones sin fines de lucro y las fundaciones siguen siendo una zona gris, con riesgo de “lavado de responsabilidad” mediante fachadas FOSS.
Regulación frente a innovación y profesionalización
- Algunos sostienen que la ingeniería de software debería avanzar hacia licencias profesionales y buenas prácticas codificadas; la regulación forma parte de la maduración del campo.
- Otros advierten sobre la captura regulatoria, explosiones de costes (de 1 a 2 órdenes de magnitud) y un estancamiento “al estilo aeroespacial” donde el cambio se vuelve prohibitivamente caro.
- Hay desacuerdo sobre si la autorregulación debería haber llegado primero o si ya ha llegado “el momento del látigo”.
Licencias, bloqueos y soluciones alternativas
- Se plantearon propuestas: licencias que prohíban el uso gubernamental/UE, bloqueo de IPs de la UE o nuevas licencias FOSS que se anulen a sí mismas si surgen obligaciones regulatorias.
- Varias respuestas señalan:
- Las leyes prevalecen sobre las licencias; es probable que tales cláusulas no protejan frente a las obligaciones de la CRA.
- La discriminación basada en el uso violaría las definiciones comunes de FOSS y el contrato social de Debian, incluso si pudiera aplicarse técnicamente mediante bloqueo de infraestructura.