taler-merchant-demos

thegnuproject.html (61789B)

---

 <!--#set var="ENGLISH_PAGE" value="/gnu/thegnuproject.en.html" -->
 
 <!--#include virtual="/server/header.pt-br.html" -->
 <!-- Parent-Version: 1.96 -->
 <!-- This page is derived from /server/standards/boilerplate.html -->
 <!--#set var="TAGS" value="gnu-history" -->
 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" -->
 
 <!-- This file is automatically generated by GNUnited Nations! -->
 <title>Sobre o Projeto GNU - Projeto GNU - Free Software Foundation</title>
 <style type="text/css" media="print,screen"><!--
 a[href*='#ft'] { font-size: .94em; }
 -->
 </style>
 <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" -->
 <!--#include virtual="/gnu/gnu-breadcrumb.pt-br.html" -->
 <!--GNUN: OUT-OF-DATE NOTICE-->
 <!--#include virtual="/server/top-addendum.pt-br.html" -->
 <div class="article reduced-width">
 <h2>O Projeto GNU</h2>
 
 <address class="byline">por <a href="https://www.stallman.org/">Richard Stallman</a></address>
 
 <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&#8239;<a href="#ft1">[1]</a> 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>
 
 <div class="announcement comment" role="complementary">
 <hr class="no-display" />
 <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>
 <hr class="no-display" />
 </div>
 
 <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 <cite>Hackers</cite>, 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 publicadores 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 publicadores 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 a “<a
 href="/philosophy/why-free.html">Por Que o Software Não Deve Ter Donos</a>”
 e “<a href="/philosophy/free-software-even-more-important.html">Software
 Livre é Ainda Mais Importante Agora</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 <i>g</i>&nbsp;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&#8239;<a
 href="#ft2">[2]</a>:</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>
 
 <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
 <i>v</i>). 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”.&#8239;<a href="#ft3">[3]</a>.</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.&#8239;<a href="#ft4">[4]</a>.</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="https://www.fsf.org/">Free
 Software Foundation</a> (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.</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="https://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="https://my.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 BASH, o Bourne Again Shell&#8239;<a href="#ft5">[5]</a>, 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>
 
 <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&#8239;<a href="#ft6">[6]</a>, 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>
 
 <h3>A GNU Menor GPL</h3>
 
 <p>A biblioteca C GNU usa um tipo especial de copyleft chamado Licença Pública
 Geral Menor GNU&#8239;<a href="#ft7">[7]</a>, 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 Menor é 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 Menor. Isso provavelmente reduz o quanto a Readline é
 usada, mas isso não nos representa perda. Por outro lado, pelo menos uma
 aplicação útil foi feita software livre especificamente para que ela pudesse
 usar a Readline, e isso é um ganho real para a comunidade.</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>
 
 <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>
 
 <h4>Hardware secreto</h4>
 <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&#8239;<a href="#ft8">[8]</a>.</p>
 
 <h4>Bibliotecas não livres</h4>
 <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&#8239;<a href="#ft9">[9]</a>.)</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>
 
 <h4>As patentes de software</h4>
 <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&#8239;<a
 href="#ft10">[10]</a>. 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&#8239;<a
 href="#ft11">[11]</a>.
 </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>
 
 <h4>Documentação livre</h4>
 <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="column-limit"></div>
 
 <h3 class="footnote">Notas de rodapé</h3>
 <ol>
 <li id="ft1">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).</li>
 
 <li id="ft2">Como um ateu eu não sigo líderes religiosos, mas às vezes eu percebo que
 admiro algo que algum deles disse.</li>
 
 <li id="ft3">Em 1984 ou 1985, Don Hopkins (um companheiro muito imaginativo) enviou-me
 uma carta. <a href="/graphics/copyleft-sticker.html">No envelope</a> 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.</li>
 
 <li id="ft4">Agora usamos a <a href="/licenses/fdl.html">Licença de Documentação Livre
 GNU</a> para documentação.</li>
 
 <li id="ft5">“Bourne Again Shell” (Interpretador de Comandos “Renascido”) é um trocadilho
 com o nome “Bourne Shell” (Interpretador de Comandos Bourne), que era o
 interpretador de comandos costumeiro do Unix.</li>
 
 <li id="ft6">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.</li>
 
 <li id="ft7">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.</li>
 
 <li id="ft8">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.</li>
 
 <li id="ft9">Em setembro de 2000, Qt foi relançada sob a GNU GPL, o que essencialmente
 resolveu este problema.</li>
 
 <li id="ft10">Desde 2009, as patentes do GIF expiraram.</li>
 
 <li id="ft11">Desde 2017, as patentes do MP3 expiraram. Veja quanto tempo tivemos que
 esperar.</li>
 </ol>
 
 <div class="infobox extra" role="complementary">
 <hr />
 <p>
 Originalmente publicado no livro <cite>Open Sources</cite>. 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>
 </div>
 </div>
 
 <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" role="contentinfo">
 <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 contributing 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 a
 contribuição com 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, 2005, 2008, 2010, 2012, 2015, 2017, 2018, 2021
 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-2021</div>
 
 <p class="unprintable"><!-- timestamp start -->
 Última atualização:
 
 $Date: 2021/12/26 00:59:53 $
 
 <!-- timestamp end -->
 </p>
 </div>
 </div>
 <!-- for class="inner", starts in the banner include -->
 </body>
 </html>