Livre, mas Algemado - A Armadilha do Java

por Richard Stallman

---

12 de abril de 2004

Se o seu programa é software livre, é basicamente ético – mas há uma armadilha para a qual você deve estar atento. Seu programa, embora seja livre, pode ser restrito por softwares não livres dos quais ele depende. Como o problema é mais proeminente hoje em dia nos programas Java, nós o chamamos de Armadilha do Java.

Um programa é software livre se seus usuários tiverem certas liberdades cruciais. A grosso modo, elas são: a liberdade de executar o programa, a liberdade de estudar e alterar o fonte, a liberdade de redistribuir o código-fonte e os binários e a liberdade de publicar versões aprimoradas. (Veja a Definição de Software Livre.) Se algum programa dado em forma de fonte é software livre depende unicamente do significado de sua licença.

Se o programa pode ser usado no mundo livre, usado por pessoas que querem viver em liberdade, é uma questão mais complexa. Isso não é determinado apenas pela própria licença do programa porque nenhum programa funciona isoladamente. Todo programa depende de outros programas. Por exemplo, um programa precisa ser compilado ou interpretado, então depende de um compilador ou interpretador. Se compilado em código de byte, isso depende de um interpretador de código de bytes. Além disso, ele precisa de bibliotecas para ser executado e também pode chamar outros programas separados que são executados em outros processos. Todos esses programas são dependências. Dependências podem ser necessárias para o programa ser executado, ou podem ser necessárias apenas para determinados recursos. De qualquer maneira, todo ou parte do programa não pode operar sem as dependências.

Se algumas das dependências de um programa forem não livres, isso significa que todo ou parte do programa não pode ser executado em um sistema totalmente livre – é inutilizável no mundo livre. Claro, poderíamos redistribuir o programa e ter cópias em nossas máquinas, mas isso não é muito bom se não for executado. Esse programa é software livre, mas está efetivamente preso por suas dependências não livres.

Esse problema pode ocorrer em qualquer tipo de software, em qualquer linguagem. Por exemplo, um programa livre que só funciona no Microsoft Windows é claramente inútil no mundo livre. Mas o software que funciona no GNU/Linux também pode ser inútil se depender de outro software não livre. No passado, o Motif (antes de ter o LessTif) e o Qt (antes de seus desenvolvedores o tornar software livre) eram as principais causas desse problema. A maioria das placas de vídeo 3D funciona totalmente apenas com drivers não livres, o que também causa esse problema. Mas a principal fonte desse problema hoje é o Java, porque as pessoas que escrevem software livre geralmente acham que o Java é sexy. Cegos por sua atração pela linguagem, eles ignoram a questão das dependências e caem na Armadilha do Java.

A implementação de Java da Sun não é livre. As bibliotecas padrão do Java também são não livres. Nós temos implementações livres de Java, como o GNU Compiler for Java (GCJ) e GNU Classpath, mas elas não possuem suporte a todos os recursos ainda. Nós ainda estamos trabalhando nisso.

Se você desenvolver um programa Java na plataforma Java da Sun, será necessário usar recursos exclusivos da Sun sem nem mesmo notar. No momento em que você descobrir isso, você pode tê-los usado por meses, e refazer o trabalho pode levar mais meses. Você pode dizer: “É muito trabalho para recomeçar”. Então, seu programa terá caído na Armadilha do Java; será inutilizável no mundo livre.

A maneira confiável de evitar a Armadilha do Java é ter apenas uma implementação livre do Java em seu sistema. Então, se você usar um recurso ou biblioteca Java que o software livre ainda não possui suporte, você descobrirá imediatamente e poderá reescrever esse código imediatamente.

A Sun continua a desenvolver bibliotecas “padrão” adicionais para o Java e quase todas elas são não livres; em muitos casos, até mesmo a especificação de uma biblioteca é um segredo comercial, e a última licença da Sun para essas especificações proíbe o lançamento de qualquer coisa menos que uma implementação completa da especificação. (Veja Java Specification Participation Agreement e J2ME™ Personal Basis Profile Specification para exemplos.)

Felizmente, essa licença de especificação permite lançar uma implementação como software livre; outros que recebem a biblioteca podem ter permissão para alterá-la e não são obrigados a aderir à especificação. Mas o requisito tem o efeito de proibir o uso de um modelo de desenvolvimento colaborativo para produzir a implementação livre. O uso desse modelo implicaria a publicação de versões incompletas, algo que aqueles que leram a especificação não têm permissão para fazer.

Nos primeiros dias do movimento do software livre, era impossível evitar depender de programas não livres. Antes de termos o compilador C GNU, todo programa C (livre ou não) dependia de um compilador C não livre. Antes de termos a biblioteca GNU C, todo programa dependia de uma biblioteca C não livre. Antes de termos o Linux, o primeiro kernel livre, todo programa dependia de um kernel não livre. Antes de termos o BASH, todo script de shell tinha que ser interpretado por um shell não livre. Era inevitável que nossos primeiros programas fossem inicialmente prejudicados por essas dependências, mas aceitamos isso porque nosso plano incluía salvá-los posteriormente. Nosso objetivo geral, um sistema operacional GNU de hospedagem própria, incluía substituições livre para todas essas dependências; Se alcançássemos a meta, todos os nossos programas seriam resgatados. Assim aconteceu: com o sistema GNU/Linux, agora podemos usar esses programas em plataformas livres.

A situação é diferente hoje. Agora temos sistemas operacionais poderosos e livres e muitas ferramentas de programação livres. Qualquer que seja o trabalho que você queira fazer, você pode fazê-lo em uma plataforma livre; não há necessidade de aceitar uma dependência não livre, mesmo que temporariamente. A principal razão pela qual as pessoas caem na armadilha hoje é porque elas não estão pensando nisso. A solução mais fácil para o problema é ensinar as pessoas a reconhecê-lo e não cair nele.

Para manter seu código Java protegido da Armadilha do Java, instale um ambiente de desenvolvimento Java livre e use-o. De forma mais genérica, seja qual for a linguagem que você usa, mantenha os olhos abertos e verifique o status de programas dos quais o seu código depende. A maneira mais fácil de verificar se um programa é livre é procurá-lo no Diretório de Software Livre. Se um programa não estiver no diretório, você poderá verificar sua(s) licença(s) com a lista de licenças de software livre.

Estamos tentando resgatar os programas Java que caíram nessa armadilha, portanto, se você gosta da linguagem Java, nós o convidamos a ajudar no desenvolvimento do GNU Classpath. Experimentar seus programas com o GCJ Compiler e o GNU Classpath, e relatar quaisquer problemas que você encontre em classes já implementadas, também é útil. No entanto, terminar o GNU Classpath levará tempo; se mais bibliotecas não livres continuarem sendo adicionadas, talvez nunca tenhamos todas as mais recentes. Então, por favor, não coloque seu software livre em grilhões. Quando você escrever um programa hoje, escreva-o para funcionar em instalações livres desde o início.

Veja também:

O curioso incidente da Sun no período noturno