taler-merchant-demos

shouldbefree.html (50951B)

---

 <!--#set var="PO_FILE"
  value='<a href="/philosophy/po/shouldbefree.pt-br.po">
  https://www.gnu.org/philosophy/po/shouldbefree.pt-br.po</a>'
  --><!--#set var="ORIGINAL_FILE" value="/philosophy/shouldbefree.html"
  --><!--#set var="DIFF_FILE" value="/philosophy/po/shouldbefree.pt-br-diff.html"
  --><!--#set var="OUTDATED_SINCE" value="2021-09-12" --><!--#set var="ENGLISH_PAGE" value="/philosophy/shouldbefree.en.html" -->
 
 <!--#include virtual="/server/header.pt-br.html" -->
 <!-- Parent-Version: 1.96 -->
 <!-- This page is derived from /server/standards/boilerplate.html -->
 <!--#set var="TAGS" value="essays aboutfs principles" -->
 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
 
 <!-- This file is automatically generated by GNUnited Nations! -->
 <title>Por que o Software Deveria Ser Livre - Projeto GNU - Free Software
 Foundation</title>
 <style type="text/css" media="print,screen"><!--
 #content h3 { margin-top: 1.6em; }
 -->
 
 </style>
 
 <!--#include virtual="/philosophy/po/shouldbefree.translist" -->
 <!--#include virtual="/server/banner.pt-br.html" -->
 <!--#include virtual="/philosophy/ph-breadcrumb.pt-br.html" -->
 <!--GNUN: OUT-OF-DATE NOTICE-->
 <!--#include virtual="/server/outdated.pt-br.html" -->
 <!--#include virtual="/server/top-addendum.pt-br.html" -->
 <div class="article reduced-width">
 <h2>Por que o Software Deveria Ser Livre</h2>
 
 <address class="byline">por <a href="http://www.stallman.org/">Richard Stallman</a></address>
 
 <p  id="introduction">
 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 dono”?</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 dono, 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 donos 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 donos 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 Donos 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
 privativo versus a da inexistência deste programa, e então conclui que o
 desenvolvimento de software privativo é, no todo, benéfico e deveria ser
 encorajado. A falácia aqui está em comparar apenas dois pontos — software
 privativo 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 dono que controla o uso do
 software. Enquanto existe esta ligação, nós frequentemente nos deparamos com
 a opção entre software privativo 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 donos. Formular a opção como
 sendo entre software privativo versus software inexistente é desvirtuar a
 questão.</p>
 
 <h3 id="against-having-owners">O Argumento Contra Ter Donos</h3>
 <p>
    A questão é: “O desenvolvimento de software deveria ser ligado a ter donos
 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,
 privativo) 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 dono.” 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 privativo 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 privativo 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 é privativo, 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 dono 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 donos.</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 privativo é mantido
 em segredo pelo dono, 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 dono 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 privativo 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 dono 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 donos 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>
    Donos 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
 donos para programas.</p>
 <p>
    Outra maneira de entender isto é ver que o que a sociedade precisa é de
 software livre, e software privativo é 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 privativo 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 privativo.</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 privativo, 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 privativo, 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 privativo é 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 donos 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 donos 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 donos 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 dono. 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>
 <div class="column-limit"></div>
 
 <h3 id="footnotes" class="footnote">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 dono porque ele
 tornaria o programa menos disponível. O dono 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 class="no-display" />
 <div class="edu-note c"><p id="fsfs">Este ensaio foi publicado em <a
 href="https://shop.fsf.org/product/free-software-free-society/"><cite>Software
 Livre, Sociedade Livre: Artigos selecionados de Richard
 M. Stallman</cite></a>.</p></div>
 </div>
 
 <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" role="contentinfo">
 <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 contributing 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 a
 contribuição com traduções das páginas deste site.</p>
 </div>
 
 <p>Copyright &copy; 1991, 1992, 1998, 2006, 2010, 2021 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-2021</div>
 
 <p class="unprintable"><!-- timestamp start -->
 Última atualização:
 
 $Date: 2021/11/11 15:30:25 $
 
 <!-- timestamp end -->
 </p>
 </div>
 </div>
 <!-- for class="inner", starts in the banner include -->
 </body>
 </html>