BRASIL   SoftwareLivre.org  BR-Linux  ·  VivaoLinux  ·  LinuxSecurity  ·  Dicas-L  ·  NoticiasLinux  ·  UnderLinux  ·  BestLinux [mais]
   
 
 
Notícias - 1968
 
Imprimir esta notícia

Livre mas restrito: a Armadilha Java
Editoria: Geral
12/Apr/2004 - 13:58
Se seu programa é software livre, ele é basicamente ético - mas há uma armadilha com a qual você deve tomar cuidado. Seu programa, apesar de livre ele próprio, pode ser restringido por software não-livre de que ele depende. Já que o problema é mais proeminente hoje em programas Java, nós chamamos isso de Armadilha Java.

Autor: Richard M. Stallman


Um programa é software livre se seus usuários tem certas liberdades cruciais. Grosseiramente falando, elas são: a liberdade de executá-lo, a liberdade de estudá-lo e modificar o código-fonte, a liberdade de redistribuir o código-fonte e os binários, e a liberdade de publicar versões melhoradas. (Veja free-sw.html.) Se qualquer dado programa é software livre depende somente do significado da sua licença.

Se o programa pode ser utilizado no Mundo Livre, utilizado por pessoas que querem viver em liberdade, esta é uma questão mais complicada. Isto não é determinado pela licença própria do programa, porque nenhum programa trabalha isoladamente. Cada programa depende de outros programas. Por exemplo, um prgrama precisa ser compilado ou interpretado, logo depende de um compilador ou interpretador. Se compilado para byte code, ele depende de um interpretador de byte code. Além disso, ele depende de uma biblioteca para ser executado, e pode também invocar outros programas separados que são executados em outros processos. Todos esses programas são dependências. Dependências podem ser imprescindíveis para o programa ser executado, ou elas podem ser necessárias somente para algumas características. De qualquer maneira, todo ou parte do programa não pode operar sem suas dependências.

Se algumas das dependências do programa são não-livres, isto significa que todo ou parte do programa não está apto a ser executado em um sistema inteiramente livre - é inútil no Mundo Livre. Certamente, nós poderiamos redistribuir o programa e ter cópias em nossas máquinas, mas isso não importa se não pudermos executá-lo. Aquele programa é software livre, mas ele está efetivamente restrito por usas dependências não-livres.

Este problema pode ocorrer em qualquer tipo de software, em qualquer linguagem. Por exemplo, um programa livre que é somente executável no Microsoft Windows é claramente inútil no Mundo Livre. Mas softwares executáveis no GNU/Linux podem também ser inúteis se dependem de outro software não-livre. No passado, Motif (antes de termos LessTif) e Qt (antes de seus desenvolvedores tê-lo feito software livre) eram as causas principais desse problema. A maioria das placas de vídeo 3D funcionam completamente apenas com drivers não-livres, que também causam esse problema. Mas a maior fonte desse problema hoje é o Java, porque pessoas que escrevem software livre freqüentemente acham Java sexy. Cegos por sua atração pela linguagem, eles desconsideram a questão das dependências e caem na Armadilha Java.

A implementação de Java da Sun é não-livre. A da Blackdown também é não-livre; é uma adaptação do código proprietário da Sun. As bibliotecas padrão Java são não-livres também. Nós temos implementações livres de Java, como o GNU Java Compiler e o GNU Classpath, mas eles não suportam todas as características ainda. Nós ainda estamos correndo atrás.

Se você desenvolve um programa em Java na plataforma Java da Sun, você está propenso a utilizar características únicas da Sun sem mesmo notar. No momento em que você descobrir isso, você pode tê-las usado por meses, e refazer o trabalho pode levar mais meses. Você pode dizer, "É muito trabalhos recomeçar." Então seu programa terá caído na Armadilha Java; será inútil no Mundo Livre.

A maneira confiável de evitar a Armadilha Java é ter somente uma implementação livre de Java no seu sistema. Então se você utilizar uma característica ou biblioteca de Java que o software livre ainda não suporta, você descobrirá diretamente, e você pode re-escrever aquele código imediatamente.

A Sun continua a desenvolver bibliotecas "padrão" Java adicionais, e quase a sua totalidade é não-livre; em muitos casos, mesmo a especificação da biblioteca é um segredo industrial, e a última licença da Sun para estas especificações proíbem o lançamento de qualquer coisa menor do que uma implementação completa da especificação. (Veja JSPA2.pdf e j2me_pb-1_0-fr-spec-license.html, por exemplo)

Felizmente, aquela licença da especificação permite lançar uma implementação como software livre; outros que receberam a biblioteca podem ser permitidos a modificá-la e não são obrigados a aderir à especificação. Mas a obrigação tem o efeito de proibir o uso de um modelo colaborativo para produzir a implementação livre. O uso deste modelo envolve publicar versões incompletas, o que não é permitido aos que leram a especificação.

Nos dias iniciais do Movimento do Software Livre, era impossível evitar depender de programas não-livres. Antes de termos o GNU C Compiler, todo programa em 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 shell tinha de ser interpretado por um shell não-livre. Era inevitável que nossos primeiros programas seriam inicialmente dificultados por aquelas dependências, mas nós aceitamos isso porque nosso plano incluía resgatá-los subseqüentemente. Nosso objetivo maior, um sistema operacional GNU auto-hospedado, incluia substitutos livres para cada uma daquelas dependências; se nós alcançássemos o objetivo, todos nossos programas seriam resgatados. Assim aconteceu: com o sistema GNU/Linux nós podemos agora executar esses programas em plataformas livres.

A situação é diferente hoje. Nós temos, agora, sistemas operacionais livres poderosos e muitas ferramentas de programação livres. Qualquer 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 para as pessoas cairem na armadilha hoje é porque elas não estão pensando nela. A solução mais fácil para o problema da Armadilha Java é ensinar as pessoas a não caírem nela.

Para manter seu código Java seguro da Armadilha Java, instale um ambiente de desenvolvimento Java livre, e o use. Mais genericamente, qualquer linguagem que você usar, mantenha seus olhos abertos e verifique o status livre dos programas de que seu código depende. A maneira mais fácil de verificar se um programa é livre é procurar por ele no Diretório de Software Livre. Se um programa não está no diretório, você pode verificar se sua(s) licença(s) consta(m) na lista de licenças de software livre.

Nós estamos tentando resgatar os programas Java "presos" na armadilha, então se você gosta da linguagem Java, nós o convidamos a participar do desenvolvimento do GNU Classpath. Provando seus programas com o compilador GJC e a GNU Classpath, e relatando quaisquer problemas que você encontrar em classes já implementadas, também é útil. Contudo, a conclusão da GNU Classpath vai tomar tempo; se mais bibliotecas não-livres continuarem a ser adicionadas, nós podemos nunca ter as últimas. Então, não ponha seu software livre na restrição. Quando você escrever uma aplicação hoje, escreva ela para ser executada em instalações livres desde o princípio.

Copyright 2004 Richard Stallman Verbatim copying and distribution of this entire article are permitted worldwide without royalty in any medium provided this notice is preserved.



Fonte: Propus
 

 

Pelo debate e transparencia no Projeto de Lei de CONTROLE da INTERNET

Leia também
 
 > Consegi ultrapassa 1700 inscrições
 
 > Base de usuários brasileiros do Firefox dobra em 2008, segundo Mozilla
 
 > Backup Incremental de Servidores e Estações Windows em Servidores Linux com o RSYNC
 
 > Oficinas reforçam compartilhamento do Consegi
 
 > Consegi 2008: um evento de governo para a sociedade
 
 > Bahia quer capacitação em software livre e criação do vale-cultura
 
 > Ceará: Seminário debate projeto de Software Livre
 
 > INPI: Software Livre em Risco
 
 > Lançado o primeiro livro sobre macros do OpenOffice, em português, da América Latina e 3º do Planeta
 
 > Compiz, conhecendo a fundo
 
 > Paraná: Expresso Livre tem novo aplicativo - Gestão de Contratos
 
 > O Ministério da Cultura vai lançar a comunidade Xemelê
 
 > Celepar desenvolve sistema de atendimento do SUS em Software Livre
 
 > Semana da Mobilidade INdT no CCSL IME/USP
 
 > Serpro promove I Fórum de Tecnologia em Software Livre de São Paulo
 
 > Mais Notícias
  Valid HTML Valid CSS