Divulgamos anteriormente que a União Europeia está discutindo uma nova lei que responsabiliza os desenvolvedores de software por defeitos em seus produtos.
Essa proposta busca equiparar softwares a outros produtos, como eletrodomésticos, aplicando os mesmos princípios de responsabilidade civil.
O objetivo do projeto de lei é aumentar a segurança dos softwares e proteger os consumidores de danos causados por defeitos.
E incentivar os desenvolvedores a investir mais em qualidade e segurança, reduzindo o número de softwares com “problemas”.
E, com isso, estabelecer um padrão claro de responsabilidade, evitando que os desenvolvedores se isentem de culpa por danos causados por seus produtos.
Responsabilidade que é estendida a todos os desenvolvedores, independentemente de terem sido negligentes ou não.
Exigindo que os desenvolvedores demonstrem que um defeito não era detectável dado o conhecimento técnico da época.
A projeto de lei considera não só danos materiais e físicos, como os causados pela perda ou destruição de dados.
Por quê software não tem garantia?
A percepção de que software não tem garantia é um equívoco comum. Na verdade, ela existe, mas apresenta algumas particularidades em relação a produtos físicos.
Softwares são produtos intangíveis, o que dificulta a definição de um defeito de forma tão clara quanto em um produto físico.
E estão em constante desenvolvimento, recebendo atualizações e correções de bugs. Isso torna a garantia mais complexa, pois um problema pode ser resolvido com uma nova versão.
O funcionamento de um software muitas vezes depende de outros softwares, hardware e configurações do sistema, o que pode dificultar a identificação da causa de um problema.
Tipos de garantias
No Brasil, o Código de Defesa do Consumidor se aplica aos softwares, garantindo os direitos básicos do consumidor, como a possibilidade de reclamar por vícios ou defeitos.
Muitas empresas oferecem garantias contratuais, com prazos e condições específicas que podem incluir suporte técnico, correções de bugs e até reembolso em caso de insatisfação.
O projeto europeu força as empresas a fornecer informações mais claras sobre as garantias oferecidas para seus softwares.
E o software livre?
A questão da responsabilidade por defeitos em softwares livres e open source (FOSS) é complexa e ainda suscita debates.
A lei, em sua concepção inicial, buscava responsabilizar os desenvolvedores de software por qualquer defeito, independentemente da natureza do software. Isso incluía, em princípio, tanto softwares comerciais quanto FOSS.
No entanto, diversas considerações foram levantadas, que impactam na aplicabilidade da lei:
-
a natureza colaborativa do projeto, onde programadores localizam-se em países distintos sem uma estrutura empresarial tradicional. Isso dificulta a identificação de um único responsável por um eventual defeito.
-
as licenças FOSS, por definição, permitem a modificação e distribuição do software por terceiros. Um defeito pode ser introduzido por terceiros, sem que o desenvolvedor original tenha controle sobre isso.
-
softwares FOSS oferecem inúmeros benefícios para a sociedade, como maior transparência, segurança e inovação. Impossibilitar a sua utilização ou desenvolvimento livre poderia comprometer esses benefícios.
Diante dessas considerações, a lei europeia, em sua versão final, parece ter excluído a responsabilidade direta dos desenvolvedores de softwares FOSS por danos causados por defeitos.
A justificativa é que esses softwares podem ser alterados por terceiros e os programadores não podem ser responsabilizados por danos causados por eles.
Mesmo que os desenvolvedores de FOSS não sejam diretamente responsabilizados, terceiros podem sê-lo, como empresas que oferecem suporte ou serviços relacionados ao software.
Dois pesos, duas medidas?
Para a Fundação Python Software (PSF) o projeto de lei “criaria um efeito inibidor” que causa “danos irreparáveis” quando replicados em outras partes da cadeia de suprimentos de software, fazendo os desenvolvedores correrem para limitar suas responsabilidades.
O que deixaria as organizações e desenvolvedores de código aberto injustamente responsáveis pela distribuição de código incorreto.
Ela argumenta que responsabilizar os desenvolvedores de código aberto pelas contribuições de código desencorajaria quem contribui com os mesmos.
E que se deveria isentar os “repositórios públicos de software que servem o bem público — e para organizações e desenvolvedores que hospedam pacotes em repositórios públicos”.
Qualquer indivíduo que alterasse substancialmente um projeto de código aberto, seria responsável pelas consequências dessa mudança.
Teme-se que esse projeto de lei gere uma indústria de ações judiciais, com limites de responsabilidade difíceis de definir e, com isso, muitos indivíduos e/ou organizações arquem com responsabilidades que não lhes compete.
Embora as organizações/desenvolvedores de software possam e devam testar a segurança de seus produtos, a segurança completa é impossível de garantir.
Mas não se pode negar que falhas de segurança “mantêm o software e cadeias de suprimentos inteiras vulneráveis”, necessitando-se de regulação para que os desenvolvedores construam tecnologias seguras e protegidas.
Fontes: