summaryrefslogtreecommitdiff
path: root/talermerchantdemos/blog/articles/br/thegnuproject.html
diff options
context:
space:
mode:
Diffstat (limited to 'talermerchantdemos/blog/articles/br/thegnuproject.html')
-rw-r--r--talermerchantdemos/blog/articles/br/thegnuproject.html1108
1 files changed, 1108 insertions, 0 deletions
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 @@
+<!--#set var="ENGLISH_PAGE" value="/gnu/thegnuproject.en.html" -->
+
+<!--#include virtual="/server/header.pt-br.html" -->
+<!-- Parent-Version: 1.86 -->
+
+<!-- This file is automatically generated by GNUnited Nations! -->
+<title>Sobre o Projeto GNU - Projeto GNU - Free Software Foundation</title>
+<meta http-equiv="Keywords" content="GNU, Projeto GNU, FSF, Software Livre, Free Software Foundation, História" />
+
+<!--#include virtual="/gnu/po/thegnuproject.translist" -->
+<!--#include virtual="/server/banner.pt-br.html" -->
+<h2>O Projeto GNU</h2>
+
+<p>
+por <a href="http://www.stallman.org/"><strong>Richard Stallman</strong></a></p>
+
+<blockquote>
+<p>
+Originalmente publicado no livro <em>Open Sources</em>. Richard Stallman <a
+href="/philosophy/open-source-misses-the-point.html">nunca foi um apoiante
+do “código aberto”</a>, mas contribuiu com este artigo para que as ideias do
+movimento de software livre não estivessem totalmente ausentes naquele
+livro.
+</p>
+<p>
+Por que é mais importante do que nunca <a
+href="/philosophy/free-software-even-more-important.html">insistir que o
+software que usamos seja livre</a>.
+</p>
+</blockquote>
+
+<h3>A primeira comunidade de compartilhamento de software</h3>
+<p>
+Quando comecei a trabalhar no Laboratório de Inteligência Artificial do
+<abbr title="Massachusetts Institute of Technology">MIT</abbr> (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.</p>
+<p>
+O laboratório de IA usava um sistema operacional de tempo compartilhado
+chamado <abbr title="Incompatible Timesharing System">ITS</abbr> (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
+<abbr title="Programmed Data Processor">PDP</abbr>-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.</p>
+<p>
+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.</p>
+<p>
+(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, <a
+href="http://stallman.org/articles/on-hacking.html">On Hacking</a> (em
+inglês).</p>
+
+<h3>O colapso da comunidade</h3>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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”.</p>
+<p>
+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.</p>
+<p>
+Quando os publicantes de software falam sobre “exercer” seus “direitos” ou
+“acabar com a <a
+href="/philosophy/words-to-avoid.html#Piracy">pirataria</a>”, o que eles
+realmente estão <em>dizendo</em> é 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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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 <a
+href="/philosophy/why-free.html">http://www.gnu.org/philosophy/why-free.html</a>
+e <a
+href="/philosophy/free-software-even-more-important.html">http://www.gnu.org/philosophy/free-software-even-more-important.html</a>.
+</p>
+
+<h3>Uma escolha moral difícil</h3>
+<p>
+Com a minha comunidade desfeita, continuar como antes era impossível. Em vez
+disso, eu enfrentei uma escolha moral difícil.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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?</p>
+<p>
+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.</p>
+<p>
+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 <a
+href="/gnu/pronunciation.html">uma sílaba com g forte</a>.</p>
+<p>
+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.</p>
+<p>
+Mais tarde, ouvi estas palavras, atribuídas a Hillel (1):</p>
+
+<blockquote><p>
+ Se eu não for por mim, quem será por mim?<br />
+ Se eu for só por mim, o que eu sou?<br />
+ Se não for agora, quando?
+</p></blockquote>
+<p>
+A decisão de iniciar o projeto GNU foi baseada em um espírito semelhante.</p>
+<p>
+(1) Como um ateu eu não sigo líderes religiosos, mas às vezes eu percebo que
+admiro algo que algum deles disse.</p>
+
+<h3>Livre como em liberdade</h3>
+<p>
+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.</p>
+
+<p>Um programa é software livre, para você, um usuário em particular, se:</p>
+
+<ul>
+ <li>Você tem a liberdade para executar o programa como quiser, para qualquer
+finalidade.</li>
+
+ <li>Você tem a liberdade de modificar o programa para atender às suas
+necessidades. (Para fazer esta liberdade efetiva na prática, você deve ter
+acesso ao código-fonte, uma vez que fazer mudanças em um programa sem ter o
+código fonte é extremamente difícil).</li>
+
+ <li>Você tem a liberdade de redistribuir cópias, seja gratuitamente ou por uma
+taxa.</li>
+
+ <li>Você tem a liberdade de distribuir versões modificadas do programa, de modo
+que a comunidade possa se beneficiar de suas melhorias.</li>
+</ul>
+<p>
+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.</p>
+<p>
+Por causa da ambiguidade do termo “free”<sup><a
+href="#TransNote1">1</a></sup> (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.</p>
+
+<h3>Software GNU e o sistema GNU</h3>
+<p>
+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.</p>
+<p>
+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.</p>
+
+<h3>Começando o projeto</h3>
+<p>
+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.</p>
+<p>
+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.</p>
+
+<h3>Os primeiros passos</h3>
+<p>
+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
+<em>v</em>). 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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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 <abbr title="GNU Compiler Collection">GCC</abbr>
+(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.</p>
+
+<h3>GNU Emacs</h3>
+<p>
+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.</p>
+<p>
+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?</p>
+<p>
+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 <abbr title="Self-addressed
+Stamped Envelope">SASE</abbr> (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.</p>
+
+<h3>Um programa é livre para qualquer usuário?</h3>
+<p>
+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, <a
+href="/philosophy/categories.html#PublicDomainSoftware">software de domínio
+público</a> (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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+
+<h3>O Copyleft e a GNU GPL</h3>
+<p>
+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)</p>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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”.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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)</p>
+<p>
+(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.</p>
+
+<p>
+(2) Agora usamos a <a href="/licenses/fdl.html">Licença de Documentação
+Livre GNU</a> (GNU Free Documentation License) para documentação.</p>
+
+<h3>A Free Software Foundation</h3>
+
+<p>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 <a href="http://www.fsf.org/">Free Software
+Foundation</a> (FSF), uma instituição de caridade isenta de impostos para o
+desenvolvimento do software livre. A <abbr title="Free Software
+Foundation">FSF</abbr> 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.</p>
+
+<p>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 <a href="http://shop.fsf.org/">vende manuais e
+outros apetrechos</a>, mas a maior parte do seu financiamento vem de doações
+de seus membros. Você pode participar da FSF em <a
+href="http://fsf.org/join">fsf.org</a>.</p>
+
+<p>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 <abbr title="Bourne Again Shell">BASH</abbr>, o Bourne Again Shell(1),
+que foi desenvolvido pelo empregado da FSF, Brian Fox.</p>
+
+<p>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.</p>
+
+<p>(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.</p>
+
+<h3>Suporte ao software livre</h3>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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”.</p>
+
+<h3>Objetivos técnicos</h3>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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).</p>
+
+<p>Estas decisões permitiram que muitos programas GNU superassem os seus
+equivalentes Unix em confiabilidade e velocidade.</p>
+
+<h3>Computadores doados</h3>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<h3>A lista de tarefas GNU</h3>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>(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.</p>
+
+<h3>A GNU GPL para Bibliotecas (GNU Library GPL)</h3>
+
+<p>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?</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>(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 <a
+href="/philosophy/why-not-lgpl.html">Por que você não deve usar a GPL
+Reduzida para a sua próxima biblioteca</a> para mais informações.</p>
+
+<h3>Colocar o dedo na ferida?</h3>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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 <abbr title="Lempel-Ziv-Welch">LZW</abbr>. Encontramos pessoas para
+desenvolver a LessTif, e mais recentemente começamos o <abbr title="GNU
+Network Object Model Environment">GNOME</abbr> 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.</p>
+<p>
+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.</p>
+
+<h3>Desenvolvimentos inesperados</h3>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+
+<h3>O GNU Hurd</h3>
+<p>
+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.</p>
+<p>
+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.</p>
+
+<h3>Alix</h3>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+
+<h3>Linux e GNU/Linux</h3>
+<p>
+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.</p>
+
+<p>
+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.</p>
+<p>
+Nós chamamos esta versão do sistema <a
+href="/gnu/linux-and-gnu.html">GNU/Linux</a>, 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, <a
+href="/gnu/gnu-linux-faq.html">nos dê menção igual</a>.</p>
+
+<h3>Desafios para o futuro</h3>
+<p>
+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.</p>
+<p>
+As quatro seções seguintes abordam esses desafios.</p>
+
+<h3>Hardware secreto</h3>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+(nota de 2008: este problema estende-se também à BIOS. Há uma BIOS livre, <a
+href="http://www.libreboot.org/">LibreBoot</a> (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).</p>
+
+<h3>Bibliotecas não livres</h3>
+<p>
+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 <em>executaria</em> 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.</p>
+<p>
+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.</p>
+<p>
+Entre 1996 e 1998, uma outra biblioteca não livre de kit de ferramentas para
+<abbr title="Graphical User Interface">GUI</abbr>, chamada Qt, foi usada em
+uma coleção substancial de software livre, o <abbr title="K Desktop
+Environment">KDE</abbr>.</p>
+<p>
+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.</p>
+<p>
+A comunidade do software livre respondeu ao problema de duas formas: GNOME e
+Harmony (Harmonia).</p>
+<p>
+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.</p>
+<p>
+Harmony é uma biblioteca substituta compatível, projetada para tornar
+possível executar software KDE sem usar Qt.</p>
+<p>
+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).</p>
+<p>
+[Nota subsequente: em setembro de 2000, Qt foi relançada sob a GNU GPL, o
+que essencialmente resolveu este problema].</p>
+<p>
+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.</p>
+
+<h3>As patentes de software</h3>
+<p>
+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 <abbr
+title="Graphics Interchange Format">GIF</abbr>s comprimidos. [Em 2009 elas
+expiraram]. Em 1998, um programa livre para produzir áudio comprimido em
+<abbr title="MPEG-1 Audio Layer 3">MP3</abbr> 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.]
+</p>
+<p>
+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?</p>
+<p>
+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.</p>
+
+<h3>Documentação livre</h3>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+No entanto, deve ser possível modificar todo o conteúdo <em>técnico</em> 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.</p>
+<p>
+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.</p>
+
+<h3>Devemos falar sobre liberdade</h3>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+
+<h3>“Código Aberto” (“Open Source”)</h3>
+<p>
+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).</p>
+<p>
+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.</p>
+<p>
+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?</p>
+<p>
+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.</p>
+<p>
+“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.</p>
+
+<h3>Tente!</h3>
+<p>
+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.</p>
+<p>
+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.</p>
+<p>
+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.</p>
+
+<div class="translators-notes">
+
+<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
+<h3>Notas do tradutor</h3>
+<ol>
+<li id="TransNote1">Em inglês a palavra “free” é ambígua e pode significar
+tanto “livre” quanto “gratuito”.</li>
+</ol></div>
+</div>
+
+<!-- for id="content", starts in the include above -->
+<!--#include virtual="/server/footer.pt-br.html" -->
+<div id="footer">
+<div class="unprintable">
+
+<p>Envie perguntas em geral sobre a FSF e o GNU para <a
+href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Também existem <a
+href="/contact/">outros meios de contatar</a> a FSF. Links quebrados e
+outras correções ou sugestões podem ser enviadas para <a
+href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>
+
+<p>
+<!-- TRANSLATORS: Ignore the original text in this paragraph,
+ replace it with the translation of these two:
+
+ We work hard and do our best to provide accurate, good quality
+ translations. However, we are not exempt from imperfection.
+ Please send your comments and general suggestions in this regard
+ to <a href="mailto:web-translators@gnu.org">
+
+ &lt;web-translators@gnu.org&gt;</a>.</p>
+
+ <p>For information on coordinating and submitting translations of
+ our web pages, see <a
+ href="/server/standards/README.translations.html">Translations
+ README</a>. -->
+A equipe de traduções para o português brasileiro se esforça para oferecer
+traduções precisas e de boa qualidade, mas não estamos isentos de erros. Por
+favor, envie seus comentários e sugestões em geral sobre as traduções para
+<a
+href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.
+</p><p>Consulte o <a href="/server/standards/README.translations.html">Guia
+para as traduções</a> para mais informações sobre a coordenação e o envio de
+traduções das páginas deste site.</p>
+</div>
+
+<!-- Regarding copyright, in general, standalone pages (as opposed to
+ files generated as part of manuals) on the GNU web server should
+ be under CC BY-ND 4.0. Please do NOT change or remove this
+ without talking with the webmasters or licensing team first.
+ Please make sure the copyright date is consistent with the
+ document. For web pages, it is ok to list just the latest year the
+ document was modified, or published.
+
+ If you wish to list earlier years, that is ok too.
+ Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
+ years, as long as each year in the range is in fact a copyrightable
+ year, i.e., a year in which the document was published (including
+ being publicly visible on the web or in a revision control system).
+
+ There is more detail about copyright years in the GNU Maintainers
+ Information document, www.gnu.org/prep/maintain. -->
+<p>Copyright &copy; 1998, 2001, 2002, 2005, 2006, 2007, 2008, 2010, 2014, 2015,
+2017, 2018, 2020 Richard Stallman</p>
+
+<p>Esta página está licenciada sob uma licença <a rel="license"
+href="http://creativecommons.org/licenses/by-nd/4.0/deed.pt_BR">Creative
+Commons Atribuição-SemDerivações 4.0 Internacional</a>.</p>
+
+<!--#include virtual="/server/bottom-notes.pt-br.html" -->
+<div class="translators-credits">
+
+<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
+Tradução por:
+<a href="http://oitofelix.freeshell.org/">Bruno Félix Rezende Ribeiro</a> <a
+href="mailto:oitofelix@gnu.org">&lt;oitofelix@gnu.org&gt;</a>, 2015;
+Rafael Fontenelle <a
+href="mailto:rafaelff@gnome.org">&lt;rafaelff@gnome.org&gt;</a>, 2020</div>
+
+<p class="unprintable"><!-- timestamp start -->
+Última atualização:
+
+$Date: 2020/07/25 12:31:02 $
+
+<!-- timestamp end -->
+</p>
+</div>
+</div>
+<!-- for class="inner", starts in the banner include -->
+</body>
+</html>