path: root/talermerchantdemos/blog/articles/br/shouldbefree.html

<!--#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>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/10/26 13:34:15 $

<!-- timestamp end -->
</p>
</div>
</div>
<!-- for class="inner", starts in the banner include -->
</body>
</html>