summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/br/shouldbefree.html
diff options
context:
space:
mode:
Diffstat (limited to 'talermerchantdemos/blog/articles/br/shouldbefree.html')
-rw-r--r--talermerchantdemos/blog/articles/br/shouldbefree.html908
1 files changed, 908 insertions, 0 deletions
diff --git a/talermerchantdemos/blog/articles/br/shouldbefree.html b/talermerchantdemos/blog/articles/br/shouldbefree.html
new file mode 100644
index 0000000..00339db
--- /dev/null
+++ b/talermerchantdemos/blog/articles/br/shouldbefree.html
@@ -0,0 +1,908 @@
+<!--#set var="ENGLISH_PAGE" value="/philosophy/shouldbefree.en.html" -->
+
+<!--#include virtual="/server/header.pt-br.html" -->
+<!-- Parent-Version: 1.86 -->
+
+<!-- This file is automatically generated by GNUnited Nations! -->
+<title>Por que o Software Deveria Ser Livre - Projeto GNU - Free Software
+Foundation</title>
+
+<!--#include virtual="/philosophy/po/shouldbefree.translist" -->
+<!--#include virtual="/server/banner.pt-br.html" -->
+<h2>Por que o Software Deveria Ser Livre</h2>
+
+<p>
+por <a href="http://www.stallman.org/"><strong>Richard Stallman</strong></a></p>
+<h3 id="introduction">Introdução</h3>
+<p>
+A existência do software inevitavelmente levanta questões a respeito de como
+deveria ser feito seu uso. Por exemplo, suponha que um indivíduo que tem uma
+cópia de um programa se encontre com outro que gostaria de ter uma cópia. É
+possível a eles copiar o programa; quem deveria decidir se isto deve ser
+feito ou não? Os indivíduos envolvidos? Ou outra parte, chamada de “o
+proprietário”?</p>
+<p>
+ Desenvolvedores de software tipicamente consideram estas questões assumindo
+que o critério para a resposta seja maximizar os lucros dos
+desenvolvedores. A força política do negócio tem levado à adoção, por parte
+do governo, tanto deste critério quanto da resposta proposta pelos
+desenvolvedores: o programa tem um proprietário, tipicamente uma empresa
+associada ao seu desenvolvimento.</p>
+<p>
+ Eu gostaria de considerar a mesma questão usando um critério diferente: a
+prosperidade e liberdade do público em geral.</p>
+<p>
+ Esta resposta não pode ser dada pela lei atual — a lei deveria agir em
+conformidade com a ética, não o contrário. Nem a prática comum decide esta
+questão, apesar de sugerir respostas possíveis. A única maneira de julgar é
+ver quem é beneficiado e quem é prejudicado pelo reconhecimento dos
+proprietários de software, porque, e quanto. Em outras palavras, nós
+deveríamos fazer uma análise de custo-benefício tomando por base a sociedade
+como um todo, levando em conta a liberdade individual bem como a produção de
+bens materiais.</p>
+<p>
+ Neste ensaio, eu irei descrever os efeitos de ter proprietários e mostrarei
+que os resultados são malignos. Minha conclusão é que programadores têm a
+responsabilidade de encorajar outros a compartilhar, redistribuir, estudar e
+melhorar o software que nós escrevemos: em outras palavras, escrever <a
+href="/philosophy/free-sw.html">software “livre”</a>.<a href="#f1">(1)</a></p>
+
+<h3 id="owner-justification">Como os Proprietários Justificam Seu Poder</h3>
+<p>
+ Aqueles que se beneficiam do sistema atual onde programas são propriedade
+oferecem dois argumentos em suporte à suas reivindicações: o argumento
+emocional e o econômico.</p>
+<p>
+ O argumento emocional é mais ou menos assim: “Eu coloquei meu suor, meu
+coração, minha alma neste programa. Ele veio de <em>mim</em>, é
+<em>meu</em>!”</p>
+<p>
+ Este argumento não requer uma refutação pesada. O sentimento de ligação pode
+ser cultivado pelos programadores quando lhes convém; não é
+inevitável. Considere, por exemplo, quão sinceramente os mesmos
+programadores transferem todos os seus direitos à uma grande empresa em
+troca de um salário; a ligação emocional misteriosamente
+desaparece. Contrastando, considere os grandes artistas e artesãos dos
+tempos medievais, que nem mesmo assinavam seus nomes na sua obra. Para eles,
+o nome do artista não era importante. O que importava era que o trabalho
+havia sido feito — e o propósito ao qual ele serviria. Esta concepção
+prevaleceu durante séculos.</p>
+<p>
+ O argumento econômico se parece com: “Eu quero ficar rico (que via de regra
+é descrito imprecisamente como &lsquo;ganhar a vida&rsquo;), e se você não
+me permitir ficar rico programando, então eu não vou programar. Todos os
+outros são como eu, sendo assim ninguém mais vai programar. E então você vai
+acabar ficando sem programas!” Esta ameaça é normalmente velada, como um
+conselho de amigo.</p>
+<p>
+ Depois eu irei explicar que esta ameaça é um blefe. Primeiro eu quero focar
+uma concepção que é mais visível em outra formulação do argumento.</p>
+<p>
+ Esta formulação começa comparando a utilidade social de um programa
+proprietário versus a da inexistência deste programa, e então conclui que o
+desenvolvimento de software proprietário é, no todo, benéfico e deveria ser
+encorajado. A falácia aqui está em comparar apenas dois pontos — software
+proprietário versus inexistência do software — e assumir que não existem
+outras possibilidades.</p>
+<p>
+ Dado um sistema de copyright sobre programas, o desenvolvimento de software
+comumente está ligado à existência de um proprietário que controla o uso do
+software. Enquanto existe esta ligação, nós frequentemente nos deparamos com
+a opção entre software proprietário ou nada. No entanto, esta ligação não é
+natural ou inevitável; é uma consequência da escolha da política sócio-legal
+que nós estamos questionando: a decisão de ter proprietários. Formular a
+opção como sendo entre software proprietário versus software inexistente é
+desvirtuar a questão.</p>
+
+<h3 id="against-having-owners">O Argumento Contra Ter Proprietários</h3>
+<p>
+ A questão é: “O desenvolvimento de software deveria ser ligado a ter
+proprietários para restringir sua utilização?”</p>
+<p>
+ Para que nós possamos escolher, temos que julgar o efeito na sociedade de
+cada uma destas duas atividades <em>independentemente</em>: o efeito de
+desenvolver software (sem levar em consideração seus termos de
+distribuição), e o efeito de restringir sua utilização (assumindo que o
+software tenha sido desenvolvido). Se uma destas atividades ajuda e a outra
+atrapalha, nós estaríamos melhor descartando esta ligação e fazendo apenas a
+atividade que ajuda.</p>
+<p>
+ Colocando em outras palavras, se a restrição da distribuição de um programa
+já desenvolvido é prejudicial à sociedade como um todo, então um
+desenvolvedor ético irá rejeitar a opção de trabalhar deste modo.</p>
+<p>
+ Para determinar o efeito de restringir o compartilhamento, nós precisamos
+comparar o valor para a sociedade de um programa restrito (por exemplo
+proprietário) com o valor do mesmo programa, disponível para todos. Isto
+significa comparar dois mundos possíveis.</p>
+<p>
+ Esta análise também leva em consideração o contra-argumento feito às vezes
+que “o benefício ao próximo de lhe dar uma cópia de um programa é cancelado
+pelo dano feito ao proprietário.” Este contra-argumento assume que o dano e
+o benefício são de igual grandeza. A análise envolve comparar estas duas
+grandezas, e mostra que os benefícios são muito maiores.</p>
+<p>
+ Para elucidar este argumento, vamos aplicá-lo a outra área: construção de
+vias públicas.</p>
+<p>
+ Seria possível financiar a construção de todas as vias com pedágios. Isto
+iria exigir que houvesse postos de cobrança de pedágio em todas as
+esquinas. Tal sistema produziria um grande incentivo para melhorar as
+estradas. Teria também a virtude de fazer com que os usuários de qualquer
+estrada pagassem por ela. No entanto, um posto de cobrança de pedágio é um
+obstáculo artificial à condução suave de um veículo — artificial porque não
+é uma consequência de como estradas ou carros funcionam.</p>
+<p>
+ Comparando a utilidade das estradas gratuitas com a utilidade das estradas
+onde há cobrança de pedágio, nós concluímos que (sendo igual todo o
+restante) estradas sem pedágio são mais baratas de construir, mais baratas
+para se usar, mais seguras e mais eficientes.<a href="#f2">(2)</a> Em uma
+nação pobre, pedágios podem tornar as estradas proibitivas para muitos
+cidadãos. As estradas sem pedágio oferecem assim mais benefícios à sociedade
+a um custo menor; elas são preferíveis para a sociedade. Sendo assim, a
+sociedade deveria se decidir por financiar as estradas de outra maneira, e
+não por meio de pedágio. O uso das estradas, uma vez construídas, deveria
+ser gratuito.</p>
+<p>
+ Quando os defensores dos pedágios os propõem <em>meramente</em> como um modo
+de levantar fundos, eles distorcem a opção que é disponível. Pedágios
+arrecadam fundos, mas eles fazem algo além disso: em efeito, eles degradam a
+estrada, no sentido de que a estrada com pedágio não é tão boa quanto a
+gratuita; nos fornecer estradas em maior quantidade ou tecnicamente
+superiores pode não ser uma melhoria se isto significa substituir as vias
+gratuitas pelas vias com pedágio.</p>
+<p>
+ É claro que a construção de uma estrada sem pedágio custa dinheiro, que o
+público deve pagar de algum modo. No entanto, isto não implica
+necessariamente na existência de postos de pedágio. Nós, que em qualquer dos
+casos estaremos pagando, faremos melhor negócio adquirindo uma estrada livre
+de pedágio.</p>
+<p>
+ Eu não estou aqui dizendo que uma estrada com pedágio é pior que ficar sem
+estrada. Isto seria verdade se a tarifa fosse tão alta que dificilmente
+alguém usasse a estrada — mas isto é uma política pouco provável para um
+arrecadador de impostos. No entanto, uma vez que os pedágios causem um
+desperdício e inconveniência significativos, é melhor levantar fundos de um
+modo menos perturbador.</p>
+<p>
+ Para aplicar o mesmo argumento ao desenvolvimento de software, eu irei agora
+mostrar que ter “pedágios” para programas úteis custa diariamente à
+sociedade: torna os programas mais caros para construir, mais caros para
+distribuir, e menos satisfatórios e eficientes para se usar. Segue que a
+construção de programas deveria ser encorajada de algum outro modo. Então eu
+irei explicar outros métodos de estímulo e (à medida do realmente
+necessário) financiamento para o desenvolvimento de software.</p>
+
+<h4 id="harm-done">O Dano Causado por Software Obstruído</h4>
+<p>
+ Considere por um momento que um programa tenha sido desenvolvido, e que
+qualquer pagamentos necessários para seu desenvolvimento já tenham sido
+feitos; agora a sociedade tem que decidir se deve torná-lo proprietário ou
+se deve permitir seu livre uso e compartilhamento. Assuma que é desejável
+que o programa exista e que esteja disponível.<a href="#f3">(3)</a></p>
+<p>
+ Restrições na distribuição e modificação do programa não podem facilitar seu
+uso. Só podem interferir. Sendo assim o efeito só pode ser negativo. Mas
+quão negativo? E de que modo?</p>
+<p>
+ Três níveis diferentes de danos materiais se originam desta obstrução:</p>
+
+<ul>
+<li>Menos pessoas usam o programa.</li>
+
+<li>Nenhum dos usuários pode adaptar ou corrigir o programa.</li>
+
+<li>Outros desenvolvedores não podem aprender a partir do programa, ou basear um
+novo trabalho nele.</li>
+</ul>
+
+<p>
+ Cada nível de dano material tem uma forma concomitante de dano
+psicossocial. Isto se refere ao efeito que as decisões das pessoas tem nos
+seus sentimentos, atitudes e predisposições subsequentes. Estas alterações
+na maneira de pensar das pessoas terão um efeito posterior no seu
+relacionamento com seus concidadãos e podem ter consequências materiais.</p>
+<p>
+ Os três níveis de danos materiais desperdiçam parte do valor que o programa
+poderia prover, mas eles não podem reduzi-lo a zero. Se eles desperdiçassem
+quase todo o valor do programa, então o programa causaria quase tanto dano à
+sociedade quanto o esforço empregado para escrevê-lo. Pode-se dizer que um
+programa que é lucrativo deveria prover algum benefício material líquido
+direto.</p>
+<p>
+ No entanto, levando em consideração o dano psicossocial concomitante, não
+existe limite para os danos que o desenvolvimento de software proprietário
+pode causar.</p>
+
+<h4 id="obstructing-use">Obstruindo O Uso de Programas</h4>
+<p>
+ O primeiro nível de dano impede o simples uso de um programa. Uma cópia de
+um programa tem um custo marginal de quase zero (e você pode pagar este
+custo executando você mesmo a tarefa), sendo assim, num mercado livre, teria
+um preço de quase zero. Uma taxa de licença é um desincentivo significativo
+ao uso do programa. Se um programa de ampla utilidade é proprietário, muito
+menos pessoas irão utilizá-lo.</p>
+<p>
+ É fácil mostrar que a contribuição total de um programa para a sociedade é
+reduzida atribuindo-se um proprietário a ele. Cada usuário potencial do
+programa, deparado com a necessidade de pagar para utilizá-lo, pode escolher
+pagar ou pode abrir mão do seu uso. Quando um usuário escolhe pagar, isto é
+uma transferência de riqueza entre duas partes. Mas cada vez que alguém
+escolhe abrir mão de usar o programa, isto causa um dano àquela pessoa sem
+beneficiar ninguém. A soma dos números negativos e zeros deve ser negativa.</p>
+<p>
+ Mas isto não reduz o montante de trabalho que é necessário para
+<em>desenvolver</em> o programa. Como resultado, é reduzida a eficiência do
+processo como um todo, em termos da satisfação de usuário proporcionada por
+hora de trabalho.</p>
+<p>
+ Isto traz à luz uma diferença crucial entre cópias de programas e carros,
+cadeiras, ou sanduíches. Não existe máquina copiadora de objetos materiais,
+a não ser em ficção científica. Mas programas são fáceis de copiar; qualquer
+um pode produzir tantas cópias quantas quiser, com muito pouco esforço. Isto
+não é verdade para objetos materiais porque a matéria é conservada: cada
+nova cópia tem que ser construída de matéria-prima da mesma maneira que a
+primeira cópia foi.</p>
+<p>
+ Com objetos materiais, um desincentivo para utilizá-los faz sentido, porque
+menos objetos comprados significa menos matéria-prima e trabalho necessários
+para construí-los. É verdade que normalmente existe um custo inicial, um
+custo de desenvolvimento, que é distribuído na produção em massa. Mas uma
+vez que o custo de produção seja significativo, acrescentar uma parcela do
+custo de desenvolvimento não faz uma diferença qualitativa. E não requer
+restrições sobre a liberdade dos usuários comuns.</p>
+<p>
+ No entanto, impor um preço em algo que de outro modo seria gratuito é uma
+mudança qualitativa. Uma taxa centralmente imposta para a distribuição do
+software se torna um desincentivo poderoso.</p>
+<p>
+ E tem mais, a produção centralizada como é praticada atualmente é
+ineficiente mesmo como meio de distribuição de cópias de software. Este
+sistema envolve acomodar discos ou fitas em um empacotamento supérfluo,
+enviando um grande número deles ao redor do mundo, e armazenando-os para a
+venda. Este custo é apresentado como uma despesa de negócio; na verdade, é
+parte do desperdício causado por ter proprietários.</p>
+
+<h4 id="damaging-social-cohesion">Prejudicando a União Social</h4>
+<p>
+ Suponha que você e seu colega achassem útil rodar um certo programa. Num
+consenso ético com seu colega você sente que a maneira apropriada de lidar
+com a situação é permitir que ambos utilizem o programa. Uma proposta que
+permitisse a somente um dos dois a utilização do programa excluindo o outro
+causaria desarmonia; nem você nem seu colega achariam aceitável.</p>
+<p>
+ Aceitar um típico acordo de licença de software significa trair seu colega:
+“Eu prometo privar meu colega deste programa de modo que eu possa ter uma
+cópia para mim.” As pessoas que fazem opções deste tipo sentem uma pressão
+psicológica interna para se justificar, desmerecendo a importância da
+cooperação mútua — assim o espírito público é prejudicado. Este é um dano
+psicossocial associado com o dano material de desencorajar o uso do
+programa.</p>
+<p>
+ Muitos usuários inconscientemente reconhecem o erro de se recusar a
+compartilhar, então eles decidem ignorar as licenças e as leis, e
+compartilham programas de qualquer forma. Mas eles frequentemente se sentem
+culpados por agirem assim. Eles sabem que devem quebrar as leis para serem
+bons colegas, mas ainda assim reconhecem a autoridade das leis, então
+concluem que ser um bom companheiro (que eles são) é perverso ou
+vergonhoso. Isto também é um tipo de dano psicossocial, mas alguém pode
+escapar disto decidindo que estas licenças e leis não têm força moral.</p>
+<p>
+ Os programadores também sofrem dano psicossocial por saber que muitos
+usuários não terão o direito de tirar proveito do seu trabalho. Isto leva a
+uma atitude de cinismo ou negação. Um programador pode descrever
+entusiasticamente o trabalho que ele acha tecnologicamente interessante;
+então quando perguntado, “Eu vou poder usar isso?”, seu semblante cai e ele
+admite que a resposta é não. Para evitar se sentir desestimulado, ele ou
+ignora isso a maior parte do tempo ou adota uma postura cínica elaborada
+para minimizar a relevância do fato.</p>
+<p>
+ Desde a época do governo Reagan, a maior escassez nos Estados Unidos não é
+inovação tecnológica e sim a disposição de trabalhar junto para o bem
+público. Não faz sentido estimular o primeiro às custas do segundo.</p>
+
+<h4 id="custom-adaptation">Obstruindo a Adaptação Personalizada de Programas</h4>
+<p>
+ O segundo nível de dano material é a impossibilidade de adaptar programas. A
+facilidade de modificação do software é uma das suas grandes vantagens em
+relação às tecnologias mais antigas. Mas a maior parte do software
+disponível comercialmente não está disponível para modificação, mesmo depois
+de você comprá-lo. Está disponível para você pegar ou largar, como uma caixa
+preta — e isto é tudo.</p>
+<p>
+ Um programa que você pode rodar consiste numa série de números cujo
+significado é obscuro. Ninguém, nem mesmo um bom programador, pode
+facilmente mudar os números para fazer com que o programa aja diferente.</p>
+<p>
+ Programadores normalmente trabalham com o “código-fonte” do programa, que é
+escrito numa linguagem de programação como Fortran ou C. Ela usa nomes para
+designar os dados utilizados e as partes do programa, e representa operações
+com símbolos como '+' para adição e '-' para subtração. Isto é feito para
+auxiliar os programadores a ler e alterar programas. Aqui está um exemplo;
+um programa para calcular a distância entre dois pontos num plano:</p>
+
+<pre>
+ float
+ distance (p0, p1)
+ struct point p0, p1;
+ {
+ float xdist = p1.x - p0.x;
+ float ydist = p1.y - p0.y;
+ return sqrt (xdist * xdist + ydist * ydist);
+ }
+</pre>
+<p>
+ O que o código-fonte precisamente significa não é o importante; o importante
+é que isso se parece com álgebra, e uma pessoa que sabe essa linguagem de
+programação vai entender seu significado e achar claro. Em contraste, aqui
+está o mesmo programa na forma executável, no computador que eu normalmente
+usava quando escrevi isso:
+</p>
+
+<pre>
+ 1314258944 -232267772 -231844864 1634862
+ 1411907592 -231844736 2159150 1420296208
+ -234880989 -234879837 -234879966 -232295424
+ 1644167167 -3214848 1090581031 1962942495
+ 572518958 -803143692 1314803317
+</pre>
+
+<p>
+ Código-fonte é útil (no mínimo em potencial) para qualquer usuário de um
+programa. Mas a maioria dos usuários não tem permissão para ter cópias do
+código-fonte. Normalmente o código-fonte de um programa proprietário é
+mantido em segredo pelo proprietário, evitando que qualquer pessoa possa
+aprender a partir dele. Usuários recebem apenas os arquivos contendo números
+incompreensíveis que o computador irá executar. Isto significa que somente o
+proprietário do programa pode alterá-lo.</p>
+<p>
+ Uma amiga me disse uma vez que ela estava trabalhando em um banco durante
+aproximadamente seis meses, escrevendo um programa similar a algo que estava
+disponível comercialmente. Ela acreditava que se pudesse ter acesso ao
+código-fonte para aquele programa disponível comercialmente, ele poderia ter
+sido adaptado facilmente às suas necessidades. O banco estava disposto a
+pagar por isso, mas não lhe foi permitido — o código-fonte era um
+segredo. Sendo assim ela teve que gastar seis meses nesta tarefa, trabalho
+este que conta no Produto Interno Bruto (PIB) mas que na verdade foi
+desperdício.</p>
+<p>
+ O laboratório de Inteligência Artificial do <abbr title="Massachusetts
+Institute of Technology">MIT</abbr> (laboratório de AI) recebeu uma
+impressora gráfica como presente da Xerox por volta de 1977. Funcionava com
+software livre ao qual nós adicionamos muitas funcionalidades
+convenientes. Por exemplo, o software notificava um usuário imediatamente ao
+término de uma impressão. Sempre que a impressora tinha algum problema, tal
+como papel preso ou falta de papel, o software imediatamente notificava
+todos os usuários que tinham impressões na fila. Estas funcionalidades
+facilitavam a operação tranquila.</p>
+<p>
+ Mais tarde a Xerox deu ao laboratório de AI uma impressora mais nova, mais
+rápida, uma das primeiras impressoras a laser. Ela era controlada por um
+software proprietário que rodava em um computador dedicado separado, sendo
+assim nós não poderíamos acrescentar qualquer das nossas funcionalidades
+favoritas. Nós poderíamos organizar as coisas de modo a enviar uma
+notificação quando a tarefa de impressão fosse enviada ao computador
+dedicado, mas não quando a impressão realmente fosse feita (e o atraso era
+normalmente considerável). Não havia modo de saber quando a impressão era
+realmente concluída; você poderia somente chutar. E ninguém era informado
+quando havia um papel enroscado, de modo que a impressora frequentemente
+ficava por uma hora parada.</p>
+<p>
+ Os programadores de sistema do laboratório de AI eram capazes de corrigir
+estes problemas, provavelmente tão capazes quanto os autores originais do
+programa. A Xerox não estava interessada em corrigi-los no entanto, e
+preferiu nos impedir, de modo que nós fomos forçados a aceitar os
+problemas. Eles nunca foram corrigidos.</p>
+<p>
+ A maioria dos bons programadores já passou por esta frustração. O banco pôde
+se permitir resolver o problema escrevendo um novo programa do zero, mas um
+usuário típico, não importa o quão conhecedor, não tem outra alternativa
+senão desistir.</p>
+<p>
+ Desistência causa dano psicossocial — ao espírito da autoconfiança. É
+desmoralizante viver numa casa que você não pode reorganizar para satisfazer
+as suas necessidades. Isto leva à resignação e desencorajamento, que pode se
+espalhar e afetar outros aspectos da vida de uma pessoa. Pessoas que se
+sentem assim são infelizes e não produzem um bom trabalho.</p>
+<p>
+ Imagine o que aconteceria se receitas culinárias fossem entesouradas como o
+software. Você poderia dizer, “Como eu mudo esta receita para tirar o sal?”,
+e o grande chefe de cozinha te responderia, “Como ousa insultar minha
+receita, o fruto do meu cérebro e do meu paladar, tentando mexer nela? Você
+não tem conhecimento para alterar minha receita e fazê-la funcionar.”</p>
+<p>
+ “Mas meu médico disse que eu não posso comer sal! O que eu posso fazer? Você
+vai tirar o sal pra mim?”</p>
+<p>
+ “Eu faria com muito prazer; meus honorários são de apenas $50.000.” Uma vez
+que o proprietário tem o monopólio nas alterações, os honorários tendem a
+ser grandes. “No entanto, justamente agora eu não tenho tempo. Estou ocupado
+com uma comissão para projetar uma nova receita para o biscoito do navio
+para o Departamento da Marinha. Posso te dar um retorno daqui a dois anos.”</p>
+
+<h4 id="software-development">Obstruindo Desenvolvimento de Software</h4>
+<p>
+ O terceiro nível de dano material afeta o desenvolvimento de
+software. Desenvolvimento de software costumava ser um processo
+evolucionário, onde uma pessoa pegava um programa existente e reescrevia
+partes dele para obter uma nova funcionalidade, e então outra pessoa iria
+reescrever partes para adicionar outra funcionalidade; em alguns casos isso
+continuava por um período de vinte anos. Neste meio-tempo, partes do
+programa eram “canibalizadas” para formar o princípio de outros programas.</p>
+<p>
+ A existência de proprietários impede este tipo de evolução, tornando
+necessário começar do zero quando do desenvolvimento de um programa. Também
+impede novos praticantes de estudar programas existentes para aprender
+técnicas úteis ou mesmo como grandes programas podem ser estruturados.</p>
+<p>
+ Proprietários também obstruem a educação. Eu tenho conhecido estudantes
+brilhantes em ciência da computação que nunca viram o código-fonte de um
+programa grande. Eles podem ser bons para escrever pequenos programas, mas
+eles não podem começar a aprender os conhecimentos diferentes que são
+necessários para a construção de grandes programas se eles não podem ver
+como outros fizeram isto.</p>
+<p>
+ Em qualquer área intelectual, uma pessoa pode alcançar maiores alturas
+subindo nos ombros de outros. Mas geralmente isto não é mais permitido na
+área de software — você pode somente subir nos ombros das outras pessoas
+dentro <em>da sua empresa</em>.</p>
+<p>
+ O dano psicossocial associado afeta o espírito da cooperação científica, que
+costumava ser tão forte que cientistas cooperariam mesmo quando suas nações
+estava em guerra. Imbuídos deste espírito, oceanógrafos japoneses
+abandonando seu laboratório numa ilha do Pacífico cuidadosamente preservaram
+seu trabalho para os soldados invasores dos Estados Unidos, e deixaram uma
+nota pedindo que eles tomassem cuidado com aquilo.</p>
+<p>
+ Conflitos por lucro têm destruído o que conflitos internacionais
+pouparam. Hoje em dia cientistas em muitas áreas não publicam o suficiente
+nos seus ensaios para permitir que outros reproduzam suas experiências. Eles
+publicam somente o suficiente para permitir aos leitores maravilharem-se do
+quanto eles foram capazes de fazer. Isto certamente é verdade em ciência da
+computação, onde o código-fonte do programa relatado é normalmente secreto.</p>
+
+<h4 id="does-not-matter-how">Não Importa Como o Compartilhamento Seja Restringido</h4>
+<p>
+ Eu discuti os efeitos de evitar que as pessoas copiem, alterem e construam
+um programa. Eu não especifiquei como esta obstrução é feita, porque isto
+não afeta a conclusão. Não importa se é feita através de proteção contra
+cópia, copyright, licenças, criptografia, cartões <abbr title="Read-only
+Memory">ROM</abbr>, números seriais de hardware, se é bem <em>sucedido</em>
+então causa dano.</p>
+<p>
+ Usuários consideram alguns destes métodos mais detestáveis que outros. Eu
+sugiro que os métodos mais odiados são aqueles que atingem seu objetivo.</p>
+
+<h4 id="should-be-free">O Software Deveria ser Livre</h4>
+<p>
+ Eu mostrei como a propriedade de um programa — o poder de restringir as
+alterações ou a cópia dele — é obstrusivo. Seus efeitos negativos são
+amplamente disseminados e importantes. Segue que a sociedade não deveria ter
+proprietários para programas.</p>
+<p>
+ Outra maneira de entender isto é ver que o que a sociedade precisa é de
+software livre, e software proprietário é um substituto pobre. Encorajar o
+substituto não é uma maneira racional de obter o que nós precisamos.</p>
+<p>
+ Vaclav Havel nos aconselhou: “Trabalhe por algo porque é bom e não apenas
+porque tem chance de sucesso.” Um negócio fazendo software proprietário tem
+chance de sucesso dentro dos seus próprios termos limitados, mas não é o que
+é bom para a sociedade.</p>
+
+<h3 id="why-develop">Por Que as Pessoas Irão Desenvolver Software</h3>
+<p>
+ Se nós eliminarmos a copyright como meio de estimular pessoas a desenvolver
+software, no início menos software será desenvolvido, mas este software será
+mais útil. Não está claro se a satisfação geral proporcionada será menor;
+mas se for, ou se de qualquer jeito nós quisermos aumentá-la, existem outras
+maneiras de estimular desenvolvimento, assim como existem outras maneiras de
+levantar fundos para estradas sem usar pedágios. Antes de falar a respeito
+de como isso pode ser feito, primeiro eu gostaria de questionar o quanto de
+incentivo artificial é realmente necessário.</p>
+
+<h4 id="fun">Programar é Divertido</h4>
+<p>
+ Existem algumas linhas de trabalho em que poucos irão entrar exceto por
+dinheiro; construção de rodovias, por exemplo. Existem outras áreas de
+estudo e arte em que existe pouca chance de se tornar rico, em que pessoas
+entram pela sua fascinação ou pelo percebido valor para a
+sociedade. Exemplos incluem a lógica matemática, música clássica,
+arqueologia e organização política entre trabalhadores. Pessoas competem por
+novas vagas, nenhuma das quais é muito bem remunerada. Elas chegam até a
+pagar pela chance de trabalhar na área, se elas têm condições para isso.</p>
+<p>
+ Uma área assim pode se transformar do dia pra noite se começar a oferecer a
+possibilidade de ficar rico. Quando um trabalhador fica rico, outros querem
+a mesma oportunidade. Logo todos querem grandes somas em dinheiro para fazer
+o que eles costumavam fazer por prazer. Quando se passam mais alguns anos,
+todos ligados àquele campo irão ridicularizar a ideia que trabalho poderia
+ser executado naquela área sem grandes retornos financeiros. Eles irão
+aconselhar os planejadores sociais a assegurar que estes retornos sejam
+possíveis, prescrevendo privilégios especiais, poderes e monopólios à medida
+do necessário para que isto aconteça.</p>
+<p>
+ Esta mudança aconteceu no campo da programação de computadores na década de
+1980. Nos anos 70, havia artigos sobre “vício de computador”: usuários
+estavam ficando “on-line” e tinham hábitos baratos. Era geralmente conhecido
+que pessoas frequentemente amavam programação o suficiente para romper seus
+casamentos. Hoje, é geralmente conhecido que ninguém iria programar exceto
+por uma alta taxa de remuneração. As pessoas se esqueceram do que elas
+sabiam naquela época.</p>
+<p>
+ Quando é verdade em um determinado momento que a maioria das pessoas irão
+trabalhar numa certa área por altos pagamentos, isto não precisa continuar
+sendo verdade. A dinâmica da mudança pode acontecer ao contrário, se a
+sociedade fornecer o ímpeto. Se nós tirarmos a possibilidade de grande
+riqueza, então depois de um breve momento, quando as pessoas tiverem
+reajustado suas atitudes, elas irão mais uma vez ansiar por trabalhar na
+área pelo prazer da conquista.</p>
+<p>
+ A questão “Como nós podemos pagar programadores?” se torna mais fácil quando
+nós entendemos que não é uma questão de pagá-los uma fortuna. Um mero viver
+é mais fácil de se conseguir.</p>
+
+<h4 id="funding">Financiando o Software Livre</h4>
+<p>
+ Instituições que pagam programadores não têm que ser “software
+houses”. Muitas outras instituições já existem que podem fazer isto.</p>
+<p>
+ Fabricantes de equipamentos acham essencial suportar desenvolvimento de
+software mesmo que eles não controlem o uso do software. Em 1970, muito do
+seu software era livre porque eles não consideravam a possibilidade de
+restringi-lo. Hoje, a sua crescente disposição para combinar consórcios
+mostra seu entendimento que possuir o software não é o que é realmente
+importante para eles.</p>
+<p>
+ Universidades conduzem muitos projetos de programação. Hoje, elas
+frequentemente vendem os resultados, mas nos anos 70, elas não
+vendiam. Existe alguma dúvida de que as universidades iriam desenvolver
+software livre se não lhes fosse permitido vender software? Estes projetos
+poderiam ser financiados pelos mesmos contratos de governo e concessões que
+agora financiam o desenvolvimento de software proprietário.</p>
+<p>
+ É comum hoje para pesquisadores de universidade pegar concessão para
+desenvolver um sistema, desenvolvê-lo até quase o término e dá-lo por
+“terminado”, e então começar empresas onde eles realmente terminam o projeto
+e o tornam útil. Às vezes eles declaram as versões inacabadas como
+“gratuitas”; se eles são profundamente corruptos, eles em vez disso obtém
+uma licença exclusiva da universidade. Isto não é nenhum segredo; é
+abertamente admitido por todos os interessados. Já se os pesquisadores não
+fossem expostos à tentação de fazer estas coisas, eles ainda assim fariam
+suas pesquisas.</p>
+<p>
+ Programadores que escrevem software livre podem ganhar a vida vendendo
+serviços relacionados ao software. Eu tenho sido contratado para portar o <a
+href="/software/gcc/">compilador C GNU</a> para novos equipamentos, e para
+fazer extensões à interface do usuário no <a href="/software/emacs/">GNU
+Emacs</a>. (Eu ofereço estas melhorias ao público uma vez que elas ficam
+prontas.) Eu também ensino em salas de aula, pelo que eu sou pago.</p>
+<p>
+ Eu não sou o único que trabalha desta forma; existe hoje uma empresa
+crescente e bem sucedida que não faz outra coisa. Diversas outras empresas
+também fornecem suporte comercial para software livre do sistema GNU. Isto é
+o começo de uma indústria de suporte ao software independente — uma
+indústria que poderia se tornar muito grande se o software livre se tornasse
+predominante. Ela dá aos usuários uma opção geralmente não disponível para o
+software proprietário, exceto para os muito ricos.</p>
+<p>
+ Novas instituições tais como a <a href="/fsf/fsf.html">Free Software
+Foundation</a> podem também pagar programadores. A maior parte dos fundos da
+fundação vem de usuários comprarem fitas através do correio. O software nas
+fitas é livre, o que significa que todo usuário tem a liberdade de copiá-lo
+e alterá-lo, mas muitos apesar de tudo pagam para obter cópias. (Lembre-se
+que “free software” se refere a liberdade e não preço). Alguns usuários
+adquirem fitas para as quais eles já tem uma cópia, como uma maneira de
+fazer uma contribuição que eles sentem que nós merecemos. A fundação também
+recebe donativos consideráveis de fabricantes de computadores.</p>
+<p>
+ A Free Software Foundation é uma entidade, e suas receitas são gastas
+contratando tantos programadores quanto possível. Se ela tivesse sido feita
+para ganhos financeiros, distribuindo o mesmo software livre ao público
+pelos mesmos valores, daria agora uma vida muito boa ao seu fundador.</p>
+<p>
+ Em virtude da fundação ser uma entidade, programadores frequentemente
+trabalham pra ela por metade do que eles poderiam ganhar em outro
+lugar. Eles fazem isto porque nós somos livres de burocracia, e porque eles
+sentem satisfação em saber que seu trabalho não será obstruído. Acima de
+tudo, eles fazem isso porque programar é divertido. Fora isso, voluntários
+têm escrito muitos programas úteis para nós. (Recentemente mesmo escritores
+técnicos começaram a se oferecer.)</p>
+<p>
+ Isto confirma que programação está entre as áreas mais fascinantes de todas,
+junto da música e da arte. Nós não temos medo que ninguém queira programar.</p>
+
+<h4 id="owe">O Que os Usuários Devem aos Desenvolvedores?</h4>
+<p>
+ Existe uma boa razão para os usuários de software sentirem uma obrigação
+moral de contribuir para seu suporte. Desenvolvedores de software livre
+estão contribuindo para as atividades dos usuários, e é justo e a longo
+prazo interessante para os usuários prover os fundos para continuar.</p>
+<p>
+ No entanto, isto não se aplica a software proprietário, uma vez que o
+obstrucionismo merece uma punição em vez de uma recompensa.</p>
+<p>
+ Nós temos assim um paradoxo: o desenvolvedor de software útil tem direito ao
+suporte dos usuários, mas qualquer tentativa de tornar esta obrigação moral
+numa exigência destrói a base para a obrigação. Um desenvolvedor pode tanto
+merecer a recompensa quanto exigi-la, mas não ambos.</p>
+<p>
+ Eu acredito que um desenvolvedor ético defrontado com este paradoxo deve
+agir de modo a merecer a recompensa, mas deveria também solicitar aos
+usuários donativos voluntários. No final das contas os usuários irão
+aprender a suportar os desenvolvedores sem coerção, assim como eles
+aprenderam a suportar as estações públicas de rádio e televisão.</p>
+
+<h3 id="productivity">O Que É Produtividade De Software? </h3>
+<p>
+ Se o software fosse livre, ainda assim existiriam programadores, mas talvez
+um número menor deles. Seria isto ruim para a sociedade?</p>
+<p>
+ Não necessariamente. Hoje as nações avançadas têm menos fazendeiros que em
+1900, mas nós não achamos que isto seja ruim para a sociedade, porque os em
+menor número fornecem mais comida aos consumidores do que os em maior número
+faziam. Nós chamamos isso de produtividade melhorada. Software livre
+exigiria muito menos programadores para satisfazer a demanda, por causa da
+produtividade de software aumentada em todos os níveis:</p>
+
+<ul>
+<li> Uso mais amplo de cada programa que é desenvolvido.</li>
+<li> A habilidade de adaptar programas para personalização em vez de começar do
+zero.</li>
+<li> Melhor educação de programadores.</li>
+<li> A eliminação de esforço de desenvolvimento duplicado.</li>
+</ul>
+
+<p>
+ Aqueles que se opõem à cooperação porque isso resultaria no emprego de menos
+programadores, estão na verdade se opondo à produtividade melhorada. Estas
+mesmas pessoas normalmente concordam com a crença largamente aceita que a
+indústria de software precisa de produtividade melhorada. Pode?</p>
+<p>
+ “Produtividade de Software” pode significar duas coisas diferentes: a
+produtividade geral de todo o desenvolvimento de software ou a produtividade
+de projetos individuais. Produtividade geral é o que a sociedade gostaria de
+ver melhorada e a maneira mais direta de fazer isto é eliminar os obstáculos
+artificiais à cooperação que a reduzem. Mas pesquisadores que estudam a área
+de “produtividade de software” focam somente no segundo, limitado, sentido
+da frase, onde melhoria requer avanços tecnológicos difíceis.</p>
+
+<h3 id="competition">A Competição É Inevitável?</h3>
+<p>
+ É inevitável que as pessoas tentem competir, sobrepujando seus rivais em
+sociedade? Talvez sim. Mas competição por si só não é prejudicial; o que é
+prejudicial é o <em>combate</em>.</p>
+<p>
+ Existem maneiras de competir. Competição pode consistir de tentar alcançar
+cada vez mais, exceder o que outros fizeram. Por exemplo, antigamente,
+haviam competições entre magos da programação — competição para ver quem
+poderia fazer o computador executar a coisa mais impressionante, ou fazer o
+mais curto ou mais rápido programa para uma dada tarefa. Este tipo de
+competição pode beneficiar a todos, <em>contanto que</em> o espírito
+esportivo seja mantido.</p>
+<p>
+ Competição construtiva é competição suficiente para motivar pessoas a
+grandes esforços. Algumas pessoas estão competindo para ver quem será o
+primeiro a ter visitado todos os países da Terra; alguns até mesmo já
+gastaram fortunas tentando isso. Mas eles não subornam capitães de navio
+para encalhar seus rivais em ilhas desertas. Eles estão satisfeitos em que
+vença o melhor.</p>
+<p>
+ Competição se torna combate quando os competidores começam a tentar impedir
+um ao outro de avançar — quando o “que vença o melhor” dá lugar ao “que eu
+vença, sendo ou não o melhor.” Software proprietário é prejudicial, não
+porque seja uma forma de competição, mas porque é uma forma de combate entre
+cidadãos da nossa sociedade.</p>
+<p>
+ Competição em negócios não é necessariamente combate. Por exemplo, quando
+duas mercearias competem, todo seu esforço é para melhorar as suas próprias
+operações, não para sabotar a rival. Mas isto não demostra um compromisso
+especial com a ética de negócios; em vez disso, há pouco espaço para combate
+nesta linha de negócio a não ser violência física. Nem todas as áreas de
+negócio compartilham esta característica. Ocultar informação que poderia
+ajudar o avanço de todos é uma forma de combate.</p>
+<p>
+ Ideologia de negócios não prepara pessoas para resistir à tentação de
+combater na competição. Algumas formas de combate tem sido banidas com leis
+antitruste, leis que exigem a verdade em anúncios, e assim por diante, mas
+em vez de generalizar isto para obter um princípio de rejeição ao combate em
+geral, executivos inventam outras formas de combate que não são
+especificamente proibidas. Os recursos da sociedade são gastos no
+equivalente econômico da guerra civil faccionária.</p>
+
+<h3 id="communism">“Por Que Você Não Se Muda Pra Rússia?”</h3>
+<p>
+ Nos Estados Unidos, qualquer um que defenda outra coisa que não a mais
+extrema forma de política egoísta de não intervencionismo tem ouvido
+frequentemente esta acusação. Por exemplo, é dito isso aos que defendem um
+sistema de saúde nacional, tal como os encontrados em todas as outras nações
+industrializadas do mundo livre. Também dizem isso aos que defendem o
+suporte público para as artes, também universal em nações desenvolvidas. A
+ideia que cidadãos tenham qualquer obrigação para com o bem público é
+identificada nos Estados Unidos como Comunismo. Mas quão similar são estas
+ideias?</p>
+<p>
+ Comunismo como praticado na União Soviética era um sistema de controle
+central onde toda atividade era regimentada, supostamente para o bem comum,
+mas na prática em prol dos membros do partido Comunista. E onde os
+equipamentos de cópia eram guardados hermeticamente para evitar cópias
+ilegais.</p>
+<p>
+ O sistema Americano de copyright exerce um controle central sobre a
+distribuição de um programa, e guarda os equipamentos de cópia com esquemas
+de proteção contra cópia automáticos para evitar a cópia ilegal.</p>
+<p>
+ Em contraste, eu estou trabalhando para construir um sistema onde pessoas
+são livres para decidir suas própria ações; em particular, livres para
+ajudar seus companheiros, e livres para alterar e melhorar as ferramentas
+que elas usam no seu cotidiano. Um sistema baseado em cooperação voluntária
+e decentralização.</p>
+<p>
+ Assim, se nós temos que julgar pontos de vista pelas suas semelhanças com o
+Comunismo Russo, são os proprietários de software que são os Comunistas.</p>
+
+<h3 id="premises">A Questão das Premissas</h3>
+<p>
+ Eu assumo neste documento que um usuário de software não é menos importante
+que um autor, ou até mesmo que o empregador de um autor. Em outras palavras,
+seus interesses e necessidades têm igual peso, quando nós decidimos que
+curso de ação é melhor.</p>
+<p>
+ Esta premissa não é universalmente aceita. Muitos mantêm que um empregador
+de autor é fundamentalmente mais importante que qualquer um. Eles dizem, por
+exemplo, que o propósito de ter proprietários de software é dar ao
+empregador do autor a vantagem que ele merece — sem levar em consideração
+como isto pode afetar o público.</p>
+<p>
+ Não é comum tentar provar ou desaprovar estas premissas. Prova requer
+premissas compartilhadas. Sendo assim a maior parte do que eu disse é
+somente para aqueles que compartilham as premissas que eu adoto, ou pelo
+menos estão interessados em quais são suas consequências. Para aqueles que
+acreditam que os proprietários são mais importantes que todos os demais,
+este documento é irrelevante.</p>
+<p>
+ Mas por que um grande número de Americanos iria aceitar uma premissa que
+eleva certas pessoas em importância acima de todos os outros? Parcialmente
+por causa do credo que esta premissa é parte das tradições legais da
+sociedade Americana. Algumas pessoas sentem que duvidar da premissa
+significa desafiar as bases da sociedade.</p>
+<p>
+ É importante para estas pessoas saber que esta premissa não é parte da nossa
+tradição legal. Nem nunca foi.</p>
+<p>
+ Assim, a Constituição diz que o propósito do copyright é “promover o
+progresso da ciência e das artes úteis.” A Suprema Corte foi além disso,
+afirmando em <em>Fox Film vs. Doyal</em> que “O único interesse dos Estados
+Unidos e o principal objetivo em conferir o monopólio [de copyright] reside
+nos benefícios derivados pelo público a partir do trabalho dos autores.”</p>
+<p>
+ Nós não temos que concordar com a Constituição ou com a Suprema Corte. (Uma
+vez, ambas perdoaram a escravidão.) Sendo assim suas posições não desaprovam
+a premissa da supremacia do proprietário. Mas eu espero que o anúncio que
+isto é uma concepção radical direitista em vez de uma tradicionalmente
+reconhecida venha enfraquecer seu apelo.</p>
+
+<h3 id="conclusion">Conclusão</h3>
+<p>
+ Nós gostamos de pensar que nossa sociedade estimula o auxílio mútuo; mas
+cada vez que nós recompensamos alguém pelo seu obstrucionismo, ou o
+admiramos pela riqueza que ele ganhou deste modo, nós estamos enviando a
+mensagem oposta.</p>
+<p>
+ O entesouramento de software é uma faceta da nossa disposição geral de
+desrespeitar o bem estar social em prol do ganho pessoal. Nós podemos vir
+acompanhando este desrespeito desde Ronald Reagan a Dick Cheney, desde Exxon
+a Enron, desde a falência dos bancos à falência das escolas. Podemos medir
+isto pelo tamanho da população sem-teto e da população carcerária. Este
+espírito antissocial alimenta a si mesmo; porque quanto mais nós vemos que
+outras pessoas não irão nos ajudar, mais nos parece fútil ajudá-las. Assim a
+sociedade vai decaindo até se tornar uma selva.</p>
+<p>
+ Se nós não queremos viver numa selva, devemos mudar nossas atitudes. Devemos
+começar enviando a mensagem que um bom cidadão é um que coopera quando
+apropriado, não um que é bem sucedido tirando dos outros. Eu espero que o
+movimento pelo software livre contribua para isto: pelo menos em uma área
+nós iremos substituir a selva por um sistema mais eficiente que encoraja e
+confia na cooperação voluntária.</p>
+
+
+<h3 id="footnotes">Notas de Rodapé</h3>
+
+<ol>
+<li id="f1">A palavra “free” em “free software” refere-se à liberdade, e não ao preço; o
+preço pago por uma cópia de um “free software” pode ser zero, ou pequeno, ou
+(raramente) bem grande.</li>
+
+<li id="f2">Os problemas da poluição e do congestionamento não alteram esta
+conclusão. Se nós desejamos tornar o ato de guiar mais caro para
+desencorajá-lo em geral, é desvantajoso fazer isto usando pedágios, que
+contribuem tanto para a poluição quanto para o congestionamento. Um imposto
+sobre a gasolina é muito melhor. Da mesma forma, um desejo de melhorar a
+segurança limitando a velocidade máxima não é relevante; a via de acesso
+livre melhora a velocidade média evitando paradas e atrasos, para qualquer
+limite de velocidade dado.</li>
+
+<li id="f3">Alguém poderia observar que um programa de computador em particular é uma
+coisa prejudicial e que não deveria estar disponível, como a base de dados
+de informações pessoais Lotus Marketplace, que foi retirada de venda devido
+à desaprovação pública. A maior parte do que eu digo não se aplica a este
+caso, mas faz pouco sentido argumentar que seria bom ter um proprietário
+porque ele tornaria o programa menos disponível. O proprietário não o
+tornaria <em>completamente</em> não disponível, como seria desejável no caso
+de um programa cujo uso fosse considerado destrutivo.</li>
+</ol>
+
+<hr />
+<blockquote id="fsfs"><p class="big">Este ensaio foi publicado em <a
+href="http://shop.fsf.org/product/free-software-free-society/"><cite>Software
+Livre, Sociedade Livre: Artigos selecionados de Richard
+M. Stallman</cite></a>.</p></blockquote>
+
+<div class="translators-notes">
+
+<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
+ </div>
+</div>
+
+<!-- for id="content", starts in the include above -->
+<!--#include virtual="/server/footer.pt-br.html" -->
+<div id="footer">
+<div class="unprintable">
+
+<p>Envie perguntas em geral sobre a FSF e o GNU para <a
+href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Também existem <a
+href="/contact/">outros meios de contatar</a> a FSF. Links quebrados e
+outras correções ou sugestões podem ser enviadas para <a
+href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>
+
+<p>
+<!-- TRANSLATORS: Ignore the original text in this paragraph,
+ replace it with the translation of these two:
+
+ We work hard and do our best to provide accurate, good quality
+ translations. However, we are not exempt from imperfection.
+ Please send your comments and general suggestions in this regard
+ to <a href="mailto:web-translators@gnu.org">
+
+ &lt;web-translators@gnu.org&gt;</a>.</p>
+
+ <p>For information on coordinating and submitting translations of
+ our web pages, see <a
+ href="/server/standards/README.translations.html">Translations
+ README</a>. -->
+A equipe de traduções para o português brasileiro se esforça para oferecer
+traduções precisas e de boa qualidade, mas não estamos isentos de erros. Por
+favor, envie seus comentários e sugestões em geral sobre as traduções para
+<a
+href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.
+</p><p>Consulte o <a href="/server/standards/README.translations.html">Guia
+para as traduções</a> para mais informações sobre a coordenação e o envio de
+traduções das páginas deste site.</p>
+</div>
+
+<p>Copyright &copy; 1991, 1992, 1998, 2000, 2001, 2006, 2007, 2010, 2017, 2018,
+2020 Free Software Foundation, Inc.</p>
+
+<p>Esta página está licenciada sob uma licença <a rel="license"
+href="http://creativecommons.org/licenses/by-nd/4.0/deed.pt_BR">Creative
+Commons Atribuição-SemDerivações 4.0 Internacional</a>.</p>
+
+<!--#include virtual="/server/bottom-notes.pt-br.html" -->
+<div class="translators-credits">
+
+<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
+Traduzido por: Juciê Dias Andrade, 2001;
+Rafael Fontenelle <a
+href="mailto:rafaelff@gnome.org">rafaelff@gnome.org</a>, 2017-2020</div>
+
+<p class="unprintable"><!-- timestamp start -->
+Última atualização:
+
+$Date: 2020/07/26 11:30:53 $
+
+<!-- timestamp end -->
+</p>
+</div>
+</div>
+<!-- for class="inner", starts in the banner include -->
+</body>
+</html>