path: root/talermerchantdemos/blog/articles/br/thegnuproject.html

<!--#set var="ENGLISH_PAGE" value="/gnu/thegnuproject.en.html" -->

<!--#include virtual="/server/header.pt-br.html" -->
<!-- Parent-Version: 1.86 -->

<!-- This file is automatically generated by GNUnited Nations! -->
<title>Sobre o Projeto GNU - Projeto GNU - Free Software Foundation</title>
<meta http-equiv="Keywords" content="GNU, Projeto GNU, FSF, Software Livre, Free Software Foundation, História" />

<!--#include virtual="/gnu/po/thegnuproject.translist" -->
<!--#include virtual="/server/banner.pt-br.html" -->
<h2>O Projeto GNU</h2>

<p>
por <a href="http://www.stallman.org/"><strong>Richard Stallman</strong></a></p>

<blockquote>
<p>
Originalmente publicado no livro <em>Open Sources</em>. Richard Stallman <a
href="/philosophy/open-source-misses-the-point.html">nunca foi um apoiante
do “código aberto”</a>, mas contribuiu com este artigo para que as ideias do
movimento de software livre não estivessem totalmente ausentes naquele
livro.
</p>
<p>
Por que é mais importante do que nunca <a
href="/philosophy/free-software-even-more-important.html">insistir que o
software que usamos seja livre</a>.
</p>
</blockquote>

<h3>A primeira comunidade de compartilhamento de software</h3>
<p>
Quando comecei a trabalhar no Laboratório de Inteligência Artificial do
<abbr title="Massachusetts Institute of Technology">MIT</abbr> (Instituto de
Tecnologia de Massachusetts) em 1971, tornei-me parte de uma comunidade de
compartilhamento de software que já existia há muitos anos. A partilha de
software não se limitava à nossa comunidade em particular; ela é tão antiga
quanto os computadores, assim como a partilha de receitas é tão antiga
quanto a culinária. Mas nós a fazíamos mais do que a maioria.</p>
<p>
O laboratório de IA usava um sistema operacional de tempo compartilhado
chamado <abbr title="Incompatible Timesharing System">ITS</abbr> (Sistema de
Compartilhamento de Tempo Incompatível) que a equipe de hackers do
laboratório (1) tinha concebido e escrito em linguagem de montagem para o
<abbr title="Programmed Data Processor">PDP</abbr>-10 da Digital, um dos
imensos computadores da época. Como um membro desta comunidade, um hacker de
sistemas da equipe do laboratório de IA, meu trabalho era melhorar este
sistema.</p>
<p>
Nós não chamávamos o nosso software de “software livre”, porque esse termo
ainda não existia; mas isso é o que era. Sempre que as pessoas de outra
universidade ou empresa queriam portar e usar um programa, tínhamos o prazer
de deixá-los. Se você visse alguém usando um programa desconhecido e
interessante, poderia sempre pedir para ver o código-fonte, para que pudesse
lê-lo, alterá-lo ou canibalizá-lo para fazer um novo programa.</p>
<p>
(1) O uso do termo “hacker” significando “violador de segurança” é uma
confusão causada pelos meios de comunicação de massa. Nós hackers nos
recusamos a reconhecer este significado, e continuamos usando a palavra com
o significado de alguém que ama programar, alguém que aprecia brincadeiras
inteligentes, ou a combinação dos dois. Veja meu artigo, <a
href="http://stallman.org/articles/on-hacking.html">On Hacking</a> (em
inglês).</p>

<h3>O colapso da comunidade</h3>
<p>
A situação mudou drasticamente no início de 1980, quando a Digital
descontinuou a série PDP-10. Esta arquitetura, elegante e poderosa na década
de 60, não poderia ser estendida naturalmente para os espaços de endereços
maiores que estavam se tornando viáveis na década de 80. Isto significa que
praticamente todos os programas que compunham o ITS ficaram obsoletos.</p>
<p>
A comunidade hacker do laboratório de IA já havia entrado em colapso, não
muito antes. Em 1981, a empresa derivada Symbolics havia contratado quase
todos os hackers do laboratório de IA, e a comunidade desfalcada foi incapaz
de manter-se. (O livro Hackers, de Steve Levy, descreve esses eventos, bem
como dá uma imagem clara desta comunidade no seu apogeu). Quando o
laboratório de IA comprou um novo PDP-10 em 1982, seus administradores
decidiram usar o sistema de tempo compartilhado não livre da Digital em vez
do ITS.</p>
<p>
Os computadores modernos da época, como o VAX ou o 68020, tinham seus
próprios sistemas operacionais, mas nenhum deles era software livre: você
tinha de assinar um acordo de confidencialidade até mesmo para obter uma
cópia executável.</p>
<p>
Isto significava que o primeiro passo para usar um computador era prometer
não ajudar o seu próximo. Uma comunidade cooperativa era proibida. A regra
definida pelos donos do software privativo era, “Se você compartilha com seu
próximo, você é um pirata. Se você quer alterações, suplique-nos para
fazê-las”.</p>
<p>
A ideia de que o sistema social do software privativo — o sistema que diz
que você não tem permissão para compartilhar ou modificar o software — é
antissocial, antiético ou simplesmente errado, pode vir como uma surpresa
para alguns leitores. Mas o que mais poderíamos dizer sobre um sistema
baseado na divisão e impotência dos usuários? Os leitores que acham a ideia
surpreendente podem ter tomado por certo o sistema social do software
privativo, ou o julgaram nos termos sugeridos pelas empresas de software
privativo. Os publicantes de software têm trabalhado muito duro para
convencer as pessoas de que há apenas uma maneira de olhar para o problema.</p>
<p>
Quando os publicantes de software falam sobre “exercer” seus “direitos” ou
“acabar com a <a
href="/philosophy/words-to-avoid.html#Piracy">pirataria</a>”, o que eles
realmente estão <em>dizendo</em> é secundário. A mensagem real destas
declarações está nos pressupostos não declarados que eles tomam por certo, e
que o público é induzido a aceitar sem questionar. Vamos, portanto,
examiná-los.</p>
<p>
Um pressuposto é que as empresas de software têm um direito natural e
inquestionável de se apropriar do software e, portanto, têm poder sobre
todos os seus usuários. (Se este fosse um direito natural, então não
importaria quão danoso fosse ao público, não poderíamos
questionar). Curiosamente, a Constituição dos Estados Unidos e a tradição
legal rejeitam essa visão; o direito autoral não é um direito natural, mas
um monopólio artificial imposto pelo governo que limita o direito natural
dos usuários de copiar.</p>
<p>
Outro pressuposto não declarado é que a única coisa importante sobre
software é que tipo de trabalho ele nos permite fazer — que nós, usuários de
computador, não deveríamos nos importar com que tipo de sociedade estamos
autorizados a ter.</p>
<p>
Um terceiro pressuposto é que nós não teríamos nenhum software utilizável
(ou nunca teríamos um programa para fazer este ou aquele trabalho em
particular) se não oferecêssemos a uma empresa poder sobre os usuários do
programa. Esta suposição pode ter parecido plausível, antes do movimento do
software livre demonstrar que podemos fazer software útil em abundância sem
ter de acorrentá-los.</p>
<p>
Se nos recusarmos a aceitar esses pressupostos, e julgarmos estas questões
com base na moralidade ordinária de senso comum enquanto colocamos os
usuários em primeiro lugar, chegamos a conclusões muito diferentes. Os
usuários de computador devem ser livres para modificar os programas de forma
a atender às suas necessidades e devem ser livres para compartilhar o
software, porque ajudar outras pessoas é a base da sociedade.</p>
<p>
Não há espaço aqui para uma extensa declaração do raciocínio que por trás
dessa conclusão, portanto, remeto o leitor às páginas da web <a
href="/philosophy/why-free.html">http://www.gnu.org/philosophy/why-free.html</a>
e <a
href="/philosophy/free-software-even-more-important.html">http://www.gnu.org/philosophy/free-software-even-more-important.html</a>.
</p>

<h3>Uma escolha moral difícil</h3>
<p>
Com a minha comunidade desfeita, continuar como antes era impossível. Em vez
disso, eu enfrentei uma escolha moral difícil.</p>
<p>
A escolha fácil era me juntar ao mundo do software privativo, assinando
acordos de confidencialidade e prometendo não ajudar os meus companheiros
hackers. O mais provável é que eu também estaria desenvolvendo software
liberado sob acordos de confidencialidade, assim aumentando a pressão sobre
outras pessoas para também trair seus companheiros.</p>
<p>
Eu poderia ter feito dinheiro desta forma e, talvez, me divertido escrevendo
código. Mas eu sabia que, no final da minha carreira, eu olharia para trás e
veria anos dedicados à construção de paredes que dividem pessoas, e sentiria
que eu tinha passado a minha vida fazendo do mundo um lugar pior.</p>
<p>
Eu já tinha experimentado os prejuízos de um acordo de confidencialidade
quando alguém se recusou a dar a mim e ao laboratório de IA do MIT, o
código-fonte do programa que controlava nossa impressora. (A falta de certas
funcionalidades neste programa fez o uso dela extremamente
frustrante). Então, eu não poderia me convencer de que acordos de
confidencialidade eram inofensivos. Fiquei muito irritado quando ele se
recusou a compartilhar conosco; eu não podia virar as costas e fazer a mesma
coisa com todos os outros.</p>
<p>
Outra escolha, simples mas desagradável, era deixar o campo da
computação. Dessa forma, minhas habilidades não seriam usadas para o mal,
mas ainda assim seriam desperdiçadas. Eu não seria culpado por dividir e
restringir os usuários de computador, mas tal divisão aconteceria de
qualquer forma.</p>
<p>
Então eu procurei por um jeito de fazer alguma coisa boa como
programador. Perguntei a mim mesmo: existe um programa ou conjunto de
programas que eu possa escrever para formar uma comunidade novamente?</p>
<p>
A resposta foi clara: em primeiro lugar, um sistema operacional era
necessário. Esse é o software crucial para começar a usar um computador. Com
um sistema operacional, você pode fazer muitas coisas; sem ele, o computador
mal funciona. Com um sistema operacional livre, poderíamos voltar a ter uma
comunidade de hackers que cooperam — e convidar qualquer pessoa para
participar — e todos seriam capazes de usar um computador sem ter que
conspirar para privar seus amigos.</p>
<p>
Como um desenvolvedor de sistema operacionais, eu tinha as habilidades
certas para este trabalho. Assim, ainda que eu não pudesse tomar o sucesso
como certo, eu percebi que havia sido eleito para realizar este trabalho. Eu
decidi fazer o sistema compatível com o Unix para que ele fosse portável, e
para que os usuários do Unix pudessem migrar para ele facilmente. O nome GNU
foi escolhido, seguindo uma tradição hacker, como um acrônimo recursivo para
“GNU Não é Unix” (do inglês “GNU’s Not Unix”). É pronunciado como <a
href="/gnu/pronunciation.html">uma sílaba com g forte</a>.</p>
<p>
Um sistema operacional não significa apenas um núcleo, que mal é suficiente
para executar outros programas. Na década de setenta, todos os sistemas
operacionais dignos de serem chamados assim incluíam processadores de
comando, montadores, compiladores, interpretadores, depuradores, editores de
texto, gerentes de correio e muito mais. ITS os tinham, Multics os tinham,
VMS os tinham, e Unix os tinham. O sistema operacional GNU iria incluí-los
também.</p>
<p>
Mais tarde, ouvi estas palavras, atribuídas a Hillel (1):</p>

<blockquote><p>
     Se eu não for por mim, quem será por mim?<br />
     Se eu for só por mim, o que eu sou?<br />
     Se não for agora, quando?
</p></blockquote>
<p>
A decisão de iniciar o projeto GNU foi baseada em um espírito semelhante.</p>
<p>
(1) Como um ateu eu não sigo líderes religiosos, mas às vezes eu percebo que
admiro algo que algum deles disse.</p>

<h3>Livre como em liberdade</h3>
<p>
O termo “software livre” às vezes é mal interpretado — não tem nada a ver
com preço. É sobre liberdade. Aqui, portanto, está a definição de software
livre.</p>

<p>Um programa é software livre, para você, um usuário em particular, se:</p>

<ul>
  <li>Você tem a liberdade para executar o programa como quiser, para qualquer
finalidade.</li>

  <li>Você tem a liberdade de modificar o programa para atender às suas
necessidades. (Para fazer esta liberdade efetiva na prática, você deve ter
acesso ao código-fonte, uma vez que fazer mudanças em um programa sem ter o
código fonte é extremamente difícil).</li>

  <li>Você tem a liberdade de redistribuir cópias, seja gratuitamente ou por uma
taxa.</li>

  <li>Você tem a liberdade de distribuir versões modificadas do programa, de modo
que a comunidade possa se beneficiar de suas melhorias.</li>
</ul>
<p>
Dado que “livre” refere-se à liberdade, não ao preço, não há contradição
entre a venda de cópias e software livre. Na verdade, a liberdade de vender
cópias é crucial: coleções de software livre vendido em CD-ROMs são
importantes para a comunidade, e vendê-los é uma forma importante para
levantar fundos para o desenvolvimento de software livre. Portanto, um
programa que as pessoas não são livres para incluir nessas coleções não é
software livre.</p>
<p>
Por causa da ambiguidade do termo “free”<sup><a
href="#TransNote1">1</a></sup> (do inglês “free software”, isto é, software
livre), as pessoas há muito tempo tem procurado por alternativas, mas
ninguém encontrou um termo melhor. A língua inglesa tem mais palavras e
nuances do que qualquer outro idioma, mas carece de uma palavra simples,
inequívoca, que signifique “livre”, como em “freedom” (liberdade) —
“unfettered” (irrestrito) é a palavra que mais se aproxima deste
significado. Outras alternativas como “liberated” (liberado), “freedom”
(liberdade) e “open” (aberto) tem ou o significado errado ou alguma outra
desvantagem.</p>

<h3>Software GNU e o sistema GNU</h3>
<p>
Desenvolver um sistema inteiro é um projeto muito grande. Para torná-lo
viável, eu decidi adaptar e usar peças existentes de software livre onde
quer que fosse possível. Por exemplo, eu decidi bem no início usar TeX como
o principal formatador de textos; alguns anos mais tarde, eu decidi usar o X
Window System, em vez de escrever outro sistema de janelas para o GNU.</p>
<p>
Devido a estas decisões, e outras como elas, o sistema GNU não é o mesmo que
a coleção de todo o software GNU. O sistema GNU inclui programas que não são
software GNU, programas que foram desenvolvidos por outras pessoas e
projetos para seus próprios propósitos, mas que podemos usar, porque eles
são software livre.</p>

<h3>Começando o projeto</h3>
<p>
Em janeiro de 1984 deixei o meu emprego no MIT e comecei a escrever software
GNU. Deixar o MIT era necessário para que eles não fossem capazes de
interferir com a distribuição do GNU como software livre. Se eu tivesse
permanecido na equipe, o MIT poderia ter reivindicado a titularidade do
trabalho, e poderia ter imposto seus próprios termos de distribuição, ou até
mesmo transformar o trabalho em um pacote de software privativo. Eu não
tinha a intenção de fazer uma grande quantidade de trabalho só para vê-lo
tornar-se inútil para a sua finalidade: a criação de uma nova comunidade de
compartilhamento de software.</p>
<p>
No entanto, o professor Winston, então chefe do laboratório de IA do MIT,
gentilmente me convidou para continuar usando as instalações do laboratório.</p>

<h3>Os primeiros passos</h3>
<p>
Pouco antes do início do Projeto GNU, eu ouvi sobre o “Free University
Compiler Kit” (Kit de Compilador da Universidade Livre), também conhecido
como VUCK. (A palavra holandesa para “livre” é escrita com um
<em>v</em>). Este era um compilador projetado para lidar com múltiplas
linguagens, incluindo C e Pascal, e para suportar múltiplas máquinas de
destino. Eu escrevi ao seu autor perguntando se o GNU poderia usá-lo.</p>
<p>
Ele respondeu com ironia, afirmando que a universidade era livre, mas o
compilador não. Por isso, decidi que meu primeiro programa para o Projeto
GNU seria um compilador de múltiplas linguagens e plataformas.</p>
<p>
Na esperança de evitar a necessidade de escrever o compilador todo eu mesmo,
obtive o código fonte do compilador Pastel, que era um compilador
multiplataforma desenvolvido no “Lawrence Livermore Lab”. Ele suportava, e
havia sido escrito, em uma versão estendida da Pascal, projetada para ser
uma linguagem de programação de sistemas. Eu adicionei um front-end C, e
comecei a portá-la para o computador Motorola 68000. Mas eu tive que
desistir quando eu descobri que o compilador precisava de muitos megabytes
de espaço de pilha, e o sistema Unix 68000 disponível apenas permitia 64k.</p>
<p>
Eu então percebi que o compilador Pastel processava todo o arquivo de
entrada em uma árvore sintática, convertendo toda a árvore sintática em uma
cadeia de “instruções”, e em seguida gerando o arquivo de saída inteiro, sem
nunca liberar qualquer armazenamento. Neste ponto, eu concluí que eu teria
que escrever um novo compilador a partir do zero. Esse novo compilador é
agora conhecido como <abbr title="GNU Compiler Collection">GCC</abbr>
(Coleção de Compiladores GNU); nada do compilador Pastel é usado nele, mas
eu consegui adaptar e usar o front-end C que eu havia escrito. Mas isso foi
alguns anos mais tarde; primeiro, eu trabalhei no GNU Emacs.</p>

<h3>GNU Emacs</h3>
<p>
Comecei a trabalhar no GNU Emacs em setembro de 1984, e no início de 1985
ele estava começando a ficar usável. Isto permitiu-me começar a usar
sistemas Unix para fazer a edição; não tendo interesse em aprender a usar o
vi ou o ed, eu havia feito a minha edição em outros tipos de máquinas até
então.</p>
<p>
Neste ponto, as pessoas começaram a querer usar o GNU Emacs, o que levantou
a questão de como distribuí-lo. Claro, eu o coloquei no servidor de FTP
anônimo do computador MIT que eu usava. (Este computador, prep.ai.mit.edu,
assim tornou-se o principal local de distribuição ftp do GNU; quando foi
descomissionado alguns anos mais tarde, nós transferimos o nome para o nosso
novo servidor ftp). Mas naquele tempo, muitas pessoas interessadas não
estavam na Internet e não poderiam obter uma cópia por ftp. Portanto, a
pergunta era: o que eu diria a elas?</p>
<p>
Eu poderia ter dito, “Encontre um amigo que está na rede e que vai fazer uma
cópia para você”. Ou eu poderia ter feito o que eu fiz com o Emacs original
do PDP-10: dizer-lhes, “Envie-me uma fita e um <abbr title="Self-addressed
Stamped Envelope">SASE</abbr> (Envelope Autoendereçado e com Selo), e eu vou
enviá-lo de volta com uma cópia do Emacs”. Mas eu não tinha trabalho, e eu
estava procurando maneiras de ganhar dinheiro com software livre. Então eu
anunciei que iria enviar uma fita para quem quisesse, por uma taxa de US$
150,00. Desta forma, eu comecei um negócio de distribuição de software
livre, o precursor das empresas que hoje distribuem sistemas GNU/Linux
completos.</p>

<h3>Um programa é livre para qualquer usuário?</h3>
<p>
Se um programa é software livre quando deixa as mãos de seu autor, isso não
significa necessariamente que ele será software livre para todos que tem uma
cópia do mesmo. Por exemplo, <a
href="/philosophy/categories.html#PublicDomainSoftware">software de domínio
público</a> (software que não está sujeito a direitos autorais) é software
livre; mas qualquer pessoa pode fazer uma versão modificada e privativa
dele. Da mesma forma, muitos programas livres estão sujeitos a direitos
autorais, mas são distribuídos sob licenças permissivas simples que permitem
versões modificadas e privativas.</p>
<p>
O exemplo paradigmático desse problema é o X Window System. Desenvolvido no
MIT, e lançado como software livre com uma licença permissiva, logo foi
adotado por diversas empresas de informática. Eles acrescentaram X em seus
sistemas Unix privativos, apenas em forma binária, e abrangidos por um mesmo
contrato de confidencialidade. Estas cópias do X não eram mais software
livre do que o Unix era.</p>
<p>
Os desenvolvedores do X Window System não consideraram isso um problema —
eles esperavam e queriam que isso acontecesse. O objetivo deles não era a
liberdade, apenas “sucesso”, definido como “ter muitos usuários”. Eles não
se importavam se esses usuários teriam liberdade, só que eles deveriam ser
numerosos.</p>
<p>
Isso levou a uma situação paradoxal onde duas formas diferentes de contar a
quantidade de liberdade deram respostas diferentes à pergunta, “Este
programa é livre?”. Se você julgasse com base na liberdade proporcionada
pelos termos de distribuição da liberação do MIT, você diria que o X era
software livre. Mas se você medisse a liberdade do usuário médio do X, você
teria que dizer que era software privativo. A maioria dos usuários do X
estavam executando as versões privativas que vieram com sistemas Unix, e não
a versão livre.</p>

<h3>O Copyleft e a GNU GPL</h3>
<p>
O objetivo do GNU era dar aos usuários liberdade, não apenas ser
popular. Portanto, nós precisávamos usar termos de distribuição que
impediriam o software GNU de ser transformado em software privativo. O
método que usamos é chamado de “copyleft”.(1)</p>
<p>
Copyleft usa a lei de direitos autorais, mas a inverte para servir ao oposto
do seu objetivo usual: em vez de um meio para restringir o programa, ela se
torna um meio para manter o programa livre.</p>
<p>
A ideia central do copyleft é que damos a todos a permissão para executar o
programa, copiar o programa, modificar o programa, e distribuir versões
modificadas — mas não a permissão para adicionar restrições por conta
própria. Assim, as liberdades fundamentais que definem o “software livre”
são garantidas a todos aqueles que tem uma cópia; elas se tornam direitos
inalienáveis.</p>
<p>
Para um copyleft efetivo, versões modificadas devem também ser livres. Isso
garante que trabalho baseado no nosso se torne disponível para nossa
comunidade se ele for publicado. Quando programadores que têm empregos de
programadores se voluntariam para melhorar o software GNU, é o copyleft que
impede os empregadores de dizer, “Você não pode compartilhar essas
alterações, porque vamos usá-las para fazer a nossa versão privativa do
programa”.</p>
<p>
A exigência de que as mudanças devem ser livres é essencial se quisermos
garantir a liberdade de todos os usuários do programa. As empresas que
privatizaram o X Window System normalmente fizeram algumas alterações para
portá-los para os seus sistemas e hardware. Essas mudanças foram pequenas em
comparação com a grande extensão do X, mas elas não foram triviais. Se fazer
mudanças fosse uma desculpa para negar liberdade aos usuários, seria fácil
para qualquer um tirar proveito dessa desculpa.</p>
<p>
Uma questão relacionada diz respeito a combinar um programa livre com código
não livre. Essa combinação seria inevitavelmente não livre; quaisquer
liberdades que faltam para a parte não livre estaria faltando para o todo
também. Permitir tais combinações abriria um buraco grande o suficiente para
afundar um navio. Portanto, um requisito fundamental para o copyleft é
tampar este buraco: o que for adicionado ou combinado com um programa sob
copyleft deve ser tal que a versão combinada total seja também livre e
esteja sob copyleft.</p>
<p>
A implementação específica de copyleft que usamos para a maioria do software
GNU é a Licença Pública Geral GNU (GNU General Public License), ou GNU GPL
para abreviar. Temos outros tipos de copyleft que são utilizados em
circunstâncias específicas. Manuais GNU estão sob copyleft também, mas usam
uma espécie de copyleft muito mais simples, porque a complexidade da GNU GPL
não é necessária para manuais.(2)</p>
<p>
(1) Em 1984 ou 1985, Don Hopkins (um companheiro muito imaginativo)
enviou-me uma carta. No envelope ele havia escrito vários dizeres
divertidos, incluindo este: “Copyleft — todos os direitos revertidos”. Eu
usei a palavra “copyleft” para nomear o conceito de distribuição que eu
estava desenvolvendo no momento.</p>

<p>
(2) Agora usamos a <a href="/licenses/fdl.html">Licença de Documentação
Livre GNU</a> (GNU Free Documentation License) para documentação.</p>

<h3>A Free Software Foundation</h3>

<p>Como o interesse em usar o Emacs foi crescendo, outras pessoas se envolveram
no projeto GNU, e decidimos que era hora de buscar financiamento mais uma
vez. Assim, em 1985 foi criada a <a href="http://www.fsf.org/">Free Software
Foundation</a> (FSF), uma instituição de caridade isenta de impostos para o
desenvolvimento do software livre. A <abbr title="Free Software
Foundation">FSF</abbr> também assumiu o negócio de distribuição de fitas com
o Emacs; mais tarde isso foi estendido adicionando-se outros softwares
livres (tanto GNU quanto não GNU) à fita, e com a venda de manuais livres
também.</p>

<p>A maior parte da renda da FSF costumava vir da venda de cópias de software
livre e de outros serviços relacionados (CD-ROMs com código-fonte, CD-ROMs
com binários, manuais bem impressos, todos com a liberdade de redistribuir e
modificar), e distribuições de luxo (distribuições para as quais
construíamos toda a coleção de software segundo a escolha de plataforma do
cliente). Hoje, a FSF ainda <a href="http://shop.fsf.org/">vende manuais e
outros apetrechos</a>, mas a maior parte do seu financiamento vem de doações
de seus membros. Você pode participar da FSF em <a
href="http://fsf.org/join">fsf.org</a>.</p>

<p>Empregados da Free Software Foundation têm escrito e mantido vários pacotes
de software GNU. Os dois mais notáveis ​​são a biblioteca C e o
interpretador de comandos. A biblioteca C GNU é o que todos os programas em
execução num sistema GNU/Linux usam para se comunicar com o Linux. Ela foi
desenvolvida por um membro da equipe da Free Software Foundation, Roland
McGrath. O interpretador de comandos usado na maioria dos sistemas GNU/Linux
é o <abbr title="Bourne Again Shell">BASH</abbr>, o Bourne Again Shell(1),
que foi desenvolvido pelo empregado da FSF, Brian Fox.</p>

<p>Financiamos o desenvolvimento destes programas porque o Projeto GNU não
dizia respeito apenas a ferramentas ou um ambiente de desenvolvimento. Nosso
objetivo era um sistema operacional completo, e esses programas eram
necessários para atingir este objetivo.</p>

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

<h3>Suporte ao software livre</h3>

<p>A filosofia do software livre rejeita uma prática específica e amplamente
difundida de negócios, mas não é contra os negócios. Quando as empresas
respeitam a liberdade dos usuários, desejamos-lhes sucesso.</p>

<p>A venda de cópias do Emacs demonstra um tipo de negócio de software
livre. Quando a FSF assumiu esse negócio, eu precisava de uma outra maneira
de ganhar a vida. Eu a encontrei na venda de serviços relacionados ao
software livre que eu tinha desenvolvido. Isto incluía ensino, sobre os
temas de como programar o GNU Emacs e como personalizar o GCC, e
desenvolvimento de software, principalmente portando o GCC para novas
plataformas.</p>

<p>Hoje cada um desses tipos de negócio de software livre é praticado por uma
série de empresas. Alguns distribuem coleções de software livre em CD-ROM;
outros vendem suporte em níveis que vão de responder perguntas dos usuários,
à correção de erros, à adição de importantes novas funcionalidades. Estamos
até mesmo começando a ver companhias de software livre baseadas no
lançamento de novos produtos de software livre.</p>

<p>No entanto, tome cuidado — várias empresas que se associam ao termo “open
source” realmente baseiam seus negócios em software não livre que funciona
com software livre. Estas não são empresas de software livre, mas sim
empresas de software privativo cujos produtos seduzem os usuários para longe
da liberdade. Eles chamam esses programas “pacotes de valor agregado”, o que
mostra os valores que eles gostariam que adotássemos: conveniência acima da
liberdade. Se valorizamos mais a liberdade, devemos chamá-los “pacotes de
liberdade desagregada”.</p>

<h3>Objetivos técnicos</h3>

<p>O principal objetivo do GNU é ser software livre. Mesmo se o GNU não tivesse
nenhuma vantagem técnica sobre o Unix, teria uma vantagem social, permitindo
que os usuários cooperem, e uma vantagem ética, respeitando a liberdade dos
usuários.</p>

<p>Mas era natural aplicar os padrões conhecidos de boas práticas ao nosso
trabalho — por exemplo, alocar dinamicamente estruturas de dados para evitar
limites de tamanho fixos arbitrários, e lidar com todos os possíveis códigos
de 8 bits onde quer que fizesse sentido.</p>

<p>Além disso, rejeitamos o foco do Unix em memória reduzida, ao decidir
suportar máquinas de 16 bits (era claro que as máquinas de 32 bits seriam a
norma no momento em que o sistema GNU fosse terminado), e não fazer nenhum
esforço para reduzir o uso de memória a menos que excedesse um megabyte. Nos
programas para os quais lidar com arquivos muito grandes não era crucial,
nós encorajamos os programadores a ler um arquivo de entrada inteiro para a
memória, e então verificar o seu conteúdo sem ter que se preocupar com E/S
(do inglês “Input/Output”, isto é, Entrada/Saída).</p>

<p>Estas decisões permitiram que muitos programas GNU superassem os seus
equivalentes Unix em confiabilidade e velocidade.</p>

<h3>Computadores doados</h3>

<p>Conforme a reputação do projeto GNU crescia, as pessoas começaram a se
oferecer para doar máquinas rodando Unix para o projeto. Estas ofertas eram
muito úteis, porque a maneira mais fácil de desenvolver componentes do GNU
era fazê-lo em um sistema Unix, e substituir os componentes desse sistema,
um a um. Mas eles levantaram uma questão ética: se para nós era correto ter
uma cópia do Unix.</p>

<p>Unix era (e ainda é) software privativo, e a filosofia do Projeto GNU dizia
que não devíamos usar software privativo. Mas, aplicando o mesmo raciocínio
que leva à conclusão de que a violência em legítima defesa é justificada,
cheguei à conclusão de que era legítimo usar um pacote privativo quando isso
fosse crucial para o desenvolvimento de um substituto livre que ajudaria os
outros a parar de usar o pacote privativo.</p>

<p>Mas, mesmo que isso fosse um mal justificável, ainda era um mal. Hoje não
temos mais nenhuma cópia do Unix, porque as substituímos por sistemas
operacionais livres. Se não pudéssemos substituir o sistema operacional de
uma máquina com um livre, substituíamos a máquina em vez disso.</p>

<h3>A lista de tarefas GNU</h3>

<p>Conforme o Projeto GNU prosseguia, e um número crescente de componentes do
sistema foram encontrados ou desenvolvidos, eventualmente, tornou-se útil
fazer uma lista das lacunas remanescentes. Costumávamos recrutar
desenvolvedores para escrever as peças que faltavam. Esta lista se tornou
conhecida como a lista de tarefas GNU. Além de componentes Unix que
faltavam, listávamos vários outros projetos úteis de softwares e
documentação que nós achávamos necessários a um sistema verdadeiramente
completo.</p>

<p>Hoje (1), dificilmente um componente do Unix está na lista de tarefas GNU —
esse trabalho já foi feito, com exceção de uns poucos não essenciais. Mas a
lista está cheia de projetos que alguns poderiam chamar de
“aplicações”. Qualquer programa que agrada mais do que uma classe pequena de
usuários é uma coisa útil para se adicionar a um sistema operacional.</p>

<p>Mesmo jogos estão incluídos na lista de tarefas — e estiveram desde o
início. Unix incluía jogos, então naturalmente o GNU também deveria. Mas a
compatibilidade não importa para os jogos, por isso não seguimos a lista de
jogos que o Unix tinha. Em vez disso, listamos um espectro de diferentes
tipos de jogos que os usuários poderiam gostar.</p>

<p>(1) Isso foi escrito em 1998. Em 2009 já não mantemos uma longa lista de
tarefas. A comunidade desenvolve software livre tão rápido que nem sequer
podemos acompanhá-los. Em vez disso, nós temos uma lista de projetos de alta
prioridade, uma lista muito mais curta de projetos nos quais queremos
encorajar as pessoas a trabalhar.</p>

<h3>A GNU GPL para Bibliotecas (GNU Library GPL)</h3>

<p>A biblioteca C GNU usa um tipo especial de copyleft chamado Licença Pública
Geral GNU para Bibliotecas(1) (GNU Library General Public License), que dá
permissão para ligar software privativo à biblioteca. Por que fazer essa
exceção?</p>

<p>Não é uma questão de princípio; não há um princípio que diz que os produtos
de software privativo têm o direito de incluir o nosso código. (Por que
contribuir com um projeto que se recusa a compartilhar conosco?) Usando a
LGPL para a biblioteca C, ou para qualquer biblioteca, é uma questão de
estratégia.</p>

<p>A biblioteca C faz um trabalho genérico; cada sistema privativo ou
compilador vem com uma biblioteca C. Portanto, tornar nossa biblioteca C
disponível apenas para o software livre não teria sido qualquer vantagem —
isso só teria desencorajado o uso da nossa biblioteca.</p>

<p>Um sistema é uma exceção a isto: no sistema GNU (e isso inclui o GNU/Linux),
a biblioteca C GNU é a única biblioteca C. Então, os termos de distribuição
da biblioteca C GNU determinam se é possível compilar um programa privativo
para o sistema GNU. Não há nenhuma razão ética para permitir aplicações
privativas no sistema GNU, mas estrategicamente, parece que não as permitir
acabaria mais por desencorajar o uso do sistema GNU do que encorajar o
desenvolvimento de aplicações livres. É por isso que usar a GPL para
Bibliotecas é uma boa estratégia para a biblioteca C.</p>

<p>Para outras bibliotecas, a decisão estratégica precisa ser considerada caso
a caso. Quando uma biblioteca faz um trabalho especial que pode ajudar a
escrever certos tipos de programas, liberá-la sob a GPL, limitando-a apenas
a programas livres, é uma forma de ajudar outros desenvolvedores de software
livre, dando-lhes uma vantagem sobre o software privativo.</p>

<p>Considere a GNU Readline, uma biblioteca que foi desenvolvida para fornecer
a edição de linha de comando para o BASH. Readline é distribuída sob a GNU
GPL comum, não a GPL para Bibliotecas. Isso provavelmente reduz o quanto a
Readline é usada, mas isso não nos representa perda. Por outro lado, pelo
menos uma aplicação útil foi feita software livre especificamente para que
ela pudesse usar a Readline, e isso é um ganho real para a comunidade.</p>

<p>Desenvolvedores de software privativo têm as vantagens que o dinheiro
fornece; desenvolvedores de software livre precisam criar vantagens uns para
os outros. Eu espero que algum dia venhamos a ter uma grande coleção de
bibliotecas cobertas pela GPL que não têm equivalente disponível para o
software privativo, fornecendo módulos úteis para servir como blocos de
construção em novos pacotes de software livre, e agregando a uma grande
vantagem para o desenvolvimento subsequente do software livre.</p>

<p>(1) Esta licença é agora chamada de Licença Pública Geral GNU Reduzida (GNU
Lesser General Public License), para evitar passar a ideia de que todas as
bibliotecas deveriam usá-la. Consulte <a
href="/philosophy/why-not-lgpl.html">Por que você não deve usar a GPL
Reduzida para a sua próxima biblioteca</a> para mais informações.</p>

<h3>Colocar o dedo na ferida?</h3>
<p>
Eric Raymond diz que “Todo bom trabalho de software começa ao colocar-se o
dedo na ferida de um programador”. Talvez isso aconteça às vezes, mas muitas
peças essenciais de software GNU foram desenvolvidas a fim de se ter um
sistema operacional livre completo. Elas vêm de uma visão e um plano, não
por impulso.</p>
<p>
Por exemplo, desenvolvemos a biblioteca C GNU, porque um sistema semelhante
ao Unix precisa de uma biblioteca C, BASH porque um sistema do tipo Unix
precisa de um interpretador de comandos, e o GNU tar porque um sistema
parecido com Unix precisa de um programa tar. O mesmo é verdade para os meus
próprios programas — o compilador C GNU, GNU Emacs, GDB e GNU Make.</p>
<p>
Alguns programas GNU foram desenvolvidos para lidar com ameaças específicas
à nossa liberdade. Assim, desenvolvemos o gzip para substituir o programa
Compress, que havia sido perdido pela comunidade por causa das patentes
sobre o <abbr title="Lempel-Ziv-Welch">LZW</abbr>. Encontramos pessoas para
desenvolver a LessTif, e mais recentemente começamos o <abbr title="GNU
Network Object Model Environment">GNOME</abbr> e o Harmony, para resolver os
problemas causados por certas bibliotecas privativas (veja abaixo). Estamos
desenvolvendo o GNU Privacy Guard para substituir um software não livre de
criptografia popular, porque os usuários não deveriam ter que escolher entre
privacidade e liberdade.</p>
<p>
Claro, as pessoas que escrevem estes programas se interessaram pelo
trabalho, e muitos recursos foram adicionados a eles por várias pessoas por
causa de suas próprias necessidades e interesses. Mas não é por isso que
esses programas existem.</p>

<h3>Desenvolvimentos inesperados</h3>
<p>
No início do Projeto GNU, eu imaginei que iríamos desenvolver todo o sistema
GNU e então liberá-lo como um todo. Não foi assim que aconteceu.</p>
<p>
Dado que cada componente do sistema GNU foi implementado em um sistema Unix,
cada componente podia ser executado em sistemas Unix muito antes de existir
um sistema GNU completo. Alguns desses programas se tornaram populares, e os
usuários começaram a estendê-los e portá-los — para as várias versões
incompatíveis do Unix, e às vezes para outros sistemas também.</p>
<p>
O processo fez esses programas muito mais poderoso, e atraiu tanto fundos
quanto contribuidores para o projeto GNU. Mas provavelmente também atrasou a
conclusão de um sistema funcional mínimo por vários anos, como o tempo dos
desenvolvedores GNU foi usado para manter essas portagens e adicionar
recursos aos componentes existentes, ao invés de continuar escrevendo os
componentes que faltavam, um após o outro.</p>

<h3>O GNU Hurd</h3>
<p>
Em 1990, o sistema GNU estava quase completo; o único grande componente que
faltava era o núcleo. Havíamos decidido implementar nosso núcleo como uma
coleção de processos servidores rodando em cima do Mach. Mach é um
micronúcleo (microkernel) desenvolvido na Carnegie Mellon University e
depois na Universidade de Utah; o GNU Hurd é um conjunto de servidores (ou
seja, um rebanho de GNUs), que executam sobre o Mach, e proveem os vários
serviços atribuídos ao núcleo do Unix. O início do desenvolvimento foi
adiado enquanto esperávamos pelo lançamento do Mach como software livre,
como havia sido prometido.</p>
<p>
Uma das razões para escolher este design era evitar o que parecia ser a
parte mais difícil do trabalho: depurar o núcleo sem contar com um depurador
de código fonte para fazê-lo. Esta parte do trabalho já havia sido feita, no
Mach, e esperávamos para depurar os servidores do Hurd como programas de
usuário, com o GDB. Mas levou muito tempo para que isso seja possível, e os
servidores de múltiplas linhas de execução que enviam mensagens uns aos
outros acabaram por ser muito difíceis de se depurar. Fazer o Hurd funcionar
de maneira sólida demorou muitos anos.</p>

<h3>Alix</h3>
<p>
O kernel do GNU não seria originalmente chamado de Hurd. Seu nome original
era Alix — o nome da mulher que era minha namorada na época. Ela, uma
administradora de sistemas Unix, nos fez notar como seu nome seguia o padrão
de nomenclatura comum para as versões do sistema Unix; como uma brincadeira,
ela disse aos seus amigos, “Alguém deveria dar meu nome a um núcleo”. Eu não
disse nada, mas decidi surpreendê-la com um núcleo chamado Alix.</p>
<p>
Mas isso não ficou assim. Michael (agora Thomas) Bushnell, o principal
desenvolvedor do kernel, preferiu o nome de Hurd, e redefiniu Alix para se
referir a uma determinada parte do kernel — a parte que intercepta as
chamadas de sistema e as trata através do envio de mensagens para os
servidores do Hurd.</p>
<p>
Mais tarde, Alix e eu terminamos, e ela mudou seu nome; de forma
independente, o design do Hurd foi alterado para que a biblioteca C enviasse
mensagens diretamente aos servidores, e isso fez com que o componente Alix
desaparecesse do design.</p>
<p>
Mas antes destas coisas acontecerem, um amigo dela se deparou com o nome
Alix no código-fonte do Hurd, e mencionou a ela. Então ela teve a chance de
encontrar um kernel com o seu nome.</p>

<h3>Linux e GNU/Linux</h3>
<p>
O GNU Hurd não está pronto para o uso em produção, e não sabemos se um dia
estará. O design baseado em capacidade (capability-based design) tem
problemas que são resultados diretos da flexibilidade do design, e não está
claro se soluções existem.</p>

<p>
Felizmente, outro núcleo está disponível. Em 1991, Linus Torvalds
desenvolveu um núcleo compatível com o Unix e o chamou Linux. Este era
privativo no início, mas em 1992, ele o tornou software livre; a combinação
do Linux com o não-exatamente-completo sistema GNU resultou em um sistema
operacional livre completo. (Combinar ambos era um trabalho substancial em
si mesmo, é claro). É graças ao Linux que podemos de fato executar uma
versão do sistema GNU hoje em dia.</p>
<p>
Nós chamamos esta versão do sistema <a
href="/gnu/linux-and-gnu.html">GNU/Linux</a>, para expressar sua composição
como a combinação do sistema GNU com o núcleo Linux. Por favor, não caia na
prática de chamar o sistema como um todo de “Linux”, já que isso significa a
atribuição do nosso trabalho à outra pessoa. Por favor, <a
href="/gnu/gnu-linux-faq.html">nos dê menção igual</a>.</p>

<h3>Desafios para o futuro</h3>
<p>
Nós provamos nossa capacidade de desenvolver um amplo espectro de software
livre. Isso não significa que somos invencíveis e que não podemos ser
detidos. Vários desafios fazem com que o futuro do software livre seja
incerto; enfrentá-los vai exigir esforço firme e muita resistência, às vezes
durante anos. Exigirá o tipo de determinação que as pessoas mostram quando
elas valorizam a sua liberdade e não deixam ninguém levá-la embora.</p>
<p>
As quatro seções seguintes abordam esses desafios.</p>

<h3>Hardware secreto</h3>
<p>
Os fabricantes de hardware tendem cada vez mais a manter as especificações
de hardware secretas. Isso torna difícil o desenvolvimento de controladores
livres para que o Linux e o XFree86 possam suportar novo hardware. Temos
sistemas livres completos hoje, mas não vamos tê-los amanhã, se não pudermos
dar suporte aos computadores do futuro.</p>
<p>
Há duas maneiras de lidar com este problema. Os programadores podem fazer
engenharia reversa para descobrir como suportar o hardware. O resto de nós
pode escolher o hardware que é suportado pelo software livre; conforme o
nosso número aumenta, o sigilo das especificações se tornará uma política de
auto-destrutiva.</p>
<p>
A engenharia reversa é um grande trabalho; teremos programadores com
determinação suficiente para realizá-lo? Sim — se nós construirmos um forte
sentimento de que o software livre é uma questão de princípios, e os
controladores não livres são intoleráveis. E irá um grande número de pessoas
gastar dinheiro extra, ou até mesmo um pouco de tempo extra, para que possam
usar controladores livres? Sim, se a determinação de ter liberdade for
generalizada.</p>
<p>
(nota de 2008: este problema estende-se também à BIOS. Há uma BIOS livre, <a
href="http://www.libreboot.org/">LibreBoot</a> (uma distribuição do
coreboot); o problema está em conseguir especificações para as máquinas de
modo que LibreBoot possa suportá-las sem “blobs” não livres).</p>

<h3>Bibliotecas não livres</h3>
<p>
Uma biblioteca não livre que funciona em sistemas operacionais livres age
como uma armadilha para os desenvolvedores do software livre. Recursos
atraentes da biblioteca são a isca; se você usar a biblioteca, você cai na
armadilha, porque o programa não pode ser parte útil de um sistema
operacional livre. (Estritamente falando, poderíamos incluir o seu programa,
mas ele não <em>executaria</em> com a biblioteca em falta). Ainda pior, se
um programa que usa a biblioteca privativa se torna popular, ele pode atrair
outros programadores desavisados para a armadilha.</p>
<p>
A primeira instância desse problema era o kit de ferramentas Motif, nos anos
80. Embora ainda não houvesse sistemas operacionais livres, ficava claro o
problema que a Motif causaria para eles mais tarde. O Projeto GNU respondeu
de duas formas: pedindo aos projetos de software livre individuais para dar
suporte aos widgets do kit de ferramentas livre do X tão bem quanto a Motif,
e pedindo a alguém para escrever um substituto livre para a Motif. O
trabalho levou muitos anos; LessTif, desenvolvida pelos Hungry Programmers
(Programadores Famintos), tornou-se poderosa o suficiente para dar suporte a
maioria das aplicações Motif apenas em 1997.</p>
<p>
Entre 1996 e 1998, uma outra biblioteca não livre de kit de ferramentas para
<abbr title="Graphical User Interface">GUI</abbr>, chamada Qt, foi usada em
uma coleção substancial de software livre, o <abbr title="K Desktop
Environment">KDE</abbr>.</p>
<p>
Sistemas livres GNU/Linux foram incapazes de usar o KDE, porque não podíamos
usar a biblioteca. No entanto, alguns distribuidores comerciais do sistemas
GNU/Linux que não eram rigorosos a respeito do software livre adicionaram o
KDE aos seus sistemas − produzindo um sistema com mais recursos, mas menos
liberdade. O grupo KDE estava encorajando ativamente mais programadores a
usar Qt, e milhões de novos “usuários Linux” nunca tinham sido expostos à
ideia de que havia algum problema nisso. A situação era desesperadora.</p>
<p>
A comunidade do software livre respondeu ao problema de duas formas: GNOME e
Harmony (Harmonia).</p>
<p>
GNOME, o Ambiente de Modelos de Objetos de Rede GNU (GNU Network Object
Model Environment), é o projeto de área de trabalho do GNU. Iniciado em 1997
por Miguel de Icaza, e desenvolvido com o apoio da Red Hat Software, o GNOME
busca fornecer instalações de área de trabalho semelhantes, mas usando
exclusivamente software livre. Ele tem vantagens técnicas também, tais como
suportar uma variedade de linguagens, não apenas C++. Mas o seu principal
objectivo era a liberdade: não exigir a utilização de qualquer software não
livre.</p>
<p>
Harmony é uma biblioteca substituta compatível, projetada para tornar
possível executar software KDE sem usar Qt.</p>
<p>
Em novembro de 1998, os desenvolvedores da Qt anunciaram uma mudança de
licença que, quando realizada, deverá fazer da Qt software livre. Não há
maneira de ter certeza, mas eu acho que isso foi em parte devido à resposta
firme da comunidade ao problema que a Qt causou quando era não livre. (A
nova licença é inconveniente e injusta, por isso, continua a ser desejável
evitar o uso da Qt).</p>
<p>
[Nota subsequente: em setembro de 2000, Qt foi relançada sob a GNU GPL, o
que essencialmente resolveu este problema].</p>
<p>
Como vamos responder à próxima tentadora biblioteca não livre? Irá toda a
comunidade entender a necessidade de ficar longe da armadilha? Ou será que
muitos de nós desistiremos da liberdade por conveniência, e produziremos um
problema maior? Nosso futuro depende de nossa filosofia.</p>

<h3>As patentes de software</h3>
<p>
A pior ameaça que enfrentamos vem de patentes de software, que podem colocar
algoritmos e funcionalidades fora do alcance do software livre por até 20
anos. As patentes do algoritmo de compressão LZW foram aplicadas em 1983, e
nós ainda não podemos liberar software livre que produza adequadamente <abbr
title="Graphics Interchange Format">GIF</abbr>s comprimidos. [Em 2009 elas
expiraram]. Em 1998, um programa livre para produzir áudio comprimido em
<abbr title="MPEG-1 Audio Layer 3">MP3</abbr> foi impedido de ser
distribuído sob a ameaça de um processo de patente. [Desde 2017, essas
patentes expiraram. Veja quanto tempo tivemos que esperar.]
</p>
<p>
Existem maneiras de lidar com as patentes: podemos procurar evidências de
que uma patente é inválida, e nós podemos procurar formas alternativas para
realizar uma tarefa. Mas esses métodos funcionam apenas algumas vezes;
quando ambos falham, uma patente pode forçar o software livre a deixar a
desejar com respeito a uma funcionalidade que os usuários querem. Após uma
longa espera, as patentes expiram, mas o que vamos fazer até então?</p>
<p>
Aqueles de nós que valorizam o software livre por amor à liberdade vão ficar
com software livre de qualquer maneira. Vamos conseguir realizar as tarefas
sem as funcionalidades patenteadas. Mas aqueles que valorizam o software
livre porque esperam que ele seja tecnicamente superior tendem a chamá-lo de
fracasso quando uma patente o detém. Assim, embora seja útil falar sobre a
eficácia prática do modelo de desenvolvimento “bazar”, bem como a
confiabilidade e poder de alguns softwares livres, não devemos parar por
aí. Temos que falar sobre liberdade e princípio.</p>

<h3>Documentação livre</h3>
<p>
A maior deficiência nos sistemas operacionais livres não está no software —
é a falta de bons manuais livres que possamos incluir em nossos sistemas. A
documentação é uma parte essencial de qualquer pacote de software; quando um
importante pacote de software livre não vem com um bom manual livre, essa é
uma grande lacuna. Temos muitas dessas lacunas hoje.</p>
<p>
Documentação livre, como o software livre, é uma questão de liberdade, não
de preço. O critério para um manual livre é praticamente o mesmo que para o
software livre: é uma questão de dar a todos os usuários certas
liberdades. Redistribuição (incluindo a venda comercial) deve ser permitida,
on-line e em papel, de modo que o manual possa acompanhar cada cópia do
programa.</p>
<p>
Permissão para modificação também é crucial. Como regra geral, eu não
acredito que é essencial que as pessoas tenham permissão para modificar
todos os tipos de artigos e livros. Por exemplo, eu não acho que você ou eu
somos obrigados a dar permissão para modificação de artigos como este, que
descrevem as nossas ações e nossos pontos de vista.</p>
<p>
Mas há uma razão específica porque a liberdade de modificações é crucial
para a documentação do software livre. Quando as pessoas exercerem o seu
direito de modificar o software, e adicionar ou alterar as suas
funcionalidades, se eles forem sensatos irão mudar o manual também — para
que possam fornecer documentação precisa e usável com o programa
modificado. Um manual não livre, que não permite que os programadores sejam
sensatos e terminem o trabalho, não satisfaz as necessidades da nossa
comunidade.</p>
<p>
Alguns tipos de limites sobre como as modificações são feitas não
representam qualquer problema. Por exemplo, os requisitos para preservar
aviso de direitos autorais do autor original, os termos de distribuição, ou
a lista de autores, são aceitáveis. Também não é problema exigir que versões
modificadas incluam um aviso identificando-as como tal, ou mesmo ter seções
inteiras que não podem ser excluídas ou alteradas, desde que essas seções
lidem com tópicos não técnicos. Esses tipos de restrições não são um
problema, porque elas não impedem o programador consciente de adaptar o
manual para corresponder ao programa modificado. Em outras palavras, elas
não impedem a comunidade de software livre de fazer pleno uso do manual.</p>
<p>
No entanto, deve ser possível modificar todo o conteúdo <em>técnico</em> do
manual, e depois distribuir o resultado em todos os meios usuais, através de
todos os canais usuais; caso contrário, as restrições obstruem a comunidade,
o manual não é livre, e nós precisamos de outro manual.</p>
<p>
Terão os desenvolvedores de software livre a consciência e determinação para
produzir um espectro completo de manuais livres? Mais uma vez, o nosso
futuro depende da filosofia.</p>

<h3>Devemos falar sobre liberdade</h3>
<p>
As estimativas atuais são de que existem dez milhões de usuários do sistemas
GNU/Linux, como Debian GNU/Linux e Red Hat “Linux”. O software livre tem
desenvolvido tamanhas vantagens práticas que os usuários estão migrando para
ele por razões puramente práticas.</p>
<p>
As boas consequências disto são evidentes: mais interesse no desenvolvimento
do software livre, mais clientes para as empresas do software livre, e mais
capacidade de incentivar as empresas a desenvolver software livre comercial,
em vez de produtos de software privativo.</p>
<p>
Mas o interesse no software está crescendo mais rápido do que a consciência
na filosofia sobre a qual ele se baseia, e isso leva a problemas. A nossa
capacidade para enfrentar os desafios e ameaças descritas acima depende da
vontade de defender firmemente a liberdade. Para nos certificarmos de que
nossa comunidade tem essa vontade, precisamos difundir a ideia para os novos
usuários conforme eles chegam à nossa comunidade.</p>
<p>
Mas não estamos conseguindo fazê-lo: os esforços para atrair novos usuários
para nossa comunidade estão superando de longe os esforços para ensiná-los a
educação cívica da nossa comunidade. Precisamos fazer as duas coisas, e
precisamos manter os dois esforços em equilíbrio.</p>

<h3>“Código Aberto” (“Open Source”)</h3>
<p>
Ensinar novos usuários sobre a liberdade tornou-se mais difícil em 1998,
quando uma parte da comunidade decidiu parar de usar o termo “software
livre” (free software) e, em vez disso, começou a dizer “código aberto”
(open source).</p>
<p>
Alguns que favoreceram este termo visaram evitar a confusão de “livre” com
“grátis” — um objetivo válido. Outros, no entanto, com o objetivo de anular
os princípios que haviam motivado o movimento do software livre e o projeto
GNU, atraíram executivos e usuários de negócios, muitos dos quais carregam
uma ideologia que coloca o lucro acima da liberdade, acima da comunidade,
acima dos princípios. Assim, a retórica do “código aberto” incide sobre o
potencial de fazer software poderoso e de alta qualidade, mas evita as
ideias de liberdade, comunidade e princípios.</p>
<p>
As revistas do “Linux” são um exemplo claro disso — eles estão cheias de
anúncios de software privativo, que funciona com GNU/Linux. Quando a próxima
Motif ou Qt aparecer, irão essas revistas alertar os programadores, ou será
que vão exibir anúncios dela?</p>
<p>
Aparte dos demais fatores o apoio das empresas pode contribuir para a
comunidade de muitas maneiras e é útil. Mas ganhar o apoio deles, falando
menos ainda sobre liberdade e princípios pode ser desastroso; isso faz o
desequilíbrio entre divulgação e educação cívica ainda pior.</p>
<p>
“Software livre” e “código aberto” descrevem a mesma categoria de software,
mais ou menos, mas dizem coisas diferentes sobre o software, e sobre
valores. O Projeto GNU continua a usar o termo “software livre”, para
expressar a ideia de que liberdade, não apenas tecnologia, é importante.</p>

<h3>Tente!</h3>
<p>
O aforismo de Yoda (“‘Tentar’ não há”) soa bem, mas ele não funciona para
mim. Eu tenho feito a maior parte do meu trabalho com a ansiedade de não
saber se eu teria sucesso, e sem a certeza de que ter sucessor seria
suficiente para atingir a meta. Mas eu tentei de qualquer maneira, porque
não havia ninguém além de mim entre o inimigo e minha cidade. Para minha
surpresa, algumas vezes eu tive sucesso.</p>
<p>
Algumas vezes eu falhei; e algumas das minhas cidades desmoronaram. Então eu
encontrava outra cidade ameaçada, e me preparava para outra batalha. Com o
tempo, aprendi a olhar para as ameaças e colocar-me entre elas e minha
cidade, convidando outros hackers para vir e se juntar a mim.</p>
<p>
Hoje em dia, muitas vezes eu não sou o único. É um alívio e uma alegria
quando vejo um regimento de hackers cavando para manter as trincheiras, e eu
percebo que esta cidade pode sobreviver — por enquanto. Mas os perigos são
maiores a cada ano, e agora a Microsoft está explicitamente alvejando nossa
comunidade. Nós não podemos tomar o futuro da liberdade por garantido. Não
tome por garantido! Se você quiser manter sua liberdade, você deve estar
preparado para defendê-la.</p>

<div class="translators-notes">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.-->
<h3>Notas do tradutor</h3>
<ol>
<li id="TransNote1">Em inglês a palavra “free” é ambígua e pode significar
tanto “livre” quanto “gratuito”.</li>
</ol></div>
</div>

<!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.pt-br.html" -->
<div id="footer">
<div class="unprintable">

<p>Envie perguntas em geral sobre a FSF e o GNU para <a
href="mailto:gnu@gnu.org">&lt;gnu@gnu.org&gt;</a>. Também existem <a
href="/contact/">outros meios de contatar</a> a FSF. Links quebrados e
outras correções ou sugestões podem ser enviadas para <a
href="mailto:webmasters@gnu.org">&lt;webmasters@gnu.org&gt;</a>.</p>

<p>
<!-- TRANSLATORS: Ignore the original text in this paragraph,
        replace it with the translation of these two:

        We work hard and do our best to provide accurate, good quality
        translations.  However, we are not exempt from imperfection.
        Please send your comments and general suggestions in this regard
        to <a href="mailto:web-translators@gnu.org">

        &lt;web-translators@gnu.org&gt;</a>.</p>

        <p>For information on coordinating and submitting translations of
        our web pages, see <a
        href="/server/standards/README.translations.html">Translations
        README</a>. -->
A equipe de traduções para o português brasileiro se esforça para oferecer
traduções precisas e de boa qualidade, mas não estamos isentos de erros. Por
favor, envie seus comentários e sugestões em geral sobre as traduções para
<a
href="mailto:web-translators@gnu.org">&lt;web-translators@gnu.org&gt;</a>.
</p><p>Consulte o <a href="/server/standards/README.translations.html">Guia
para as traduções</a> para mais informações sobre a coordenação e o envio de
traduções das páginas deste site.</p>
</div>

<!-- Regarding copyright, in general, standalone pages (as opposed to
     files generated as part of manuals) on the GNU web server should
     be under CC BY-ND 4.0.  Please do NOT change or remove this
     without talking with the webmasters or licensing team first.
     Please make sure the copyright date is consistent with the
     document.  For web pages, it is ok to list just the latest year the
     document was modified, or published.
     
     If you wish to list earlier years, that is ok too.
     Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
     years, as long as each year in the range is in fact a copyrightable
     year, i.e., a year in which the document was published (including
     being publicly visible on the web or in a revision control system).
     
     There is more detail about copyright years in the GNU Maintainers
     Information document, www.gnu.org/prep/maintain. -->
<p>Copyright &copy; 1998, 2001, 2002, 2005, 2006, 2007, 2008, 2010, 2014, 2015,
2017, 2018, 2020 Richard Stallman</p>

<p>Esta página está licenciada sob uma licença <a rel="license"
href="http://creativecommons.org/licenses/by-nd/4.0/deed.pt_BR">Creative
Commons Atribuição-SemDerivações 4.0 Internacional</a>.</p>

<!--#include virtual="/server/bottom-notes.pt-br.html" -->
<div class="translators-credits">

<!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.-->
Tradução por:
<a href="http://oitofelix.freeshell.org/">Bruno Félix Rezende Ribeiro</a> <a
href="mailto:oitofelix@gnu.org">&lt;oitofelix@gnu.org&gt;</a>, 2015;
Rafael Fontenelle <a
href="mailto:rafaelff@gnome.org">&lt;rafaelff@gnome.org&gt;</a>, 2020</div>

<p class="unprintable"><!-- timestamp start -->
Última atualização:

$Date: 2020/07/25 12:31:02 $

<!-- timestamp end -->
</p>
</div>
</div>
<!-- for class="inner", starts in the banner include -->
</body>
</html>