Por que o Software Deveria Ser Livre

por Richard Stallman

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”?

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.

Eu gostaria de considerar a mesma questão usando um critério diferente: a prosperidade e liberdade do público em geral.

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.

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 software “livre”.(1)

Como os Donos Justificam Seu Poder

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.

O argumento emocional é mais ou menos assim: “Eu coloquei meu suor, meu coração, minha alma neste programa. Ele veio de mim, é meu!”

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.

O argumento econômico se parece com: “Eu quero ficar rico (que via de regra é descrito imprecisamente como ‘ganhar a vida’), 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.

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.

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.

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.

O Argumento Contra Ter Donos

A questão é: “O desenvolvimento de software deveria ser ligado a ter donos para restringir sua utilização?”

Para que nós possamos escolher, temos que julgar o efeito na sociedade de cada uma destas duas atividades independentemente: 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.

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.

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.

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.

Para elucidar este argumento, vamos aplicá-lo a outra área: construção de vias públicas.

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.

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.(2) 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.

Quando os defensores dos pedágios os propõem meramente 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.

É 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.

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.

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.

O Dano Causado por Software Obstruído

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.(3)

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?

Três níveis diferentes de danos materiais se originam desta obstrução:

• Menos pessoas usam o programa.
• Nenhum dos usuários pode adaptar ou corrigir o programa.
• Outros desenvolvedores não podem aprender a partir do programa, ou basear um novo trabalho nele.

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.

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.

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.

Obstruindo O Uso de Programas

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.

É 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.

Mas isto não reduz o montante de trabalho que é necessário para desenvolver 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.

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.

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.

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.

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.

Prejudicando a União Social

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.

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.

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.

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.

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.

Obstruindo a Adaptação Personalizada de Programas

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.

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.

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:

     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);
     }

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:

     1314258944      -232267772      -231844864      1634862
     1411907592      -231844736      2159150         1420296208
     -234880989      -234879837      -234879966      -232295424
     1644167167      -3214848        1090581031      1962942495
     572518958       -803143692      1314803317

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.

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.

O laboratório de Inteligência Artificial do MIT (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.

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.

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.

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.

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.

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.”

“Mas meu médico disse que eu não posso comer sal! O que eu posso fazer? Você vai tirar o sal pra mim?”

“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.”

Obstruindo Desenvolvimento de Software

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.

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.

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.

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 da sua empresa.

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.

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.

Não Importa Como o Compartilhamento Seja Restringido

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 ROM, números seriais de hardware, se é bem sucedido então causa dano.

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.

O Software Deveria ser Livre

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.

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.

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.

Por Que as Pessoas Irão Desenvolver Software

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.

Programar é Divertido

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.

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.

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.

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.

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.

Financiando o Software Livre

Instituições que pagam programadores não têm que ser “software houses”. Muitas outras instituições já existem que podem fazer isto.

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.

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.

É 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.

Programadores que escrevem software livre podem ganhar a vida vendendo serviços relacionados ao software. Eu tenho sido contratado para portar o compilador C GNU para novos equipamentos, e para fazer extensões à interface do usuário no GNU Emacs. (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.

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.

Novas instituições tais como a Free Software Foundation 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.

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.

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.)

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.

O Que os Usuários Devem aos Desenvolvedores?

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.

No entanto, isto não se aplica a software privativo, uma vez que o obstrucionismo merece uma punição em vez de uma recompensa.

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.

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.

O Que É Produtividade De Software?

Se o software fosse livre, ainda assim existiriam programadores, mas talvez um número menor deles. Seria isto ruim para a sociedade?

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:

• Uso mais amplo de cada programa que é desenvolvido.
• A habilidade de adaptar programas para personalização em vez de começar do zero.
• Melhor educação de programadores.
• A eliminação de esforço de desenvolvimento duplicado.

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?

“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.

A Competição É Inevitável?

É 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 combate.

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, contanto que o espírito esportivo seja mantido.

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.

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.

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.

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.

“Por Que Você Não Se Muda Pra Rússia?”

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?

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.

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.

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.

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.

A Questão das Premissas

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.

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.

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.

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.

É importante para estas pessoas saber que esta premissa não é parte da nossa tradição legal. Nem nunca foi.

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 Fox Film vs. Doyal 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.”

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.

Conclusão

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.

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.

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.

Notas de Rodapé

1. 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.
2. 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.
3. 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 completamente não disponível, como seria desejável no caso de um programa cujo uso fosse considerado destrutivo.

---