O Projeto GNU

por Richard Stallman

A primeira comunidade de compartilhamento de software

Quando comecei a trabalhar no Laboratório de Inteligência Artificial do MIT (Instituto de Tecnologia de Massachusetts) em 1971, tornei-me parte de uma comunidade de compartilhamento de software que já existia há muitos anos. A partilha de software não se limitava à nossa comunidade em particular; ela é tão antiga quanto os computadores, assim como a partilha de receitas é tão antiga quanto a culinária. Mas nós a fazíamos mais do que a maioria.

O laboratório de IA usava um sistema operacional de tempo compartilhado chamado ITS (Sistema de Compartilhamento de Tempo Incompatível) que a equipe de hackers do laboratório [1] tinha concebido e escrito em linguagem de montagem para o PDP-10 da Digital, um dos imensos computadores da época. Como um membro desta comunidade, um hacker de sistemas da equipe do laboratório de IA, meu trabalho era melhorar este sistema.

Nós não chamávamos o nosso software de “software livre”, porque esse termo ainda não existia; mas isso é o que era. Sempre que as pessoas de outra universidade ou empresa queriam portar e usar um programa, tínhamos o prazer de deixá-los. Se você visse alguém usando um programa desconhecido e interessante, poderia sempre pedir para ver o código-fonte, para que pudesse lê-lo, alterá-lo ou canibalizá-lo para fazer um novo programa.

O colapso da comunidade

A situação mudou drasticamente no início de 1980, quando a Digital descontinuou a série PDP-10. Esta arquitetura, elegante e poderosa na década de 60, não poderia ser estendida naturalmente para os espaços de endereços maiores que estavam se tornando viáveis na década de 80. Isto significa que praticamente todos os programas que compunham o ITS ficaram obsoletos.

A comunidade hacker do laboratório de IA já havia entrado em colapso, não muito antes. Em 1981, a empresa derivada Symbolics havia contratado quase todos os hackers do laboratório de IA, e a comunidade desfalcada foi incapaz de manter-se. (O livro Hackers, de Steve Levy, descreve esses eventos, bem como dá uma imagem clara desta comunidade no seu apogeu). Quando o laboratório de IA comprou um novo PDP-10 em 1982, seus administradores decidiram usar o sistema de tempo compartilhado não livre da Digital em vez do ITS.

Os computadores modernos da época, como o VAX ou o 68020, tinham seus próprios sistemas operacionais, mas nenhum deles era software livre: você tinha de assinar um acordo de confidencialidade até mesmo para obter uma cópia executável.

Isto significava que o primeiro passo para usar um computador era prometer não ajudar o seu próximo. Uma comunidade cooperativa era proibida. A regra definida pelos donos do software privativo era, “Se você compartilha com seu próximo, você é um pirata. Se você quer alterações, suplique-nos para fazê-las”.

A ideia de que o sistema social do software privativo — o sistema que diz que você não tem permissão para compartilhar ou modificar o software — é antissocial, antiético ou simplesmente errado, pode vir como uma surpresa para alguns leitores. Mas o que mais poderíamos dizer sobre um sistema baseado na divisão e impotência dos usuários? Os leitores que acham a ideia surpreendente podem ter tomado por certo o sistema social do software privativo, ou o julgaram nos termos sugeridos pelas empresas de software privativo. Os publicadores de software têm trabalhado muito duro para convencer as pessoas de que há apenas uma maneira de olhar para o problema.

Quando os publicadores de software falam sobre “exercer” seus “direitos” ou “acabar com a pirataria”, o que eles realmente estão dizendo é secundário. A mensagem real destas declarações está nos pressupostos não declarados que eles tomam por certo, e que o público é induzido a aceitar sem questionar. Vamos, portanto, examiná-los.

Um pressuposto é que as empresas de software têm um direito natural e inquestionável de se apropriar do software e, portanto, têm poder sobre todos os seus usuários. (Se este fosse um direito natural, então não importaria quão danoso fosse ao público, não poderíamos questionar). Curiosamente, a Constituição dos Estados Unidos e a tradição legal rejeitam essa visão; o direito autoral não é um direito natural, mas um monopólio artificial imposto pelo governo que limita o direito natural dos usuários de copiar.

Outro pressuposto não declarado é que a única coisa importante sobre software é que tipo de trabalho ele nos permite fazer — que nós, usuários de computador, não deveríamos nos importar com que tipo de sociedade estamos autorizados a ter.

Um terceiro pressuposto é que nós não teríamos nenhum software utilizável (ou nunca teríamos um programa para fazer este ou aquele trabalho em particular) se não oferecêssemos a uma empresa poder sobre os usuários do programa. Esta suposição pode ter parecido plausível, antes do movimento do software livre demonstrar que podemos fazer software útil em abundância sem ter de acorrentá-los.

Se nos recusarmos a aceitar esses pressupostos, e julgarmos estas questões com base na moralidade ordinária de senso comum enquanto colocamos os usuários em primeiro lugar, chegamos a conclusões muito diferentes. Os usuários de computador devem ser livres para modificar os programas de forma a atender às suas necessidades e devem ser livres para compartilhar o software, porque ajudar outras pessoas é a base da sociedade.

Não há espaço aqui para uma extensa declaração do raciocínio que por trás dessa conclusão, portanto, remeto o leitor a “Por Que o Software Não Deve Ter Donos” e “Software Livre é Ainda Mais Importante Agora”.

Uma escolha moral difícil

Com a minha comunidade desfeita, continuar como antes era impossível. Em vez disso, eu enfrentei uma escolha moral difícil.

A escolha fácil era me juntar ao mundo do software privativo, assinando acordos de confidencialidade e prometendo não ajudar os meus companheiros hackers. O mais provável é que eu também estaria desenvolvendo software liberado sob acordos de confidencialidade, assim aumentando a pressão sobre outras pessoas para também trair seus companheiros.

Eu poderia ter feito dinheiro desta forma e, talvez, me divertido escrevendo código. Mas eu sabia que, no final da minha carreira, eu olharia para trás e veria anos dedicados à construção de paredes que dividem pessoas, e sentiria que eu tinha passado a minha vida fazendo do mundo um lugar pior.

Eu já tinha experimentado os prejuízos de um acordo de confidencialidade quando alguém se recusou a dar a mim e ao laboratório de IA do MIT, o código-fonte do programa que controlava nossa impressora. (A falta de certas funcionalidades neste programa fez o uso dela extremamente frustrante). Então, eu não poderia me convencer de que acordos de confidencialidade eram inofensivos. Fiquei muito irritado quando ele se recusou a compartilhar conosco; eu não podia virar as costas e fazer a mesma coisa com todos os outros.

Outra escolha, simples mas desagradável, era deixar o campo da computação. Dessa forma, minhas habilidades não seriam usadas para o mal, mas ainda assim seriam desperdiçadas. Eu não seria culpado por dividir e restringir os usuários de computador, mas tal divisão aconteceria de qualquer forma.

Então eu procurei por um jeito de fazer alguma coisa boa como programador. Perguntei a mim mesmo: existe um programa ou conjunto de programas que eu possa escrever para formar uma comunidade novamente?

A resposta foi clara: em primeiro lugar, um sistema operacional era necessário. Esse é o software crucial para começar a usar um computador. Com um sistema operacional, você pode fazer muitas coisas; sem ele, o computador mal funciona. Com um sistema operacional livre, poderíamos voltar a ter uma comunidade de hackers que cooperam — e convidar qualquer pessoa para participar — e todos seriam capazes de usar um computador sem ter que conspirar para privar seus amigos.

Como um desenvolvedor de sistema operacionais, eu tinha as habilidades certas para este trabalho. Assim, ainda que eu não pudesse tomar o sucesso como certo, eu percebi que havia sido eleito para realizar este trabalho. Eu decidi fazer o sistema compatível com o Unix para que ele fosse portável, e para que os usuários do Unix pudessem migrar para ele facilmente. O nome GNU foi escolhido, seguindo uma tradição hacker, como um acrônimo recursivo para “GNU Não é Unix” (do inglês “GNU’s Not Unix”). É pronunciado como uma sílaba com g forte.

Um sistema operacional não significa apenas um núcleo, que mal é suficiente para executar outros programas. Na década de setenta, todos os sistemas operacionais dignos de serem chamados assim incluíam processadores de comando, montadores, compiladores, interpretadores, depuradores, editores de texto, gerentes de correio e muito mais. ITS os tinham, Multics os tinham, VMS os tinham, e Unix os tinham. O sistema operacional GNU iria incluí-los também.

Mais tarde, ouvi estas palavras, atribuídas a Hillel [2]:

Se eu não for por mim, quem será por mim?
Se eu for só por mim, o que eu sou?
Se não for agora, quando?

A decisão de iniciar o projeto GNU foi baseada em um espírito semelhante.

Livre como em liberdade

O termo “software livre” às vezes é mal interpretado — não tem nada a ver com preço. É sobre liberdade. Aqui, portanto, está a definição de software livre.

Um programa é software livre, para você, um usuário em particular, se:

• Você tem a liberdade para executar o programa como quiser, para qualquer finalidade.
• Você tem a liberdade de modificar o programa para atender às suas necessidades. (Para fazer esta liberdade efetiva na prática, você deve ter acesso ao código-fonte, uma vez que fazer mudanças em um programa sem ter o código fonte é extremamente difícil).
• Você tem a liberdade de redistribuir cópias, seja gratuitamente ou por uma taxa.
• Você tem a liberdade de distribuir versões modificadas do programa, de modo que a comunidade possa se beneficiar de suas melhorias.

Dado que “livre” refere-se à liberdade, não ao preço, não há contradição entre a venda de cópias e software livre. Na verdade, a liberdade de vender cópias é crucial: coleções de software livre vendido em CD-ROMs são importantes para a comunidade, e vendê-los é uma forma importante para levantar fundos para o desenvolvimento de software livre. Portanto, um programa que as pessoas não são livres para incluir nessas coleções não é software livre.

Por causa da ambiguidade do termo “free”¹ (do inglês “free software”, isto é, software livre), as pessoas há muito tempo tem procurado por alternativas, mas ninguém encontrou um termo melhor. A língua inglesa tem mais palavras e nuances do que qualquer outro idioma, mas carece de uma palavra simples, inequívoca, que signifique “livre”, como em “freedom” (liberdade) — “unfettered” (irrestrito) é a palavra que mais se aproxima deste significado. Outras alternativas como “liberated” (liberado), “freedom” (liberdade) e “open” (aberto) tem ou o significado errado ou alguma outra desvantagem.

Software GNU e o sistema GNU

Desenvolver um sistema inteiro é um projeto muito grande. Para torná-lo viável, eu decidi adaptar e usar peças existentes de software livre onde quer que fosse possível. Por exemplo, eu decidi bem no início usar TeX como o principal formatador de textos; alguns anos mais tarde, eu decidi usar o X Window System, em vez de escrever outro sistema de janelas para o GNU.

Devido a estas decisões, e outras como elas, o sistema GNU não é o mesmo que a coleção de todo o software GNU. O sistema GNU inclui programas que não são software GNU, programas que foram desenvolvidos por outras pessoas e projetos para seus próprios propósitos, mas que podemos usar, porque eles são software livre.

Começando o projeto

Em janeiro de 1984 deixei o meu emprego no MIT e comecei a escrever software GNU. Deixar o MIT era necessário para que eles não fossem capazes de interferir com a distribuição do GNU como software livre. Se eu tivesse permanecido na equipe, o MIT poderia ter reivindicado a titularidade do trabalho, e poderia ter imposto seus próprios termos de distribuição, ou até mesmo transformar o trabalho em um pacote de software privativo. Eu não tinha a intenção de fazer uma grande quantidade de trabalho só para vê-lo tornar-se inútil para a sua finalidade: a criação de uma nova comunidade de compartilhamento de software.

No entanto, o professor Winston, então chefe do laboratório de IA do MIT, gentilmente me convidou para continuar usando as instalações do laboratório.

Os primeiros passos

Pouco antes do início do Projeto GNU, eu ouvi sobre o “Free University Compiler Kit” (Kit de Compilador da Universidade Livre), também conhecido como VUCK. (A palavra holandesa para “livre” é escrita com um v). Este era um compilador projetado para lidar com múltiplas linguagens, incluindo C e Pascal, e para suportar múltiplas máquinas de destino. Eu escrevi ao seu autor perguntando se o GNU poderia usá-lo.

Ele respondeu com ironia, afirmando que a universidade era livre, mas o compilador não. Por isso, decidi que meu primeiro programa para o Projeto GNU seria um compilador de múltiplas linguagens e plataformas.

Na esperança de evitar a necessidade de escrever o compilador todo eu mesmo, obtive o código fonte do compilador Pastel, que era um compilador multiplataforma desenvolvido no “Lawrence Livermore Lab”. Ele suportava, e havia sido escrito, em uma versão estendida da Pascal, projetada para ser uma linguagem de programação de sistemas. Eu adicionei um front-end C, e comecei a portá-la para o computador Motorola 68000. Mas eu tive que desistir quando eu descobri que o compilador precisava de muitos megabytes de espaço de pilha, e o sistema Unix 68000 disponível apenas permitia 64k.

Eu então percebi que o compilador Pastel processava todo o arquivo de entrada em uma árvore sintática, convertendo toda a árvore sintática em uma cadeia de “instruções”, e em seguida gerando o arquivo de saída inteiro, sem nunca liberar qualquer armazenamento. Neste ponto, eu concluí que eu teria que escrever um novo compilador a partir do zero. Esse novo compilador é agora conhecido como GCC (Coleção de Compiladores GNU); nada do compilador Pastel é usado nele, mas eu consegui adaptar e usar o front-end C que eu havia escrito. Mas isso foi alguns anos mais tarde; primeiro, eu trabalhei no GNU Emacs.

GNU Emacs

Comecei a trabalhar no GNU Emacs em setembro de 1984, e no início de 1985 ele estava começando a ficar usável. Isto permitiu-me começar a usar sistemas Unix para fazer a edição; não tendo interesse em aprender a usar o vi ou o ed, eu havia feito a minha edição em outros tipos de máquinas até então.

Neste ponto, as pessoas começaram a querer usar o GNU Emacs, o que levantou a questão de como distribuí-lo. Claro, eu o coloquei no servidor de FTP anônimo do computador MIT que eu usava. (Este computador, prep.ai.mit.edu, assim tornou-se o principal local de distribuição ftp do GNU; quando foi descomissionado alguns anos mais tarde, nós transferimos o nome para o nosso novo servidor ftp). Mas naquele tempo, muitas pessoas interessadas não estavam na Internet e não poderiam obter uma cópia por ftp. Portanto, a pergunta era: o que eu diria a elas?

Eu poderia ter dito, “Encontre um amigo que está na rede e que vai fazer uma cópia para você”. Ou eu poderia ter feito o que eu fiz com o Emacs original do PDP-10: dizer-lhes, “Envie-me uma fita e um SASE (Envelope Autoendereçado e com Selo), e eu vou enviá-lo de volta com uma cópia do Emacs”. Mas eu não tinha trabalho, e eu estava procurando maneiras de ganhar dinheiro com software livre. Então eu anunciei que iria enviar uma fita para quem quisesse, por uma taxa de US$ 150,00. Desta forma, eu comecei um negócio de distribuição de software livre, o precursor das empresas que hoje distribuem sistemas GNU/Linux completos.

Um programa é livre para qualquer usuário?

Se um programa é software livre quando deixa as mãos de seu autor, isso não significa necessariamente que ele será software livre para todos que tem uma cópia do mesmo. Por exemplo, software de domínio público (software que não está sujeito a direitos autorais) é software livre; mas qualquer pessoa pode fazer uma versão modificada e privativa dele. Da mesma forma, muitos programas livres estão sujeitos a direitos autorais, mas são distribuídos sob licenças permissivas simples que permitem versões modificadas e privativas.

O exemplo paradigmático desse problema é o X Window System. Desenvolvido no MIT, e lançado como software livre com uma licença permissiva, logo foi adotado por diversas empresas de informática. Eles acrescentaram X em seus sistemas Unix privativos, apenas em forma binária, e abrangidos por um mesmo contrato de confidencialidade. Estas cópias do X não eram mais software livre do que o Unix era.

Os desenvolvedores do X Window System não consideraram isso um problema — eles esperavam e queriam que isso acontecesse. O objetivo deles não era a liberdade, apenas “sucesso”, definido como “ter muitos usuários”. Eles não se importavam se esses usuários teriam liberdade, só que eles deveriam ser numerosos.

Isso levou a uma situação paradoxal onde duas formas diferentes de contar a quantidade de liberdade deram respostas diferentes à pergunta, “Este programa é livre?”. Se você julgasse com base na liberdade proporcionada pelos termos de distribuição da liberação do MIT, você diria que o X era software livre. Mas se você medisse a liberdade do usuário médio do X, você teria que dizer que era software privativo. A maioria dos usuários do X estavam executando as versões privativas que vieram com sistemas Unix, e não a versão livre.

O Copyleft e a GNU GPL

O objetivo do GNU era dar aos usuários liberdade, não apenas ser popular. Portanto, nós precisávamos usar termos de distribuição que impediriam o software GNU de ser transformado em software privativo. O método que usamos é chamado de “copyleft”. [3].

Copyleft usa a lei de direitos autorais, mas a inverte para servir ao oposto do seu objetivo usual: em vez de um meio para restringir o programa, ela se torna um meio para manter o programa livre.

A ideia central do copyleft é que damos a todos a permissão para executar o programa, copiar o programa, modificar o programa, e distribuir versões modificadas — mas não a permissão para adicionar restrições por conta própria. Assim, as liberdades fundamentais que definem o “software livre” são garantidas a todos aqueles que tem uma cópia; elas se tornam direitos inalienáveis.

Para um copyleft efetivo, versões modificadas devem também ser livres. Isso garante que trabalho baseado no nosso se torne disponível para nossa comunidade se ele for publicado. Quando programadores que têm empregos de programadores se voluntariam para melhorar o software GNU, é o copyleft que impede os empregadores de dizer, “Você não pode compartilhar essas alterações, porque vamos usá-las para fazer a nossa versão privativa do programa”.

A exigência de que as mudanças devem ser livres é essencial se quisermos garantir a liberdade de todos os usuários do programa. As empresas que privatizaram o X Window System normalmente fizeram algumas alterações para portá-los para os seus sistemas e hardware. Essas mudanças foram pequenas em comparação com a grande extensão do X, mas elas não foram triviais. Se fazer mudanças fosse uma desculpa para negar liberdade aos usuários, seria fácil para qualquer um tirar proveito dessa desculpa.

Uma questão relacionada diz respeito a combinar um programa livre com código não livre. Essa combinação seria inevitavelmente não livre; quaisquer liberdades que faltam para a parte não livre estaria faltando para o todo também. Permitir tais combinações abriria um buraco grande o suficiente para afundar um navio. Portanto, um requisito fundamental para o copyleft é tampar este buraco: o que for adicionado ou combinado com um programa sob copyleft deve ser tal que a versão combinada total seja também livre e esteja sob copyleft.

A implementação específica de copyleft que usamos para a maioria do software GNU é a Licença Pública Geral GNU (GNU General Public License), ou GNU GPL para abreviar. Temos outros tipos de copyleft que são utilizados em circunstâncias específicas. Manuais GNU estão sob copyleft também, mas usam uma espécie de copyleft muito mais simples, porque a complexidade da GNU GPL não é necessária para manuais. [4].

A Free Software Foundation

Como o interesse em usar o Emacs foi crescendo, outras pessoas se envolveram no projeto GNU, e decidimos que era hora de buscar financiamento mais uma vez. Assim, em 1985 foi criada a Free Software Foundation (FSF), uma instituição de caridade isenta de impostos para o desenvolvimento do software livre. A FSF também assumiu o negócio de distribuição de fitas com o Emacs; mais tarde isso foi estendido adicionando-se outros softwares livres (tanto GNU quanto não GNU) à fita, e com a venda de manuais livres também.

A maior parte da renda da FSF costumava vir da venda de cópias de software livre e de outros serviços relacionados (CD-ROMs com código-fonte, CD-ROMs com binários, manuais bem impressos, todos com a liberdade de redistribuir e modificar), e distribuições de luxo (distribuições para as quais construíamos toda a coleção de software segundo a escolha de plataforma do cliente). Hoje, a FSF ainda vende manuais e outros apetrechos, mas a maior parte do seu financiamento vem de doações de seus membros. Você pode participar da FSF em fsf.org.

Empregados da Free Software Foundation têm escrito e mantido vários pacotes de software GNU. Os dois mais notáveis ​​são a biblioteca C e o interpretador de comandos. A biblioteca C GNU é o que todos os programas em execução num sistema GNU/Linux usam para se comunicar com o Linux. Ela foi desenvolvida por um membro da equipe da Free Software Foundation, Roland McGrath. O interpretador de comandos usado na maioria dos sistemas GNU/Linux é o BASH, o Bourne Again Shell [5], que foi desenvolvido pelo empregado da FSF Brian Fox.

Financiamos o desenvolvimento destes programas porque o Projeto GNU não dizia respeito apenas a ferramentas ou um ambiente de desenvolvimento. Nosso objetivo era um sistema operacional completo, e esses programas eram necessários para atingir este objetivo.

Suporte ao software livre

A filosofia do software livre rejeita uma prática específica e amplamente difundida de negócios, mas não é contra os negócios. Quando as empresas respeitam a liberdade dos usuários, desejamos-lhes sucesso.

A venda de cópias do Emacs demonstra um tipo de negócio de software livre. Quando a FSF assumiu esse negócio, eu precisava de uma outra maneira de ganhar a vida. Eu a encontrei na venda de serviços relacionados ao software livre que eu tinha desenvolvido. Isto incluía ensino, sobre os temas de como programar o GNU Emacs e como personalizar o GCC, e desenvolvimento de software, principalmente portando o GCC para novas plataformas.

Hoje cada um desses tipos de negócio de software livre é praticado por uma série de empresas. Alguns distribuem coleções de software livre em CD-ROM; outros vendem suporte em níveis que vão de responder perguntas dos usuários, à correção de erros, à adição de importantes novas funcionalidades. Estamos até mesmo começando a ver companhias de software livre baseadas no lançamento de novos produtos de software livre.

No entanto, tome cuidado — várias empresas que se associam ao termo “open source” realmente baseiam seus negócios em software não livre que funciona com software livre. Estas não são empresas de software livre, mas sim empresas de software privativo cujos produtos seduzem os usuários para longe da liberdade. Eles chamam esses programas “pacotes de valor agregado”, o que mostra os valores que eles gostariam que adotássemos: conveniência acima da liberdade. Se valorizamos mais a liberdade, devemos chamá-los “pacotes de liberdade desagregada”.

Objetivos técnicos

O principal objetivo do GNU é ser software livre. Mesmo se o GNU não tivesse nenhuma vantagem técnica sobre o Unix, teria uma vantagem social, permitindo que os usuários cooperem, e uma vantagem ética, respeitando a liberdade dos usuários.

Mas era natural aplicar os padrões conhecidos de boas práticas ao nosso trabalho — por exemplo, alocar dinamicamente estruturas de dados para evitar limites de tamanho fixos arbitrários, e lidar com todos os possíveis códigos de 8 bits onde quer que fizesse sentido.

Além disso, rejeitamos o foco do Unix em memória reduzida, ao decidir suportar máquinas de 16 bits (era claro que as máquinas de 32 bits seriam a norma no momento em que o sistema GNU fosse terminado), e não fazer nenhum esforço para reduzir o uso de memória a menos que excedesse um megabyte. Nos programas para os quais lidar com arquivos muito grandes não era crucial, nós encorajamos os programadores a ler um arquivo de entrada inteiro para a memória, e então verificar o seu conteúdo sem ter que se preocupar com E/S (do inglês “Input/Output”, isto é, Entrada/Saída).

Estas decisões permitiram que muitos programas GNU superassem os seus equivalentes Unix em confiabilidade e velocidade.

Computadores doados

Conforme a reputação do projeto GNU crescia, as pessoas começaram a se oferecer para doar máquinas rodando Unix para o projeto. Estas ofertas eram muito úteis, porque a maneira mais fácil de desenvolver componentes do GNU era fazê-lo em um sistema Unix, e substituir os componentes desse sistema, um a um. Mas eles levantaram uma questão ética: se para nós era correto ter uma cópia do Unix.

Unix era (e ainda é) software privativo, e a filosofia do Projeto GNU dizia que não devíamos usar software privativo. Mas, aplicando o mesmo raciocínio que leva à conclusão de que a violência em legítima defesa é justificada, cheguei à conclusão de que era legítimo usar um pacote privativo quando isso fosse crucial para o desenvolvimento de um substituto livre que ajudaria os outros a parar de usar o pacote privativo.

Mas, mesmo que isso fosse um mal justificável, ainda era um mal. Hoje não temos mais nenhuma cópia do Unix, porque as substituímos por sistemas operacionais livres. Se não pudéssemos substituir o sistema operacional de uma máquina com um livre, substituíamos a máquina em vez disso.

A lista de tarefas GNU

Conforme o Projeto GNU prosseguia, e um número crescente de componentes do sistema foram encontrados ou desenvolvidos, eventualmente, tornou-se útil fazer uma lista das lacunas remanescentes. Costumávamos recrutar desenvolvedores para escrever as peças que faltavam. Esta lista se tornou conhecida como a lista de tarefas GNU. Além de componentes Unix que faltavam, listávamos vários outros projetos úteis de softwares e documentação que nós achávamos necessários a um sistema verdadeiramente completo.

Hoje [6], dificilmente um componente do Unix está na lista de tarefas GNU — esse trabalho já foi feito, com exceção de uns poucos não essenciais. Mas a lista está cheia de projetos que alguns poderiam chamar de “aplicações”. Qualquer programa que agrada mais do que uma classe pequena de usuários é uma coisa útil para se adicionar a um sistema operacional.

Mesmo jogos estão incluídos na lista de tarefas — e estiveram desde o início. Unix incluía jogos, então naturalmente o GNU também deveria. Mas a compatibilidade não importa para os jogos, por isso não seguimos a lista de jogos que o Unix tinha. Em vez disso, listamos um espectro de diferentes tipos de jogos que os usuários poderiam gostar.

A GNU Menor GPL

A biblioteca C GNU usa um tipo especial de copyleft chamado Licença Pública Geral Menor GNU [7], que dá permissão para ligar software privativo à biblioteca. Por que fazer essa exceção?

Não é uma questão de princípio; não há um princípio que diz que os produtos de software privativo têm o direito de incluir o nosso código. (Por que contribuir com um projeto que se recusa a compartilhar conosco?) Usando a LGPL para a biblioteca C, ou para qualquer biblioteca, é uma questão de estratégia.

A biblioteca C faz um trabalho genérico; cada sistema privativo ou compilador vem com uma biblioteca C. Portanto, tornar nossa biblioteca C disponível apenas para o software livre não teria sido qualquer vantagem — isso só teria desencorajado o uso da nossa biblioteca.

Um sistema é uma exceção a isto: no sistema GNU (e isso inclui o GNU/Linux), a biblioteca C GNU é a única biblioteca C. Então, os termos de distribuição da biblioteca C GNU determinam se é possível compilar um programa privativo para o sistema GNU. Não há nenhuma razão ética para permitir aplicações privativas no sistema GNU, mas estrategicamente, parece que não as permitir acabaria mais por desencorajar o uso do sistema GNU do que encorajar o desenvolvimento de aplicações livres. É por isso que usar a GPL Menor é uma boa estratégia para a biblioteca C.

Para outras bibliotecas, a decisão estratégica precisa ser considerada caso a caso. Quando uma biblioteca faz um trabalho especial que pode ajudar a escrever certos tipos de programas, liberá-la sob a GPL, limitando-a apenas a programas livres, é uma forma de ajudar outros desenvolvedores de software livre, dando-lhes uma vantagem sobre o software privativo.

Considere a GNU Readline, uma biblioteca que foi desenvolvida para fornecer a edição de linha de comando para o BASH. Readline é distribuída sob a GNU GPL comum, não a GPL Menor. Isso provavelmente reduz o quanto a Readline é usada, mas isso não nos representa perda. Por outro lado, pelo menos uma aplicação útil foi feita software livre especificamente para que ela pudesse usar a Readline, e isso é um ganho real para a comunidade.

Desenvolvedores de software privativo têm as vantagens que o dinheiro fornece; desenvolvedores de software livre precisam criar vantagens uns para os outros. Eu espero que algum dia venhamos a ter uma grande coleção de bibliotecas cobertas pela GPL que não têm equivalente disponível para o software privativo, fornecendo módulos úteis para servir como blocos de construção em novos pacotes de software livre, e agregando a uma grande vantagem para o desenvolvimento subsequente do software livre.

Colocar o dedo na ferida?

Eric Raymond diz que “Todo bom trabalho de software começa ao colocar-se o dedo na ferida de um programador”. Talvez isso aconteça às vezes, mas muitas peças essenciais de software GNU foram desenvolvidas a fim de se ter um sistema operacional livre completo. Elas vêm de uma visão e um plano, não por impulso.

Por exemplo, desenvolvemos a biblioteca C GNU, porque um sistema semelhante ao Unix precisa de uma biblioteca C, BASH porque um sistema do tipo Unix precisa de um interpretador de comandos, e o GNU tar porque um sistema parecido com Unix precisa de um programa tar. O mesmo é verdade para os meus próprios programas — o compilador C GNU, GNU Emacs, GDB e GNU Make.

Alguns programas GNU foram desenvolvidos para lidar com ameaças específicas à nossa liberdade. Assim, desenvolvemos o gzip para substituir o programa Compress, que havia sido perdido pela comunidade por causa das patentes sobre o LZW. Encontramos pessoas para desenvolver a LessTif, e mais recentemente começamos o GNOME e o Harmony, para resolver os problemas causados por certas bibliotecas privativas (veja abaixo). Estamos desenvolvendo o GNU Privacy Guard para substituir um software não livre de criptografia popular, porque os usuários não deveriam ter que escolher entre privacidade e liberdade.

Claro, as pessoas que escrevem estes programas se interessaram pelo trabalho, e muitos recursos foram adicionados a eles por várias pessoas por causa de suas próprias necessidades e interesses. Mas não é por isso que esses programas existem.

Desenvolvimentos inesperados

No início do Projeto GNU, eu imaginei que iríamos desenvolver todo o sistema GNU e então liberá-lo como um todo. Não foi assim que aconteceu.

Dado que cada componente do sistema GNU foi implementado em um sistema Unix, cada componente podia ser executado em sistemas Unix muito antes de existir um sistema GNU completo. Alguns desses programas se tornaram populares, e os usuários começaram a estendê-los e portá-los — para as várias versões incompatíveis do Unix, e às vezes para outros sistemas também.

O processo fez esses programas muito mais poderoso, e atraiu tanto fundos quanto contribuidores para o projeto GNU. Mas provavelmente também atrasou a conclusão de um sistema funcional mínimo por vários anos, como o tempo dos desenvolvedores GNU foi usado para manter essas portagens e adicionar recursos aos componentes existentes, ao invés de continuar escrevendo os componentes que faltavam, um após o outro.

O GNU Hurd

Em 1990, o sistema GNU estava quase completo; o único grande componente que faltava era o núcleo. Havíamos decidido implementar nosso núcleo como uma coleção de processos servidores rodando em cima do Mach. Mach é um micronúcleo (microkernel) desenvolvido na Carnegie Mellon University e depois na Universidade de Utah; o GNU Hurd é um conjunto de servidores (ou seja, um rebanho de GNUs), que executam sobre o Mach, e proveem os vários serviços atribuídos ao núcleo do Unix. O início do desenvolvimento foi adiado enquanto esperávamos pelo lançamento do Mach como software livre, como havia sido prometido.

Uma das razões para escolher este design era evitar o que parecia ser a parte mais difícil do trabalho: depurar o núcleo sem contar com um depurador de código fonte para fazê-lo. Esta parte do trabalho já havia sido feita, no Mach, e esperávamos para depurar os servidores do Hurd como programas de usuário, com o GDB. Mas levou muito tempo para que isso seja possível, e os servidores de múltiplas linhas de execução que enviam mensagens uns aos outros acabaram por ser muito difíceis de se depurar. Fazer o Hurd funcionar de maneira sólida demorou muitos anos.

Alix

O kernel do GNU não seria originalmente chamado de Hurd. Seu nome original era Alix — o nome da mulher que era minha namorada na época. Ela, uma administradora de sistemas Unix, nos fez notar como seu nome seguia o padrão de nomenclatura comum para as versões do sistema Unix; como uma brincadeira, ela disse aos seus amigos, “Alguém deveria dar meu nome a um núcleo”. Eu não disse nada, mas decidi surpreendê-la com um núcleo chamado Alix.

Mas isso não ficou assim. Michael (agora Thomas) Bushnell, o principal desenvolvedor do kernel, preferiu o nome de Hurd, e redefiniu Alix para se referir a uma determinada parte do kernel — a parte que intercepta as chamadas de sistema e as trata através do envio de mensagens para os servidores do Hurd.

Mais tarde, Alix e eu terminamos, e ela mudou seu nome; de forma independente, o design do Hurd foi alterado para que a biblioteca C enviasse mensagens diretamente aos servidores, e isso fez com que o componente Alix desaparecesse do design.

Mas antes destas coisas acontecerem, um amigo dela se deparou com o nome Alix no código-fonte do Hurd, e mencionou a ela. Então ela teve a chance de encontrar um kernel com o seu nome.

Linux e GNU/Linux

O GNU Hurd não está pronto para o uso em produção, e não sabemos se um dia estará. O design baseado em capacidade (capability-based design) tem problemas que são resultados diretos da flexibilidade do design, e não está claro se soluções existem.

Felizmente, outro núcleo está disponível. Em 1991, Linus Torvalds desenvolveu um núcleo compatível com o Unix e o chamou Linux. Este era privativo no início, mas em 1992, ele o tornou software livre; a combinação do Linux com o não-exatamente-completo sistema GNU resultou em um sistema operacional livre completo. (Combinar ambos era um trabalho substancial em si mesmo, é claro). É graças ao Linux que podemos de fato executar uma versão do sistema GNU hoje em dia.

Nós chamamos esta versão do sistema GNU/Linux, para expressar sua composição como a combinação do sistema GNU com o núcleo Linux. Por favor, não caia na prática de chamar o sistema como um todo de “Linux”, já que isso significa a atribuição do nosso trabalho à outra pessoa. Por favor, nos dê menção igual.

Desafios para o futuro

Nós provamos nossa capacidade de desenvolver um amplo espectro de software livre. Isso não significa que somos invencíveis e que não podemos ser detidos. Vários desafios fazem com que o futuro do software livre seja incerto; enfrentá-los vai exigir esforço firme e muita resistência, às vezes durante anos. Exigirá o tipo de determinação que as pessoas mostram quando elas valorizam a sua liberdade e não deixam ninguém levá-la embora.

As quatro seções seguintes abordam esses desafios.

Hardware secreto

Os fabricantes de hardware tendem cada vez mais a manter as especificações de hardware secretas. Isso torna difícil o desenvolvimento de controladores livres para que o Linux e o XFree86 possam suportar novo hardware. Temos sistemas livres completos hoje, mas não vamos tê-los amanhã, se não pudermos dar suporte aos computadores do futuro.

Há duas maneiras de lidar com este problema. Os programadores podem fazer engenharia reversa para descobrir como suportar o hardware. O resto de nós pode escolher o hardware que é suportado pelo software livre; conforme o nosso número aumenta, o sigilo das especificações se tornará uma política de auto-destrutiva.

A engenharia reversa é um grande trabalho; teremos programadores com determinação suficiente para realizá-lo? Sim — se nós construirmos um forte sentimento de que o software livre é uma questão de princípios, e os controladores não livres são intoleráveis. E irá um grande número de pessoas gastar dinheiro extra, ou até mesmo um pouco de tempo extra, para que possam usar controladores livres? Sim, se a determinação de ter liberdade for generalizada [8].

Bibliotecas não livres

Uma biblioteca não livre que funciona em sistemas operacionais livres age como uma armadilha para os desenvolvedores do software livre. Recursos atraentes da biblioteca são a isca; se você usar a biblioteca, você cai na armadilha, porque o programa não pode ser parte útil de um sistema operacional livre. (Estritamente falando, poderíamos incluir o seu programa, mas ele não executaria com a biblioteca em falta). Ainda pior, se um programa que usa a biblioteca privativa se torna popular, ele pode atrair outros programadores desavisados para a armadilha.

A primeira instância desse problema era o kit de ferramentas Motif, nos anos 80. Embora ainda não houvesse sistemas operacionais livres, ficava claro o problema que a Motif causaria para eles mais tarde. O Projeto GNU respondeu de duas formas: pedindo aos projetos de software livre individuais para dar suporte aos widgets do kit de ferramentas livre do X tão bem quanto a Motif, e pedindo a alguém para escrever um substituto livre para a Motif. O trabalho levou muitos anos; LessTif, desenvolvida pelos Hungry Programmers (Programadores Famintos), tornou-se poderosa o suficiente para dar suporte a maioria das aplicações Motif apenas em 1997.

Entre 1996 e 1998, uma outra biblioteca não livre de kit de ferramentas para GUI, chamada Qt, foi usada em uma coleção substancial de software livre, o KDE.

Sistemas livres GNU/Linux foram incapazes de usar o KDE, porque não podíamos usar a biblioteca. No entanto, alguns distribuidores comerciais do sistemas GNU/Linux que não eram rigorosos a respeito do software livre adicionaram o KDE aos seus sistemas − produzindo um sistema com mais recursos, mas menos liberdade. O grupo KDE estava encorajando ativamente mais programadores a usar Qt, e milhões de novos “usuários Linux” nunca tinham sido expostos à ideia de que havia algum problema nisso. A situação era desesperadora.

A comunidade do software livre respondeu ao problema de duas formas: GNOME e Harmony (Harmonia).

GNOME, o Ambiente de Modelos de Objetos de Rede GNU (GNU Network Object Model Environment), é o projeto de área de trabalho do GNU. Iniciado em 1997 por Miguel de Icaza, e desenvolvido com o apoio da Red Hat Software, o GNOME busca fornecer instalações de área de trabalho semelhantes, mas usando exclusivamente software livre. Ele tem vantagens técnicas também, tais como suportar uma variedade de linguagens, não apenas C++. Mas o seu principal objectivo era a liberdade: não exigir a utilização de qualquer software não livre.

Harmony é uma biblioteca substituta compatível, projetada para tornar possível executar software KDE sem usar Qt.

Em novembro de 1998, os desenvolvedores da Qt anunciaram uma mudança de licença que, quando realizada, deverá fazer da Qt software livre. Não há maneira de ter certeza, mas eu acho que isso foi em parte devido à resposta firme da comunidade ao problema que a Qt causou quando era não livre. (A nova licença é inconveniente e injusta, por isso, continua a ser desejável evitar o uso da Qt [9].)

Como vamos responder à próxima tentadora biblioteca não livre? Irá toda a comunidade entender a necessidade de ficar longe da armadilha? Ou será que muitos de nós desistiremos da liberdade por conveniência, e produziremos um problema maior? Nosso futuro depende de nossa filosofia.

As patentes de software

A pior ameaça que enfrentamos vem de patentes de software, que podem colocar algoritmos e funcionalidades fora do alcance do software livre por até 20 anos. As patentes do algoritmo de compressão LZW foram aplicadas em 1983, e nós ainda não podemos liberar software livre que produza adequadamente GIFs comprimidos [10]. Em 1998, um programa livre para produzir áudio comprimido em MP3 foi impedido de ser distribuído sob a ameaça de um processo de patente [11].

Existem maneiras de lidar com as patentes: podemos procurar evidências de que uma patente é inválida, e nós podemos procurar formas alternativas para realizar uma tarefa. Mas esses métodos funcionam apenas algumas vezes; quando ambos falham, uma patente pode forçar o software livre a deixar a desejar com respeito a uma funcionalidade que os usuários querem. Após uma longa espera, as patentes expiram, mas o que vamos fazer até então?

Aqueles de nós que valorizam o software livre por amor à liberdade vão ficar com software livre de qualquer maneira. Vamos conseguir realizar as tarefas sem as funcionalidades patenteadas. Mas aqueles que valorizam o software livre porque esperam que ele seja tecnicamente superior tendem a chamá-lo de fracasso quando uma patente o detém. Assim, embora seja útil falar sobre a eficácia prática do modelo de desenvolvimento “bazar”, bem como a confiabilidade e poder de alguns softwares livres, não devemos parar por aí. Temos que falar sobre liberdade e princípio.

Documentação livre

A maior deficiência nos sistemas operacionais livres não está no software — é a falta de bons manuais livres que possamos incluir em nossos sistemas. A documentação é uma parte essencial de qualquer pacote de software; quando um importante pacote de software livre não vem com um bom manual livre, essa é uma grande lacuna. Temos muitas dessas lacunas hoje.

Documentação livre, como o software livre, é uma questão de liberdade, não de preço. O critério para um manual livre é praticamente o mesmo que para o software livre: é uma questão de dar a todos os usuários certas liberdades. Redistribuição (incluindo a venda comercial) deve ser permitida, on-line e em papel, de modo que o manual possa acompanhar cada cópia do programa.

Permissão para modificação também é crucial. Como regra geral, eu não acredito que é essencial que as pessoas tenham permissão para modificar todos os tipos de artigos e livros. Por exemplo, eu não acho que você ou eu somos obrigados a dar permissão para modificação de artigos como este, que descrevem as nossas ações e nossos pontos de vista.

Mas há uma razão específica porque a liberdade de modificações é crucial para a documentação do software livre. Quando as pessoas exercerem o seu direito de modificar o software, e adicionar ou alterar as suas funcionalidades, se eles forem sensatos irão mudar o manual também — para que possam fornecer documentação precisa e usável com o programa modificado. Um manual não livre, que não permite que os programadores sejam sensatos e terminem o trabalho, não satisfaz as necessidades da nossa comunidade.

Alguns tipos de limites sobre como as modificações são feitas não representam qualquer problema. Por exemplo, os requisitos para preservar aviso de direitos autorais do autor original, os termos de distribuição, ou a lista de autores, são aceitáveis. Também não é problema exigir que versões modificadas incluam um aviso identificando-as como tal, ou mesmo ter seções inteiras que não podem ser excluídas ou alteradas, desde que essas seções lidem com tópicos não técnicos. Esses tipos de restrições não são um problema, porque elas não impedem o programador consciente de adaptar o manual para corresponder ao programa modificado. Em outras palavras, elas não impedem a comunidade de software livre de fazer pleno uso do manual.

No entanto, deve ser possível modificar todo o conteúdo técnico do manual, e depois distribuir o resultado em todos os meios usuais, através de todos os canais usuais; caso contrário, as restrições obstruem a comunidade, o manual não é livre, e nós precisamos de outro manual.

Terão os desenvolvedores de software livre a consciência e determinação para produzir um espectro completo de manuais livres? Mais uma vez, o nosso futuro depende da filosofia.

Devemos falar sobre liberdade

As estimativas atuais são de que existem dez milhões de usuários do sistemas GNU/Linux, como Debian GNU/Linux e Red Hat “Linux”. O software livre tem desenvolvido tamanhas vantagens práticas que os usuários estão migrando para ele por razões puramente práticas.

As boas consequências disto são evidentes: mais interesse no desenvolvimento do software livre, mais clientes para as empresas do software livre, e mais capacidade de incentivar as empresas a desenvolver software livre comercial, em vez de produtos de software privativo.

Mas o interesse no software está crescendo mais rápido do que a consciência na filosofia sobre a qual ele se baseia, e isso leva a problemas. A nossa capacidade para enfrentar os desafios e ameaças descritas acima depende da vontade de defender firmemente a liberdade. Para nos certificarmos de que nossa comunidade tem essa vontade, precisamos difundir a ideia para os novos usuários conforme eles chegam à nossa comunidade.

Mas não estamos conseguindo fazê-lo: os esforços para atrair novos usuários para nossa comunidade estão superando de longe os esforços para ensiná-los a educação cívica da nossa comunidade. Precisamos fazer as duas coisas, e precisamos manter os dois esforços em equilíbrio.

“Código Aberto” (“Open Source”)

Ensinar novos usuários sobre a liberdade tornou-se mais difícil em 1998, quando uma parte da comunidade decidiu parar de usar o termo “software livre” (free software) e, em vez disso, começou a dizer “código aberto” (open source).

Alguns que favoreceram este termo visaram evitar a confusão de “livre” com “grátis” — um objetivo válido. Outros, no entanto, com o objetivo de anular os princípios que haviam motivado o movimento do software livre e o projeto GNU, atraíram executivos e usuários de negócios, muitos dos quais carregam uma ideologia que coloca o lucro acima da liberdade, acima da comunidade, acima dos princípios. Assim, a retórica do “código aberto” incide sobre o potencial de fazer software poderoso e de alta qualidade, mas evita as ideias de liberdade, comunidade e princípios.

As revistas do “Linux” são um exemplo claro disso — eles estão cheias de anúncios de software privativo, que funciona com GNU/Linux. Quando a próxima Motif ou Qt aparecer, irão essas revistas alertar os programadores, ou será que vão exibir anúncios dela?

Aparte dos demais fatores o apoio das empresas pode contribuir para a comunidade de muitas maneiras e é útil. Mas ganhar o apoio deles, falando menos ainda sobre liberdade e princípios pode ser desastroso; isso faz o desequilíbrio entre divulgação e educação cívica ainda pior.

“Software livre” e “código aberto” descrevem a mesma categoria de software, mais ou menos, mas dizem coisas diferentes sobre o software, e sobre valores. O Projeto GNU continua a usar o termo “software livre”, para expressar a ideia de que liberdade, não apenas tecnologia, é importante.

Tente!

O aforismo de Yoda (“‘Tentar’ não há”) soa bem, mas ele não funciona para mim. Eu tenho feito a maior parte do meu trabalho com a ansiedade de não saber se eu teria sucesso, e sem a certeza de que ter sucessor seria suficiente para atingir a meta. Mas eu tentei de qualquer maneira, porque não havia ninguém além de mim entre o inimigo e minha cidade. Para minha surpresa, algumas vezes eu tive sucesso.

Algumas vezes eu falhei; e algumas das minhas cidades desmoronaram. Então eu encontrava outra cidade ameaçada, e me preparava para outra batalha. Com o tempo, aprendi a olhar para as ameaças e colocar-me entre elas e minha cidade, convidando outros hackers para vir e se juntar a mim.

Hoje em dia, muitas vezes eu não sou o único. É um alívio e uma alegria quando vejo um regimento de hackers cavando para manter as trincheiras, e eu percebo que esta cidade pode sobreviver — por enquanto. Mas os perigos são maiores a cada ano, e agora a Microsoft está explicitamente alvejando nossa comunidade. Nós não podemos tomar o futuro da liberdade por garantido. Não tome por garantido! Se você quiser manter sua liberdade, você deve estar preparado para defendê-la.

Notas de rodapé

1. O uso do termo “hacker” significando “violador de segurança” é uma confusão causada pelos meios de comunicação de massa. Nós hackers nos recusamos a reconhecer este significado, e continuamos usando a palavra com o significado de alguém que ama programar, alguém que aprecia brincadeiras inteligentes, ou a combinação dos dois. Veja meu artigo, On Hacking (em inglês).
2. Como um ateu eu não sigo líderes religiosos, mas às vezes eu percebo que admiro algo que algum deles disse.
3. Em 1984 ou 1985, Don Hopkins (um companheiro muito imaginativo) enviou-me uma carta. No envelope ele havia escrito vários dizeres divertidos, incluindo este: “Copyleft — todos os direitos revertidos”. Eu usei a palavra “copyleft” para nomear o conceito de distribuição que eu estava desenvolvendo no momento.
4. Agora usamos a Licença de Documentação Livre GNU para documentação.
5. “Bourne Again Shell” (Interpretador de Comandos “Renascido”) é um trocadilho com o nome “Bourne Shell” (Interpretador de Comandos Bourne), que era o interpretador de comandos costumeiro do Unix.
6. Isso foi escrito em 1998. Em 2009 já não mantemos uma longa lista de tarefas. A comunidade desenvolve software livre tão rápido que nem sequer podemos acompanhá-los. Em vez disso, nós temos uma lista de projetos de alta prioridade, uma lista muito mais curta de projetos nos quais queremos encorajar as pessoas a trabalhar.
7. Esta licença é agora chamada de Licença Pública Geral GNU Reduzida (GNU Lesser General Public License), para evitar passar a ideia de que todas as bibliotecas deveriam usá-la. Consulte Por que você não deve usar a GPL Reduzida para a sua próxima biblioteca para mais informações.
8. nota de 2008: este problema estende-se também à BIOS. Há uma BIOS livre, LibreBoot (uma distribuição do coreboot); o problema está em conseguir especificações para as máquinas de modo que LibreBoot possa suportá-las sem “blobs” não livres.
9. Em setembro de 2000, Qt foi relançada sob a GNU GPL, o que essencialmente resolveu este problema.
10. Desde 2009, as patentes do GIF expiraram.
11. Desde 2017, as patentes do MP3 expiraram. Veja quanto tempo tivemos que esperar.