From 1ae0306a3cf2ea27f60b2d205789994d260c2cce Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Sun, 11 Oct 2020 13:29:45 +0200 Subject: add i18n FSFS --- .../articles/br/fighting-software-patents.html | 156 +++++++++++++++++++++ 1 file changed, 156 insertions(+) create mode 100644 talermerchantdemos/blog/articles/br/fighting-software-patents.html (limited to 'talermerchantdemos/blog/articles/br/fighting-software-patents.html') diff --git a/talermerchantdemos/blog/articles/br/fighting-software-patents.html b/talermerchantdemos/blog/articles/br/fighting-software-patents.html new file mode 100644 index 0000000..c9562b1 --- /dev/null +++ b/talermerchantdemos/blog/articles/br/fighting-software-patents.html @@ -0,0 +1,156 @@ + + + + + + +Combatendo Patentes de Software - Uma a uma e Todas Juntas - Projeto GNU - +Free Software Foundation + + + +

Combatendo Patentes de Software - Uma a uma e Todas Juntas

+ +

por Richard Stallman

+ +

+Patentes de software são equivalentes a minas terrestres num projeto de +software: cada decisão sobre o visual carrega o risco de pisar numa patente, +que pode destruir o seu projeto.

+

+Desenvolver um programa grande e complexo significa combinar várias ideias, +quase sempre centenas ou milhares delas. Num país que permite patentes de +software, as chances são de que alguma fração substancial das ideias no seu +programa já vão estar patenteadas por várias companhias. Talvez centenas de +patentes vão cobrir partes do seu programa. Um estudo feito em 2004 +encontrou quase 300 patentes americanas que cobriam várias partes de um +único programa importante. É tão trabalhoso realizar tal estudo que apenas +um foi feito até agora.

+

+Em termos práticos, se você é um desenvolvedor de software, você vai +normalmente ser ameaçado por uma patente algumas vezes. Quando isso +acontece, você pode sair ileso se você encontrar fundamentos legais para +derrubar a patente. Você pode tentar; se você tiver sucesso, isso vai +significar uma mina a menos no campo minado. Se essa patente for +particularmente ameaçadora para o público, a Fundação pelas Patentes Públicas +(pubpat.org) pode se interessar pelo caso; essa é a especialidade +dela. Se você pedir ajuda para a comunidade usuária de computadores para +procurar por uma publicação prévia da mesma ideia, para utilizar como prova +para derrubar a patente, nós todos deveríamos responder com qualquer +informação útil que nós podemos ter.

+

+No entanto, combater patentes uma por uma nunca vai eliminar o perigo das +patentes de software, da mesma forma que esmagar mosquitos nunca vai +eliminar a malária. Você não pode esperar ser capaz de derrotar todas as +patentes que ameaçam você, mais do que você pode esperar matar cada monstro +em um jogo de video game: mais cedo ou mais tarde, alguma vai derrotar você +e danificar o seu programa. O escritório de patentes dos Estados Unidos +emite cerca de cem mil patentes de software por ano; nossos melhores +esforços não conseguiram eliminar essas minas tão rápido quanto eles +instalam mais.

+

+Algumas destas minas são impossíveis de se eliminar. Cada patente de +software é danosa, e cada patente de software restringe você injustamente de +como usar o seu computador, mas nem toda a patente de software é legalmente +inválida de acordo com os critérios do sistema de patentes. As patentes de +software que nós podemos derrubar são aquelas que resultam de “erros”, onde +as regras do sistema de patentes não foram apropriadamente obedecidas. Não +há nada que nós possamos fazer quando o único erro relevante foi a política +de permitir patentes de software.

+

+Para tornar parte do castelo segura, você deve fazer mais do que matar os +monstros a medida que eles vão aparecendo — você deve eliminar o gerador que +os produz. Derrubar patentes existentes uma por uma não vai tornar a +programação segura. Para fazê-lo, nós devemos modificar o sistema de +patentes de maneira que as patentes não possam mais ameaçar desenvolvedores +de software e usuários.

+

+Não existe conflito entre essas duas campanhas: nós podemos trabalhar na +saída a curto prazo e no reparo a longo prazo de uma vez só. Se nós tomarmos +cuidado, nós podemos fazer com que os nossos esforços para derrubar patentes +de software individuais realizar uma dupla tarefa, construindo suporte para +os esforços para corrigir o problema inteiro. O ponto crucial é não igualar +patentes de software “más” com patentes de software erradas ou +inválidas. Cada vez que nós invalidamos uma patente de software, cada vez +que nós falamos dos nosso planos de tentar, nós devemos dizer em termos não +incertos, “Uma patente de software a menos, uma ameaça a menos para os +programadores: o alvo é zero”.

+

+A batalha contra patentes de software na União Europeia está chegando a um +estágio crucial. O Parlamento Europeu votou há um ano atrás para rejeitar +patentes de software de forma conclusiva. Em maio, o Conselho de Ministros +votou para desfazer as modificações do Parlamento e tornar a diretiva ainda +pior do que quando começou. No entanto, pelo menos um país que contribuiu +para isso já reverteu o seu voto. Nós todos devemos fazer o máximo agora +para convencer um país europeu a mais para mudar o seu voto, e para +convencer os novos membros eleitos do Parlamento Europeu para manter o voto +de antes. Acesse www.ffii.org para mais +informações sobre como ajudar, e para entrar em contato com outros +ativistas.

+
+ + +
+ + + + + + + + -- cgit v1.2.3