![[imagem do que é GNU]](/graphics/whats-gnu-sm.jpg)
[
Catalão
| Chinês(Simplificado)
| Chinês(Tradicional)
| Tchéco
| Inglês
| Francês
| Finlandês
| Alemão
| Indonésio
| Italiano
| Koreano
| Português
| Russo
| Espanhol
]
por Richard Stallman
publicado originalmente no livro "Open Sources"
[
Catalão
| Chinês(Simplificado)
| Chinês(Tradicional)
| Tchéco
| Inglês
| Francês
| Finlandês
| Alemão
| Indonésio
| Italiano
| Koreano
| Português
| Russo
| Espanhol
]
Quando eu comecei a trabalhar no Laboratório de Inteligência Artificial do MIT (N.d.T. Massachussets Institute of Technology) em 1971, eu me tornei parte de uma comunidade que compartilhava software que existia a muitos anos. Compartilar software não era limitado apenas para nossa comunidade particular; é tão antigo quanto os computadores, assim como compartilhar receitas é tão antigo quanto cozinhar. Mas nós fizemos mais do que a maioria.
O Laboratório de IA usava um sistema operacional de tempo compartilhado chamado ITS (N.d.T. Incompatible Timesharing System) que a equipe de hackers do laboratório (1) havia desenvolvido e escrito na linguagem assembler para o Digital PDP-10, um dos maiores computadores da era. Como um membro dessa comunidade, um membro da equipe de hackers do laboratório de IA, meu trabalho era melhorar esse sistema.
Nós não chamávamos o nosso software de "software livre", pois esse termo não existia ainda; mas era isso o que ele era. Sempre que alguém de outra universidade ou companhia queria portar e usar o programa, nós permitiámos isso com prazer. Se você visse um programa diferente e interessante, você sempre podia pedir para ver o código fonte, então você poderia lê-lo, alterá-lo, ou retirar algumas partes dele para fazer um novo programa.
(1) O uso do termo "hacker" significando "alguém que quebra segurança" é uma confusão por parte da mídia das massas. Nós hackers nos recusamos a reconhecer este significado, e continuamos utilizando a palavra significando "Alguém que ama programar e gosta de saber fazê-lo com esperteza."
A situação mudou drasticamente no início dos anos 80 quando a Digital não continuou com a série PDP-10. Sua arquitetura, elegante e poderosa nos anos 60, não poderia cumprir as exigências tecnológicas cada vez maiores que estavam se tornando populares nos anos 80. Isso significou que todos os programas que compunham o ITS estavam obsoletos.
A comunidade hacker do laboratório de AI havia entrado em colapso, não muito antes. Em 1981, a recém criada Symbolics contratou quase todos os hackers do laboratório de IA, e a comunidade despopulada não conseguiu se manter. (O Livro Hackers, de Steve Levy, descreve estes eventos, e também mostra claramente a comunidade no seu início.) Quando o laboratório de IA comprou um novo PDP-10 em 1982, seus administradores decidiram usar o sistema de tempo compartilhado da Digital, que não era livre, ao invés do ITS.
Os computadores modernos da era, como o VAX ou o 68020, possuiam seus próprios sistemas operacionais, mas nenhum deles era livre: você tinha que assinar um contrato de sigilo até mesmo para obter uma cópia executável.
Isso siginificou que o primeiro passo para utilizar um computador era prometer não ajudar o seu vizinho. Uma comunidade cooperativa era proibida. A regra feita pelos donos dos software proprietários era, "Se você compartilhar com o seu vizinho, você é um pirata. Se você quer alguma mudança, nos implore para fazê-la."
A idéia de que o sistema social do software proprietário--o sistema que diz que você não é autorizado a compartilhar ou alterar o software-- é anti-social, que é anti-ético, que é simplesmente errado, pode vir como uma surpresa para alguns leitores. Mas o que mais nós poderíamos dizer sobre um sistema baseado em dividir o público e manter os usuários sem ajuda ? Leitores que acham a idéia surpreendente talvez tenham aceitado a idéia do sistema de software proprietário, ou a julgaram de acordo com os termos sugeridos pelo mercado de software proprietário. O mercado do sofware trabalhou duro e durante muito tempo para convencer as pesosas de que só há um modo de encarar este assunto.
Quando o mercado do software fala sobre "defender" os seus "direitos" ou "parar com a pirataria", o que eles *dizem* na verdade é secundário. A mensagem real destas afirmações está nas suposições sem fundamentos que eles tomam por verdade; o público é concidionado a aceitá-las sem críticas. Então, vamos examiná-las.
Uma suposição é que as companhias de software possuem um direito natural inquestionável de serem proprietárias de um software e assim ter poder sobre todos os seus usuários (Se isso fosse um direito natural, então não importariam os danos que ele causaria no público, nós não poderíamos fazer objeções.) Interessantemente, a Constituição dos EUA e a tradição legal rejeitam este ponto de vista; copyright não é um direito legal, mas um monopólio artificial imposto pelo governo que limita o direito natural dos usuários de copiar.
Outra suposição sem fundamento é que a unica coisa importante sobre um software é que trabalhos ele permite a você realizar--que nós, usuários dos computadores, não deveríamos nos preocupar com que tipo de sociedade nós somos autorizados a possuir.
Uma terceira suposição é que nós não teríamos software utilizável (ou nunca haveria um programa para realizar este ou aquele trabalho particular) se nós não oferecessemos à uma companhia poder sobre os usuários do programa. Esta suposição talvez parecera plausível, antes do movimento do software livre demonstrar que nós podemos criar softwares muito úteis sem colocar correntes nele.
Se nós nos recusarmos a aceitar estas suposições, e julgarmos estes assuntos baseados no senso comum moral, colocando o usuário em primeiro lugar, nós chegamos a várias conclusões diferentes. Usuários de computador deveriam ser livres para modificar os programas de modo que se adequem às suas necessiadades, e ser livre para compartilhar software, pois ajudar os outros é a base da nossa sociedade.
Não há espaço aqui para um discurso extenso sobre o racicínio por trás desta conclusão, então eu encaminho o leitor á pagina, http://www.gnu.org/philosophy/why-free.pt.html.
Com o fim da minha comunidade, continuar como antes era impossível. Ao invés disso, eu encarei uma escolha moral definitiva.
A opção fácil era se juntar ao mundo do software proprietário, assinando acordos que me obrigavam a manter sigilo e prometendo não ajudar meu companheiro hacker. Provavelmente eu também estaria desenvolvendo software que seria distribuído sob acordos sigilosos, fazendo, assim, com que outras pessoas traíssem os seus companheiros também.
Eu poderia ter ganho dinheiro dessa maneira, e talvez me divertido muito escrevendo códigos. Mas eu sabia que no fim da minha carreira, eu olharia para trás e veria que passei a vida construindo paredes para dividir as pessoas, e eu sentiria que eu gastei minha vida tornando o mundo um lugar pior.
Eu já tive a experiência de estar do outro lado deste tipo de acordo, quando alguém se recusou a dar ao MIT e a mim o código fonte para o programa de controla da nossa impressora. (A falta de certas propriedades neste programa fez com que o uso da nossa impressora fosse extremamente frustrante.) Então eu não poderia dizer a mim mesmo que estes tipos de acordos eram inocentes. Eu fiquei muito nervoso quando ele se recusou a compartilhar o código conosco; eu não poderia me virar e fazer a mesma coisa com as outras pessoas.
Outra escolha, direta mas pouco prazerosa, era abandonar o campo da computação. Desta forma minhas habilidades não iriam apenas ser mal utilizadas, também seriam disperdiçadas. Eu não seria o culpado por dividir e restringir os usuários de computador, embora fosse acontecer de qualquer maneira.
Então eu procurei um caminho que levaria um programador a fazer algo para o bem. Eu perguntei a mim mesmo se existia um programa ou programas que eu pudesse escrever, e desse modo tornar uma comunidade possível mais uma vez ?
A resposta era clara: o que era preciso, em primeiro lugar, era um sistema operacional. Este é o software crucial para utilizar um computador. Com um sistema operacional voce pode fazer muitas coisas; sem um, você não pode nem mesmo ligar o computador. Com um sistema operacional livre, nós poderíamos mais uma vez ter uma comunidade de hackers cooperativos--e convidar qualquer um para fazer parte. E assim qualquer um seria capaz de usar um computador sem começar a conspirar para retirar a liberdade de seus amigos.
Como um desenvolvedor de sistema operacional, eu possuia as habilidades certas para esse trabalho. Então mesmo que eu não tomasse o sucesso como garantido, eu sabia que tinha sido eleito para o trabalho. Eu decidi fazer um sistema compatível com o Unix, sendo assim seria portável e os usuários do Unix poderiam migrar facilmente para ele. O nome GNU foi escolhido seguindo a tradição hacker, como um acrônimo recursivo para "GNU's Not Unix" (N.d.T. GNU não é Unix.)
Um sistema operacional não significa apenas um kernel (N.d.T. núcleo), ele quase é suficiente para executar outros programas. Nos anos 70, todo sistema operacional de nome incluía processadores de comandos, compiladores, montadores, interpretadores, debugadores, editores de texto, clientes de email, e muito mais. O ITS tinha estes programas, o Multics também, o VMS possuía-os e o Unix também os tinha. O sistema operacional GNU também iria incluí-los.
Mais tarde eu ouvi estas palavras, atribuídas as Hillel (1):
Se eu não estou aqui para mim mesmou, quem estará pra mim ?
Se eu estou aqui apenas para mim mesmo, o que sou eu ?
Se não agora, quando ?
A decisão de iniciar o projeto GNU foi baseada num espírito similar.
(1) Como um Ateísta, eu não sigo nenhum líder religioso, mas algumas vezes eu admiro algumas coisas que um deles dizem.
O termo "software livre" é mal interpretado algumas vezes--não tem nada haver com preço. Ele se refere à liberdade. Aqui, então, está a definição de software livre: um programa é software livre, para você, usuário qualquer, se:
Desde que "livre" se refere a liberdade, não à preço, não existe nenhuma contradição entre venda de cópias e software livre. Na verdade, a liberdade de vender cópias é crucial: coletâneas de softwares livres vendidas em CD-ROMs são importantes para a comunidade, e vende-las é um jeito importante de arrecadar fundos para o desenvolvimento de software livre. Portanto, um programa que as pessoas não são livres para incluir nestas coletâneas não é um software livre.
Devido à ambigüidade de "livre", as pessoas têm a muito procurado por alternativas, mas ninguém encontrou uma alternativa apropriada. A Língua Inglesa possui mais palavras e nuances do que qualquer outra, mas carece de uma palavra simples e não ambígua que signifique "livre", como na liberdade--"liberado" é a palavra que chega mais perto do significado. Algumas alternativas como "liberdade" e "aberto" possuem ou o significado errado ou outra desvantagem.
(N.d.T. O trecho acima se deve ao fato de a palavra "free" no inglês significar tanto algo que é gratuito quanto algo que é livre, por isso a dificuldade de encontrar um termo adequado na lingua inglesa.)
Desenvolver um sistema completo é um projeto muito grande. Para conseguir realizá-lo eu decidi adaptar e utilizar fragmentos de software livre onde quer que fosse possível. Por exemplo, eu decidi desde o princípio utilizar o TeX como a principal ferramenta para formatar textos; alguns anos mais tarde, eu decidi utilizar o sistema X Window ao invés de escrever outro sistema de janelas para o GNU.
Devido a esta decisão, o sistema GNU não é o mesmo que a coletânea de todos os softwares GNU. O sistema GNU inclui programas que não são softwares GNU, programas que foram desenvolvidos por outras pessoas e projetos para seus próprios propósitos, mas nós podemos usá-los pois eles são softwares livres.
Em Janeiro de 1984 I me demiti do meu emprego no MIT e comecei a escrever software GNU. Deixar o MIT era necessário pois assim o MIT não seria capaz de interferir na distribuição do GNU como software livre. Se eu tivesse permanecido na equipe, o MIT poderia reclamar o trabalho como dele, e poderia impor seus próprios termos de distribuição, ou mesmo tornar o trabalho em um pacote de software proprietário. Eu não tinha a intenção de fazer uma grande quantidade de trabalho para ve-lo se tornar inútil em seu propósito original: criar 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 utilizando as instalações do laboratório.
Um pouco antes de começar o projeto GNU eu ouvi falar sobre o Kit de Compilador da Universidade Livre, também conhecido como VUCK (N.d.T. Free Universitary Compiler Kit). (A palavra holandesa para "livre" é escrita com V.) Este era um compilador projetado para lidar com múltiplas linguagens, incluíndo C e Pascal, e para suportar muitas plataformas. Eu escrevi para o seu autor perguntando se o GNU poderia usá-lo.
Ele respondeu com desdém, deixando claro que a universidade era livre mas o compilador não. Eu, portanto, decidi que meu primeiro programa para o projeto GNU serria um compilador multi-linguagem e multi-plataforma.
Com a esperança de evitar a necessidade de escrever um compilador inteiro sozinho, eu obtive o código fonte do compilador Pastel, que era um compilador multi-plataforma desenvolvido no Laboratório Lawrence Livermore. Ele suportava e era escrito em uma versão extendida do Pascal, projetado para ser uma linguagem de programação a nível de sistemas. Eu adicionei um front end para a linguagem C e comecei a portá-lo para o computador Motorola 68000. Mas eu tive que desistir quando eu descobri que o compilador utilizava muitos megabytes em sua pilha, e o sistema Unix disponível para 68000 permitia somente a utilização de 64k.
Então eu percebi que o compilador Pastel funcionava interpretando um arquivo inteiro como entrada em uma árvore sintática, convertendo toda a ávore sintática em uma cadeia de intruções e então gerando o arquivo de saída de uma vez, sem nenhuma liberação de memória. Nesse ponto, eu concluí que eu teria que escrever um compilador novo, do zero. Este compilador novo é conhecido atualmente como GCC; nenhum código do compilador Pastel foi utilizado nele, mas eu dei um jeito de adaptar e gerenciar o front end para C que eu havia escrito para ele. Mas isso foi alguns anos mais tarde; primeiro eu trabalhei no Emacs.
Eu comecei a trabalhar no GNU Emacs em Setembro de 1984, e no início de 1985 ele estava começando a se tornar utilizável. Isso me permitiu começar utilizar sistemas Unix para fazer edição; não tendo nenhum interesse em aprender a usar o vi ou o ed, eu havia feito até então minhas edições em outros tipos de máquinas.
Nesse ponto, as pessoas começaram a querer utilizar o GNU Emacs, o que trouxe à tona a questão de como distribuí-lo. Claro, eu coloquei ele no servidor anônimo de ftp no computador do MIT que eu utilizava. (Este computador, prep.ai.mit.edu, se tornou então o principal local de distribuição do GNU; quando foi descomissionado alguns anos mais tarde, nós transferimos o nome para o nosso novo servidor de ftp.) Mas naquele tempo, muitas das pessoas interessadas não estava na Internet e não eram capazes de conseguir uma cópia por ftp. Então a questão era, o que eu diria a elas ?
Eu poderia ter dito, "Encontre um amigo que esta na internet e que irá fazer uma cópia para você." Ou eu poderia ter feito o que eu fiz com o Emacs original do PDP-10: dizer a eles, "Me mandem uma fita e os selos necessários por correio que eu lhe enviarei a fita de volta com o Emacs gravado nela." Mas eu não tinha emprego, e eu estava procurando maneiras de ganhar dinheiro através do software livre. Então eu anunciei que eu iria enviar uma fita para quem quizesse uma, por uma taxa de US$150. Deste modo, I comecei um negócio de distribuição de software livre, o precursor das companhias que hoje distribuem sistemas Linux baseados no GNU.
Se um programa é um software livre então quando ele deixa as maõs do seu autor, isso não significa necessariamente que ele será livre para todos que tiverem uma cópia dele. Por exemplo, software de domínio público (software que não tem direitos autorais) é um fotware livre; mas qualquer um pode criar uma versão proprietária apartir dele. Dessa mesma forma, muitos programas livres possuem direitos autorais mas são distribuídos sob licenças simples e permissivas que permitem que sejam feitas versões proprietárias apartir deles.
O exemplo paradigmático deste problema é o sistema X Window. Desenvolvido no MIT e distribuído como um software livre com uma licença permissiva, rápidamente foi adotado por várias companhias de computadores. Eles adicionaram o X aos seus sistemas Unix proprietários, na forma binária apenas, e aplicaram o mesmo acordo de não revelar. Estas cópias do X não eram mais livres do que o Unix.
Os desenvolvedores do sistema X Window não consideraram isso um problema-- eles esperavam e queriam que isso acontecesse. O objetivo deles não era liberdade, apenas "sucesso", definido como "possuir muitos usuários." Eles não ligavam se esses usuários tinham liberdade, contanto que eles fossem muitos.
Isso leva a uma situação paradóxica onde dois modos diferentes de contar a quantidade de liberdade dão diferentes respostas para a quetão,"Este programa é livre?" Se você julgou baseado na liberdade proveniente pelos termos de distribuição do MIT, você diria que o X era um software livre. Mas se você mediu a liberdade da maioria dos usuários do X, voce diria que ele é um software proprietário. A maior parte dos usuários do X estavam rodando as versões proprietárias que vinham com os sistemas Unix, não a versão livre.
O objetivo do GNU era dar liberdade aos usuários, não apenas ser popular. Então nós precisávamos de termos de distribuição que previnissem que softwares GNU se tornassem softwares propietários. O método que nós usamos é chamado "copyleft".(1)
O copyleft utiliza as leis de direitos autorais, mas as interpreta de uma maneira diferente, para servir à um propósito oposto ao usual: ao invés de significar a privatização de um software, significa que o software deve ser mantido livre.
A idéia central do copyleft é que nós damos permissão a todos para rodar o programa, copiar o programa, modificar o programa e distribuir versões modificadas--mas não damos permissões para adicionar suas próprias restrições no programa. Sendo assim, a liberdade crucial que define o "software livre" é ganratida a todos que possuem uma cópia; eles se tornam direitos inalteráveis.
Para um copyleft efetivo, versões modificadas também devem ser livres. Isso assegura que o trabalho baseado nos nossos fiquem à disposição da comunidade se eles forem distribuídos. Quando programadores atuam como programadores voluntários para melhorara o software GNU, é o copyleft que previne que seus empregadores digam, "Você não pode compartilhar aquelas alterações, pois nós vamos utilizá-las para criar nossa versão propietária do programa."
Requerer que as mudanças sejam livres é essencial se nós queremos assegurar a liberdade para qualquer usuário do programa. As companhias que privatizaram o sistema X Window geralmente faziam algumas mudanças para portá-lo para os seus sitemas e hardware. Estas mudanças eram pequenas comparadas com a grande extensão do X, mas não eram mudanças triviais. Se fazer mudanças é uma desculpa para negar liberdade aos usuários, seria fácil para qualquer um tirar vantagem dessa desculpa.
Um assunto relacionado diz respeito em combinar um programa livre com um código não-livre. Tal combinação seria inevitávelmente não-livre; qualquer que seja a liberdade que esteja faltando na parte não-livre não estaria presente no todo também. Permitir tais combinações iria abrir um buraco grande o suficiente para afundar um navio. Porém, uma obrigação do copyleft é concertar este buraco: se alguma coisa for adicionada ou combinada com um programa copyleft, esta nova versão também deve ser livre e sob os termos do copyleft.
A implementação específica do copyleft que nós utilizamos para a maior parte dos softwares GNU é a Licença Pública Geral, ou simplismente GNU GPL (N.d.T. GNU General Public License.) Nós temos outros tipos de copyleft que são utilizados em circunstâncias específicas. Manuais GNU também estão sob of termos do copyleft, mas usam um tipo de copyleft muito mais simples, pois a complexidade da GNU GPL não é necessária para manuais.
(1) Em 1984 ou 1985, Don Hopkins (um amigo com muita imaginação) me enviou uma carta. No envelope ele havia escrito muitas coisas engraçadas, incluíndo esta aqui: "Copyleft--todos os direitos reservados." Eu utilizei a palavra "copyleft" para nomer o conceito de distribuição que eu estava desenvolvendo naquela época.
Como o interesse em usar o Emacs estava crescendo, outras pessoas se envolveram no projeto GNU, e nós decidimos que era hora de buscar fundos mais uma vez. Então em 1985 nós criamos a Fundação do Software Livre, uma instituição de caridade isenta de impostos para o desenvolvimento do software livre. A FSF (N.d.T. Free Software Fundation) também se encarregou do negócio de distribuição do Emacs através de fitas; mais tarde ela ampliou este negócio através da adição de outros softwares livres (GNU e não-GNU) às fitas, e por vender manuais livres também.
A FSF aceita doações, mas a maior parte dos lucros sempre vem das vendas-- de cópias de softwares livres e outros serviços relacionados. Hoje ela vende CD-ROMs contendo código fonte, CD-ROMs com binários, manuais muito bem impressos (tudo com a liberdade de redistribuir e modificar), e também coletãneas personalizadas (onde nós montamos uma coleção de softwares para a plataforma de sua escolha.)
Os empregados da Fundação do Software Livre escrevem e mantêm um bom número de pacotes de softwares GNU. Dois notáveis são a biblioteca C e o shell. A bibliteca GNU C é o que todos os programas que executam em um sistema GNU/Linux usam para se comunicar com o Linux. Ela foi desenvolvida por um membro da equipe da Fundação do Software Livre, Roland McGrath. O shell utilizada na maior parte dos sistemas GNU/Linux é o BASH, o Bourne Again Shell(1) (N.d.T Shell Bourne Novamente), que foi desenvolvido pelo empregado da FSF Brian Fox.
Nós começamos o desenvolvimento destes programas pois o projeto GNU não era apenas sobre ferramentas ou ambientes de desenvolvimento. Nosso objetivo era um sistema operacional completo, e estes programas eram necessários para atingir este objetivo.
(1) ``Bourne again Shell'' é uma paródia do nome ``Bourne Shell'', que era o shell do Unix.
A filosofia do software livre rejeita a prática de grandes negócios específicos, mas não é contra os negócios. Quando os negócios respeitam a liberdade do usuário, nós desejamos sucesso a eles.
A venda de cópias do Emacs demonstrou um tipo de negócio em cima do software livre. Quando a FSF passou a controlar este negócio, eu precisei encontrar outro meio de ganhar a vida. E eu econtrei um modo, era prestar serviços relacionados ao softwares livres que eu havia desenvolvido. Isso incluía ensinar, assuntos sobre como programar no GNU Emacs e como customizar o GCC, e o desenvolvimento de software, geralmente portando o GCC para novas plataformas.
Hoje, cada um desses tipos de negócios baseados no software livre são práticados por um grande número de corporações. Algumas distribuem coletâneas de software livre em CD-ROM; outras prestam suporte, desde como responder questões dos usuários ao concerto de bugs e adição de novas propriedades aos softwares. Nós estamos começando a ver até mesmo companhias de software livre produzindo e distribuíndo novos produtos.
Porém, tome cuidado--um grande número de companhias que se associam com o termo "código aberto" na verdade baseiam seus negócios em softwares não-livres que trabalham com software livre. Estas não são companhias de software livre, são companhias de software proprietários cujos produtos tiram a liberdade do usuário. Eles os chamam de "valor agregado", que reflete os valores que eles gostariam que nós adotássemos: conveniência acima da liberdade. Se valorizamos mais a liberdade, nós devemos chamar estes produtos de "liberdade reduzida".
O principal objetivo do GNU era ser software livre. Mesmo que o GNU não tivesse nenhuma vantágem técnica sobre o Unix, ele possuíria uma vantagem social, permitindo aos usuários a cooperação, e uma vantagem ética, respeitando a liberdade do usuário.
Mas era natural aplicar os padrões conhecidos de boas praticas ao trabalho-- por exemplo, alocação dinamica de estrutura de dados para evitar tamanhos arbitrários com limites fixos, e manusear todos os códigos possíveis de 8 bits onde quer que fizesse sentido.
Ainda mais, nós rejeitamos o foco do Unix em pequeno espaço de memória, decidindo não suportar máquinas de 16 bits (estava claro que as máquinas de 32 bits dominariam o mercado quando o sistema GNU estivesse finalizado), e não fazer nenhum esforço para reduzir o uso da memória a menos que ele excedesse um megabyte. Em programas onde o manejo de arquivos muito grande não era crucial, nós encorajamos os programadores a ler um arquivo de entrada direto na memória, e então explorar o seu conteúdo sem ter que se preocupar com E/S.
Estas decisões permitiram que muitos programas GNU superassem seus concorrentes do Unix em confiabilidade e desempenho.
Como a reputação do projeto GNU cresceu, as pessoas começaram a se oferecer para doar máquinas que rodavam UNIX para o projeto. Estas eram muito úteis, pois a maneira mais facil de desenvolver os componentes do GNU era faze-lo em um sistema UNIX, e substituir os componentes daquele sistema, um por um. Mas então surgiu uma questão ética: se era certo nós possuirmos uma cópia do UNIX.
O UNIX era (e ainda é) um software proprietário, e a filosofia do projeto GNU diz que nós não deveríamos utilizar softwares proprietários. Mas, aplicando o mesmo raciocínio que nos leva a concluir que violência em se tratando de auto defesa é justificável, eu concluí que era válido utilizar um pacote proprietário quando este era crucial para o desenvolvimento de um substituto livre que iria ajudar outros a parar com o uso de pacotes de softwares proprietários.
Mas, mesmo que isso fosse um mal justificável, ainda sim era um mal. Hoje nós não temos mais nenhuma cópia do Unix, pois nós substituimos todas por sistemas operacionais livres. Se nós não conseguíamos substituir o sistema operacional da máquina por um livre, ao invés disso nós substituíamos a máquina.
Com a continuidade do projeto GNU, e o crescente número de componentes do sistema prontos ou em desenvolvimento, eventualmente se tornou necessário fazer uma lista do que faltava ser implementado. Nós recrutávamos desenvolvedores para escrever estas partes que faltavam. Esta lista ficou conhecida como a lista de tarefas GNU. Além dos componentes do Unix que estavam faltando, nós adicionamos vários outros softwares úteis à lista e também projetos de documentação que nós achamos que um sistema operacional completo é obrigado a ter.
Hoje, poucos componentes do Unix ainda estão na lista de tarefas GNU-- aqueles trabalhos foram realizados, assim como alguns não tão essenciais. Mas a lista está cheia de projetos que alguns podem chamar de "aplicações". Qualquer programa que serve para mais de uma classe de usuários é uma coisa útil para se adicionar em um sistema operacional.
Até mesmo jogos estão inclusos na lista de tarefas--e foram inclusos desde o começo. O Unix incluía jogos, então o GNU, naturalmente, também deveria. Mas a compatibilidade não era um assunto discutível em relação aos jogos, então nós não seguimos a lista de jogos que o Unix tinha. Ao invés disso, nós fizemos uma lista de diferentes tipos de jogos que os usuários gostariam de jogar.
A biblioteca GNU C usa um tipo de copyleft especial chamado de Licença Pública Geral para Bibliotecas GNU (N.d.t. GNU Library General Public License, GNU LGPL), que permite que softwares proprietários sejam linkados na biblioteca. Por que fazer esta excessão ?
Não é uma questão de princípios, não há nenhum princípio que diz que softwares proprietários devam incluir nossos códigos. (Por que contribuir com um projeto que insiste em não compartilhar conosco?) Utilizar a biblioteca GNU LGPL para a biblioteca C, ou para qualquer outra biblioteca, é uma questão de estratégia.
A biblioteca C faz um trabalho genérico; todos os sistemas ou compiladores proprietários possuem uma biblioteca C. Portanto, tornar nossa biblioteca C disponível apenas para o software livre não daria nenhuma vantagem ao software livre--iria apenas desencorajar o uso da nossa biblioteca.
Um sistema é uma excessão à isto: no sistema GNU (e isso inclui o GNU/Linux), a biblioteca GNU C é a única biblioteca C. Então os termos de distribuição da biblioteca GNU C determinam se é possível compilar um software proprietário para o sistema GNU. Não há nenhuma questão ética em permitir aplicações proprietárias no sistema GNU, mas estratégicamente parece que negar isso seria um ato que iria desencorajar mais o uso do sistema GNU do que encorajar o desenvolvimento de aplicações livres.
Por isso utilizar a LGPL é uma boa estratégia para a biblioteca C. Para outras bibliotecas, a decisão estratégica precisa ser considerada, cada caso é um caso. Quando uma biblioteca realiza um trabalho especial que por ajudar na escrita de certos tipos de programas, então distribuí-la sob a GPL, limitando-a para programas livres apenas, é uma maneira de ajudar outros desenvolvedores de software livre, dando a eles uma vantagem contra o software proprietário.
Considere a GNU Readline, uma biblioteca que foi desenvolvida para prover edição de linha de comando para o BASH. A Readline é distribuída sob a licença GNU GPL comum e não a LGPL. Isso provavelmente reduz a utilização da Readline, em termos de quantidade de usuários, mas isto não é uma perda para nós. Na verdade, se a Readline foi empregada com sucesso em pelo menos um software livre específico, então este é o ganho real para a comunidade.
Os desenvolvedores de softwares proprietários possuem as vantagens que o dinheiro prove; os desenvolvedores de software livre precisam criar vantagens entre si. Eu espero que algum dia nós tenhamos uma grande coleção de bibliotecas sob a GPL, que não possuam paralelos disponíveis para o software proprietário, provendo módulos úteis que sirvam como blocos de construção em novos softwares livres, e criando mais vantagens para o aprofundamento no desenvolvimento de software livre.
Eric Raymond diz que "Todo bom projeto de software começa com uns rabiscos pessoais do desenvolvedor." Talvez isso aconteça algumas vezes, mas muitas partes essenciais dos softwares GNU foram desenvolvidas com o objetivo de ter um sistema operacional livre completo. Elas vieram de uma visão e um plano, não do impulso.
Por exemplo, nós desenvolvemos a biblioteca GNU C por que um sistema baseado no Unix precisa de uma bibloteca C, o Boure-Again Shell (bash) pois um sistema baseado no Unix precisa de um shell, o GNU tar pois um sistema baseado no Unix precisa de um programa do tipo tar. O mesmo é verdade para os meus próprios programas--o GNU C Compiler, o GNU Emacs, GDB e o GNU Make.
Alguns programas GNU foram desenvolvidos para lidar com aspectos específicos em relação à nossa liberdade. Sendo assim, nós desenvolvemos o gzip para substituir o programa Compress, que foi uma perda para a comunidade devido às patentes LZW. Nós encontramos pessoas para desenvolver o LessTif, e mais recentemente foi começado o GNOME e o Harmony, para resolver os problemas causados por certas bibliotecas proprietárias (veja abaixo). Nós estamos desenvolvendo o GNU Privacy Guard para substituir o popular e não livre software de criptografia, pois os usuários não devem precisar escolher entre privacidade e liberdade.
É claro, as pessoas que escrevem estes programas ficam interessadas no trabalho, e muitas novas características foram adicionadas à eles devido aos próprios interesses pessoais e necessidades. Mas esse não é o motivo da existência dos programas.
No início do projeto GNU, eu imaginei que nós iríamos desenvolver o sistema GNU completo, então distribuílo como uma unidade. Não foi assim que isso aconteceu.
Como cada componente do sistema GNU foi implementado em um sistema Unix, cada componente podia rodar em sistemas Unix, muito antes do sistema GNU existir. Alguns destes programas se tornaram populares, e os usuários começaram a extende-los e portá-los--para as várias versões incompatíveis do Unix, e algumas vezes para outros sistemas também.
Este processo tornou estes programas muito mais poderosos, e atraiu tanto fundos como contribuidores para o projeto GNU. Mas ele provavelmente também atrasou a finalização de um sistema mínimo funcional em muitos anos, pois o tempo dos desenvolvedores GNU era gasto mantendo estas versões portadas e adicionando novas propriedades aos componentes existentes, ao invés de continuar a escrever as partes que faltavam.
Por volta de 1990, o sistema GNU estava quase completo; o que faltava era um kernel. Nós decidimos implementar o nosso kernel como uma coleção de servidores rodando sobre o Mach. O Mach é um microkernel desenvolvido na Universidade Carneige Mellon e na Universidade de Utah; o GNU HURD é uma coleção de servidores (ou ``horda de gnus'') que executam em cima do Mach, e realizam os vários trabalhos do kernel do Unix. O início do desenvolvimento foi atrasado pois nós estávamos esperando que o Mach fosse distribuído como um software livre, como foi prometido.
Uma das razões para escolher este design era evitar o que parecia ser a parte mais difícil do trabalho: debugar um kernel sem um debugador a nível de código disponível. Esta parte do trabalho já havia sido feita, no Mach, e nós esperávamos debugar os servidores do HURD como programas normais, com o GDB. Mas levou um tempo muito longo para tornar isso possível, e os servidores multi-threaded que enviam mensagens uns para os outros se tornaram muito difícil de debugar. Tornar o HURD um trabalho sólido levou muitos anos.
O kernel GNU originalmente não era para se chamar HURD. Seu nome original era Alix--recebeu esse nome devido a uma mulher que foi minha amada na época. Ela, uma administradora de sistemas Unix, citou como o nome dela seria perfeito de acordo com os padrões de nomenclatura seguidos nas versões do Unix; e, só por brincadeira, ela disse aos seus amigos, "Alguem deveria criar um kernel com o meu nome." Eu não disse nada, mas decidi fazer uma surpresa para ela com um kernel chamado Alix.
Não ficou com esse nome por muito tempo. Michael Bushnell (agora Thomas), o principal desenvolvedor do kernel, preferiu o nome HURD, e redefiniu Alix para se referir a uma certa parte do kernel--a parte que captura as chamadas de sistema e manipula-as através do envio de mensagens para os servidores HURD.
Enfim, Alix e eu terminamos, e ela mudou o nome dela; independentemente, o design do HURD foi alterado de modo que a biblioteca C enviaria mensagens diretamente para os servidores, e isso fez com que o componente Alix desaparecesse do projeto.
Mas antes disso tudo acontecer, um amigo dela ficou sabendo que o nome Alix estava no código fonte do HURD, e mencionou isso para ela. Assim, o nome fez o seu trabalho.
O GNU Hurd não está pronto para uso em sistemas de produção. Felizmente, outro kernel está disponível. Em 1991, Linus Torvalds desenvolveu um kernel compatível com o Unix e o chamou de Linux. Por volta de 1992, a combinação do Linux com o incompleto sistema GNU resultou em um sistema operacional livre completo. (Combiná-los foi um trabalho substancial por si próprio, claro.) É devido ao Linux que na verdade nós podemos executar versões do sistema GNU hoje.
Nós chamamos esta versão do sistema de GNU/Linux, para expressar sua composição como uma combinação do sistema GNU utilizando o Linux como kernel.
Nós provamos nossa habilidade de desenvolver um amplo espectro de software livre. Isso não significa que nós somos invencíveis ou que nada pode nos deter. Muitos desafios fazem com que o futuro do software livre seja incerto; enfrentá-los irá exigir esforços firmes e resistência, algumas vezes que duram por anos. Irá exigir o tipo de determinação que as pessoas mostram quando percebem o valor da sua liberdade e não deixarão ninguém tirá-la delas.
As próximas quatro seções discutem estes desafos.
Montadoras de hardware tendem cada vez mais a manter as especificações do hardware em segredo. Isso torna dificil escrever drivers livres de modo que o Linux e o XFree86 possam suportar novos hardwares. Nós possuímos um sistema completo hoje, mas nós não o teremos amanha se não conseguirmos rodar o sistema nos computadores de amanhã.
Há duas maneiras de lidar com este problema. Os programadores podem utilizar da engenharia reversa para entender como suportar o hardware. O resto de nós pode escolher hardware que é suportado pelo software livre; como nós crescemos em número a cada dia, manter as especificações em segredo irá se tornar uma política de auto-destruição.
Engenharia reversa é um grande trabalho; nós teremos programadores com determinação suficiente para cuidar disso ? Sim--se nós construirmos um forte sentimento de que o software livre é uma questão de princípios, e drivers não-livres são intoleráveis. E muitos de nós irão gastar dinheiro extra, ou mesmo tempo extra, para poder usar os drivers livres ? Sim, se a determinação para ter liberdade for amplamente dissipada.
Uma biblioteca não-livre que roda em um sistema opreacional livre funciona como uma armadilha para os desenvolvedores de software livre; se você usa a biblioteca, você cai na armadilha, pois o seu programa não pode fazer parte de um sistema operacional livre. (Indo direto ao ponto, nós podemos incluir o seu programa, mas ele não irá executar sem a biblioteca.) Ainda pior, se um programa que usa uma biblioteca proprietária se torna popular, ele pode atrair outros programadores para a armadilha.
A primeira ocorrência deste problema foi com o toolkit Motif, nos anos 80. Embora não houvesse ainda nenhum sistema operacional livre, estava claro o problema que o Motif causaria mais tarde neles. O Projeto GNU respondeu de duas formas: pediu que projetos de softwares livres individuais apoiássem o X toolkit livre e também o Motif, e pediu para alguém escrever um substituto livre para o Motif. O trabalho levou muitos anos para ser concluído; o LessTif, desenvolvido pelos ``Hungry Programmers'' (N.d.T. Programadores Famintos), se tornou poderoso o suficiente para suportar a maior parte das aplicações do Motif apenas em 1997.
Entre 1996 e 1998, outra biblioteca de interface gráfica não-livre, chamada Qt, era utilizada em uma coleção considerável de software livre, o KDE.
Sistemas GNU/Linux livres não eram capazes de utilizar o KDE, pois nós não podíamos usar a biblioteca. Entretanto, alguns distribuidores comerciais do sistema GNU/Linux que não estavam preocupados em ficar do lado da liberdade adicionaram o KDE aos seus sistemas--produzindo um sistema com mais capacidades, mas com menos liberdade. O grupo do KDE estava encorajando mais programadores a utilizar a biblioteca Qt, e milhões de "novos usuários do Linux" nunca foram expostos à idéia de que havia um problema nisso. A situação foi esquecida.
A comunidade de software livre respondeu à este problema de duas maneiras: GNOME e Harmony.
GNOME, o GNU Network Object Model Environment (N.d.T. Ambiente de Rede Modelaroda de Objetos GNU), é o projeto de desktop do GNU. Iniciado em 1997 por Miguel de Icaza, e desenvolvido com o suporte da Red Hat Software, o GNOME se mostrou capaz de prover um ambiente de trabalho similar, mas usando exclusivamente software livre. Ele também possui vantagens técnicas, como suportar uma variedade de linguagens, não apenas C++. Mas o seu propósito principal era liberdade: não exigir que o usuário usasse nenhum software não-livre.
Harmony é uma biblioteca substituta compatível, projetada para tornar possível executar softwares do KDE sem usar a Qt.
Em Novembro de 1998, os desenvolvedores da biblioteca Qt anunciaram uma mudança na licença que, quando lançada, deve tornar a Qt software livre. Não há meios de se ter certeza, mas eu acho que isso se deve em parte à resposta firme da comunidade ao problema que a Qt impos por ser um software não-livre. (A nova licença é inconveniente e inadequada, então ainda é aconselhável evitar a utilização da Qt.)
[Nota subsequente: em Setembro de 2000, a Qt passou a ser distribuída sob os termos da GNU GPL, o que resolveu de vez este problema.]
Como nós iremos responder à próxima tentação de uma biblioteca não-livre ? Irá a comunidade inteira entender a necessidade de se manter fora da armadilha ? Ou muitos de nós irão desistir da liberdade por conveniência, e criar um problema maior? Nosso futuro depende da nossa filosofia.
A pior ameaça que nós enfrentamos vem das patentes de softwares, que podem colocar algoritmos e características fora dos limites do software livre por mais de vinte anos. As patentes do algoritmo de compressão LZW foram solicitadas em 1983, e nós ainda não podemos distribuir softwares livres que produzem GIFs comprimidos. Em 1998, um programa para produzir audio comprimido no formato MP3 foi removido da distribuição devido à uma ameaça de processo por causa da patente.
Existem modos de lidar com as patentes: nós podemos procurar por evidências de que uma patente é inválida, e nós podemos prcurar caminhos alternativos para realizar um trabalho. Mas cada um destes métodos funciona apenas algumas vezes; quando ambos falham, uma patente pode forçar todo software livre a ficar carente de alguma propriedade que os usuários querem. O que nós faremos quando isso acontecer ?
Aqueles de nós que valorizam o software livre pelo fator da liberdade continuaraão com o software livre de qualquer maneira. Nós iremos dar um jeito de continuar fazendo nossos trabalhos sem as propriedades patenteadas. Mas aqueles que valorizam o software livre pois esperam que ele técnicamente superior irão considerar isso uma falha quando as patentes entrarem em ação. Sendo útil falar sobre a efetividade prática do modelo de desenvolvimento conhecido como "catedral"(1) , e sobre a confiabilidade e o poder de alguns softwares livres, nós não podemos parar por aí. Nós devemos discutir a liberdade e os princípios.
A maior deficiência em nossos sistemas operacionais livres não está no software--é a falta de bons manuais livres que nós devemos remediar em nossos sistemas. Documentação é uma parte essencial de qualquer pacote de software; quando um pacote de software livre importante não vem com um bom manual livre, isso é uma falha grande. Nós temos muitas falhas como essa hoje.
Documentação livre, assim como o software livre, é uma questão de liberdade, não de preço. O critério para um manual livre é muito parecido com o do software livre: é uma questão de dar a todos os usuários certas liberdades. Redistribuição (incluíndo venda) deve ser permitida, on-line e impressa, assim o manual pode acompanhar cada cópia do programa.
Permissão para modificação é crucial também. Como uma regra greal, eu não acredito que é essencial para as pessoas possuírem permissão para modificar todos os tipos de artigos e livros. Por exemplo, eu não acho que você ou eu somos obrigados a permitir que artigos como este sejam modificados, que descrevem nossas ações e nossos pontos de vista.
Mas existe uma razão particular do porque a liberdade de modificar é crucial para documentação para softwares livres. Quando as pessoas exercitam o seu direito de modificas o software, e adicionar ou alterar suas propriedades, se elas possuem consciência elas irão modificar o manual também--provendo então documentação fiel e compatível com o programa modificado. Um manual que não permite que o programador o modifique e termine o trabalho, não serve às necessidades da comunidade.
Alguns tipos de limites sobre como as modificações são feitas não apresentam problemas. Por exemplo, exigências de preservar o aviso dos direitos autorais do autor original, dos termos de distribuição, ou da lista de autores, não apresentam problemas. Não há problemas também em exigir que versões modificadas incluam avisos dizendo que elas foram modificadas, ou mesmo possuir avisos alertando que existem seções inteiras que não podem ser deletadas nem alteradas, desde que estas seções sejam não sejam de índole técnica. Estes tipos de restrições não são um problema pois eles não podem impedir que o programador adapte o manual para se adequar ao programa modificado. Em outras palavras, elas não impedem que a comunidade de software livre faça uso completo do manual.
Entretanto, deve ser possível modificar todo o conteúdo *técnico* do manual, e então redistribuir o resultado nos meios normais de comunicação, através dos canais normais; caso contrário, as restrições obstruem a comunidade, o manual não é livre, e nós precisáremos de um outro manual.
Será que os desenvolvedores de software terão a consciência e a determinação para produzir um espectro completo de manuais livres ? Mais uma vez, nosso futuro depende da nossa filosofia.
Estima-se que hoje haja dez milhões de usuários dos sistemas GNU/Linux como o Debian GNU/Linux e o Red Hat Linux. O software livre vem desenvolvendo tantas vantagens práticas de modo que os usuários estão aderindo à ele por razões puramente práticas.
A boa conseqüência disso é evidente: mais interesse no desenvolvimento de software livre, mais consumidores para o mercado de software livre, e mais habilidade para encorajar as companhias a desenvolverem softwares livres comerciais ao invés de produtos proprietários.
Mas o o interesse no software está crescendo mais rápido do que a consciência na filosofia em que ele é baseado, e isso leva a um problema. Nossa habilidade de lidar com os desafios e ameaças mencionadas anteriormente depende da determinação de se manter firme pela liberdade. Para ter certeza de que nossa comunidade tem essa determinação, nós precisamos espalhar a ídeia para os novos usuários assim que eles entrarem na comunidade.
Mas nós estamos falhando nisso: os esforços para atrair novos usuários para a nossa comunidade estão longe dos esforços para ensiná-los os compromissos cívicos da nossa comunidade. Nós precisamos fazer ambos, e nós precisamos manter os dois esforços em equilíbrio.
Ensinar sobre liberdade para os novos usuários se tornou mais difícil em 1998, quando uma parte da comunidade decidiu parar de utilizar o termo "software livre" e passou a dizer "software de código aberto".
Alguns que são a favor deste termo tentam evitar a confusão de "livre" com "gratis"--um ponto válido. Outros, porém, tentam deixar de lado o espírito do princípio que tem motivado o movimento do software livre e o projeto GNU, e apelam para executivo e usuários comerciais, muitos dos quais possuem uma ideologia que coloca o lucro acima da liberdade, acima da comunidade, acima dos princípios. Assim, a retórica do "código aberto" é focada no potencial de criar software poderoso e de alta qualidade, mas esconde as idéias de liberdade, comunidade e princípios.
As revistas de "Linux" são um exemplo claro disto--elas estão cheias de propagandas de softwares proprietários que funcionam no GNU/Linux. Quando o próximo Motif ou Qt aparecer, irão estas revistas alertar os programadores para ficarem longe deles, ou iram contribuir com sua divulgação ?
O auxílio do mercado pode contribuir com a comunidade de muitas maneiras; e também é muito útil. Mas conseguir este auxílio através de discursos que falam cada vez menos de liberdade e princípios pode ser desastroso; isso faz com que o desequilíbrio citado anteriormente fique ainda pior.
"Software livre" e "código aberto" descrevem a mesma categoria de sofware, mais ou menos, mas dizem coisas diferentes a respeito do software, e a respeito dos valores. O projeto GNU continua usando o termo "software livre", para expressar a idéia de que liberdade, não apenas técnologia, é importante.
A filosofia do Yoda ("Não existe tentativa") soa bem, mas não funciona para mim. Eu fiz a maior parte dos meus trabalhos ansioso se eu iria conseguir realizar o serviço, e incerto se seria o suficiente para atingir o objetivo se eu o realizasse. Mas eu tentei mesmo assim, pois não havia ninguém além de mim entre o inimigo e a minha cidade. Para minha surpresa, eu obtive sucesso algumas vezes.
Algumas vezes eu falhei; algumas das minhas cidades caíram. Então eu encontrei outra cidade ameaçada, e me preparei para outra batalha. Com o tempo, eu aprendi a olhar para as ameaças e me colocar entre elas e a minha cidade, chamando outros hackers para se juntar a mim.
Atualmente, geralmente eu não sou o único. É um alívio e uma alegria quando eu vejo um regimento de hackers se esforçando para manter a linha, e eu percebo que a cidade pode sobreviver--por enquanto. Mas os perigos ficam maiores a cada ano, e agora a Microsoft apontou explicitamente nossa comunidade como um alvo. Nós não podemos tomar o futuro da liberdade como certo. Não o tome como garantido! Se você quer manter sua liberdade, você deve estar preparado para defende-la.
Retornar à Página Inicial do GNU.
Por favor envie dúvidas ou questões sobre a FSF e/ou GNU para gnu@gnu.org Há também outros meios de contactar a FSF.
Por favor envie comentários sobre essas páginas para webmasters@gnu.org, envie outras questões para gnu@gnu.org.
Copyright (C) 1998, 2001 Richard Stallman.
A cópia fiel e a distribuição deste artigo completo é permitida em qualquer meio, desde que esta nota seja preservada.
Atualizado: $Date: 2004/01/02 01:44:39 $ $Author: gustgr $
Traduzido por: Gustavo Rondina <gustavorondina@uol.com.br>