From 1ae0306a3cf2ea27f60b2d205789994d260c2cce Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Sun, 11 Oct 2020 13:29:45 +0200 Subject: add i18n FSFS --- .../blog/articles/br/thegnuproject.html | 1108 ++++++++++++++++++++ 1 file changed, 1108 insertions(+) create mode 100644 talermerchantdemos/blog/articles/br/thegnuproject.html (limited to 'talermerchantdemos/blog/articles/br/thegnuproject.html') diff --git a/talermerchantdemos/blog/articles/br/thegnuproject.html b/talermerchantdemos/blog/articles/br/thegnuproject.html new file mode 100644 index 0000000..e1ad52c --- /dev/null +++ b/talermerchantdemos/blog/articles/br/thegnuproject.html @@ -0,0 +1,1108 @@ + + + + + + +Sobre o Projeto GNU - Projeto GNU - Free Software Foundation + + + + +

O Projeto GNU

+ +

+por Richard Stallman

+ +
+

+Originalmente publicado no livro Open Sources. Richard Stallman nunca foi um apoiante +do “código aberto”, mas contribuiu com este artigo para que as ideias do +movimento de software livre não estivessem totalmente ausentes naquele +livro. +

+

+Por que é mais importante do que nunca insistir que o +software que usamos seja livre. +

+
+ +

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.

+

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

+ +

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 publicantes de software têm trabalhado muito duro para +convencer as pessoas de que há apenas uma maneira de olhar para o problema.

+

+Quando os publicantes 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 às páginas da web http://www.gnu.org/philosophy/why-free.html +e http://www.gnu.org/philosophy/free-software-even-more-important.html. +

+ +

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 (1):

+ +

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

+

+(1) Como um ateu eu não sigo líderes religiosos, mas às vezes eu percebo que +admiro algo que algum deles disse.

+ +

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:

+ + +

+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”1 (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”.(1)

+

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

+

+(1) 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.

+ +

+(2) Agora usamos a Licença de Documentação +Livre GNU (GNU Free Documentation License) para documentação.

+ +

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(1), +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.

+ +

(1) “Bourne Again Shell” (Interpretador de Comandos “Renascido”) é um +trocadilho com o nome “Bourne Shell” (Interpretador de Comandos Bourne), que +era o interpretador de comandos costumário do Unix.

+ +

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 (1), 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.

+ +

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

+ +

A GNU GPL para Bibliotecas (GNU Library GPL)

+ +

A biblioteca C GNU usa um tipo especial de copyleft chamado Licença Pública +Geral GNU para Bibliotecas(1) (GNU Library General Public License), 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 para +Bibliotecas é 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 para Bibliotecas. 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.

+ +

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

+ +

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.

+

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

+ +

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

+

+[Nota subsequente: em setembro de 2000, Qt foi relançada sob a GNU GPL, o +que essencialmente resolveu este problema].

+

+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. [Em 2009 elas +expiraram]. 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. [Desde 2017, essas +patentes expiraram. Veja quanto tempo tivemos que esperar.] +

+

+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 do tradutor

+
    +
  1. Em inglês a palavra “free” é ambígua e pode significar +tanto “livre” quanto “gratuito”.
    2. +
+ + + + + + + + + -- cgit v1.2.3