diff options
Diffstat (limited to 'talermerchantdemos/blog/articles/br/thegnuproject.html')
-rw-r--r-- | talermerchantdemos/blog/articles/br/thegnuproject.html | 1108 |
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"><gnu@gnu.org></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"><webmasters@gnu.org></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"> + + <web-translators@gnu.org></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"><web-translators@gnu.org></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 © 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"><oitofelix@gnu.org></a>, 2015; +Rafael Fontenelle <a +href="mailto:rafaelff@gnome.org"><rafaelff@gnome.org></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> |