A União Europeia tem em cima da mesa o projeto de uma iminente ‘Lei de Resiliência Cibernética’, com a qual pretende reforçar as suas defesas contra ciberataques. Um objetivo com o qual organizações como a Linux Foundation ou a ‘Electronic Frontier Foundation’ (EFF) concordam. Ambas, porém, se posicionaram contra o rascunho devido às graves consequências que pode ter no desenvolvimento do software livre. Portanto, ao invés de proteger, essas leis ameaçam o futuro do software livre na União Europeia.
O projeto é cheio de boas intenções, e levanta uma série de preocupações necessárias depois de observar os problemas gerados pela descoberta de vulnerabilidades em componentes fundamentais do ecossistema de software.
Assim, estabelece-se uma série de boas práticas para “produtos com elementos digitais” no mercado comum europeu:
- Assegurar o produto durante toda a sua vida
- Aderir a uma estrutura de segurança cibernética coerente.
- Mostrar transparência de segurança cibernética
- Certifique-se de que os usuários usem os produtos com segurança.
Assim disse, barco em breve, sem problemas. Mas, oh, esse último ponto… parece ter sido escrito por alguém que nem sequer concebe a existência de software livre. Como você garante que o software não pode ser mal utilizado quando qualquer um pode ler e manipular seu código?
É verdade que, em alguns artigos, o texto parece isentar ‘software não comercial’ de parte desses requisitos, mas ‘aberto’ e/ou ‘livre’ não é um conceito oposto ao comercial : há software de código aberto que é vendido diretamente ou é monetizado por meio de serviços de consultoria/suporte.
Mas, ainda assim, os colaboradores que contribuem com código para projetos de software livre não podem ser equiparados a “fornecedores “: são simples voluntários que podem, na verdade, nem ter idade para trabalhar.
Leis ameaçam futuro do software livre na União Europeia. Fundações alertam para riscos
E, como lembra a própria Python Foundation, as empresas que usam seu código o obtêm de repositórios públicos , por isso não notifica os milhares de programadores que contribuíram com ele sobre seu uso. Responsabilizar os programadores neste contexto parece loucura.
Aqui se apresenta exatamente o mesmo problema que mencionamos há alguns dias ao analisar outro importante regulamento de tecnologia da UE que está próximo de sua aprovação, o regulamento regulatório de IA , que foi recentemente alterado introduzindo mudanças potencialmente desastrosas para projetos de código aberto. .
…tudo porque os legisladores veem toda a indústria de software pelas lentes do software proprietário , em que o software é imutável e qualquer bug tem uma pessoa específica e identificável por trás dele (a empresa proprietária do aplicativo). , que, além disso, pode pagar altas taxas para superar vários processos burocráticos antes do lançamento público do software.
Em suma, ou estamos perante um caso de ignorância absoluta fruto de um certo analfabetismo digital… ou simplesmente perante um viés pró-privado que procura expulsar do mercado os projectos open source, hoje essenciais em todas as áreas do software.
Em abril passado, uma carta conjunta de várias organizações pró-software livre explicou isso em termos mais diplomáticos:
Escrevemos para expressar nossa preocupação com o fato de grande parte da comunidade de código aberto ter sido sub-representada durante o desenvolvimento da Lei de Resiliência Cibernética […]. O software de código aberto representa mais de 70% do software presente em produtos com elementos digitais na Europa , no entanto, nossa comunidade teve o benefício de um relacionamento estabelecido com os colegisladores.
[…] Com esta lei, mais de 70% do software na Europa está prestes a ser regulamentado sem uma consulta aprofundada.
Finalmente, mais um problema com este rascunho, que vai além das categorias de software proprietário/aberto: esta lei exigirá que os fornecedores relatem as vulnerabilidades detectadas e o façam em até 24 horas após a detecção, o que não poderia fazer mais do que espalhar o caminho para explorar e aumentar os danos que a lei procura evitar.
Na melhor das hipóteses, pode forçar as empresas a optar por patches desleixados para sobreviver nesse período, criando assim novas vulnerabilidades em potencial.