Declaração da Debian sobre a Lei de Resiliência Cibernética
Os planos da UE para uma Lei de Resiliência Cibernética, que imporia requisitos de segurança e responsabilidade aos “fabricantes” de software, estão gerando preocupações entre desenvolvedores de código aberto e pequenas empresas. Os comentaristas, em geral, apoiam responsabilizar fornecedores comerciais maiores por padrões mais elevados, mas temem que definições vagas de “atividade comercial” e a abrangência sobre projetos gratuitos ou financiados por doações possam expor hobbyistas e organizações sem fins lucrativos a pesados encargos de conformidade e multas. Alguns argumentam que isso pode sufocar o desenvolvimento de código aberto na Europa ou levar projetos a bloquear usuários da UE, enquanto outros rebatem que uma regulamentação significativa já é necessária e deve ser redigida com cuidado, em vez de ser abandonada.
Escopo e Intenção do CRA
- Muitos comentaristas concordam que partes da Lei de Resiliência Cibernética (CRA) abordam problemas reais: práticas de segurança fracas, ausência de responsabilidade legal e software “empresarial” lançado com rigor mínimo.
- Outros pedem evidências específicas de que ela é “ruim”; os apoiadores dizem que responsabilidade e padrões mínimos estão atrasados em software, de forma semelhante a outras indústrias reguladas.
Responsabilidade, Analogias com Segurança e Normas
- Analogias repetidas com segurança alimentar, aeroespacial, medicina, parafusos em carros, etc.
- Um lado: regulação e padronização vieram primeiro em outros campos e os tornaram mais seguros; o software deveria seguir o mesmo caminho, especialmente onde vidas dependem dele.
- O outro lado: a complexidade do software, a rápida mudança e a dependência de exploração maliciosa (em vez de dano intrínseco como veneno) tornam analogias diretas fracas e a regulamentação muito mais arriscada.
Impacto em FOSS, Hobbyistas e Pequenas Empresas
- Preocupação central: a ampla definição de “atividade comercial” do CRA, incluindo “gratuito” e monetização por meio de suporte, plataformas ou dados.
- Medo de que:
- Projetos de hobby, ferramentas financiadas por doações e pequenas consultorias possam incorrer em pesados encargos de conformidade e responsabilidade.
- Mantenedores de código aberto (projetos do tipo log4j, OpenSSL) precisariam de processos de “grau industrial” sem financiamento equivalente.
- Isso poderia empurrar muitas pessoas e pequenas empresas para fora do mercado da UE ou levá-las a parar de publicar código.
Tentativas de Criar Isenções
- Emendas posteriores supostamente tentam isentar desenvolvedores individuais de FOSS, mas:
- Colaboradores empregados e projetos com apoio corporativo ou doações recorrentes ainda podem ser tratados como “comerciais”.
- Organizações sem fins lucrativos e fundações continuam sendo uma área cinzenta, com risco de “lavagem de responsabilidade” por meio de fachadas de FOSS.
Regulação vs. Inovação e Profissionalização
- Alguns argumentam que a engenharia de software deveria avançar em direção à licença profissional e a práticas recomendadas codificadas; a regulação faz parte da maturação do campo.
- Outros alertam para captura regulatória, explosões de custo (1–2 ordens de magnitude) e estagnação “estilo aeroespacial”, em que mudanças se tornam proibitivamente caras.
- Há discordância sobre se a autorregulação deveria ter vindo primeiro, ou se “a hora do chicote” já chegou.
Licenciamento, Bloqueio e Alternativas
- Propostas levantadas: licenças que proíbam o uso por governos/UE, bloqueio de IPs da UE ou novas licenças FOSS que se anulem se surgirem deveres regulatórios.
- Várias respostas observam:
- Leis se sobrepõem a licenças; tais cláusulas provavelmente não protegem contra deveres do CRA.
- Discriminação baseada no uso violaria definições comuns de FOSS e o contrato social da Debian, mesmo que tecnicamente aplicável por meio de bloqueio de infraestrutura.