|
Essa discuss�o � muito antiga e, ao meu
ver, desperd�cio de esfor�o... -----Mensagem original----- Aeliton ����������� Vc esqueceu de indicar tb esse link aqui: ����������� “The Sun/Microsoft settlement” – James Gosling http://today.java.net/jag/page7.html “As for Richard Stallman's Free but
shackled: The Java trap , it's hard to know where to begin. He has his own
rather peculiar definition of "Free" that I think violates the First
Law of Thermodynamics (energy is conserved): developers put a huge amount of
energy into creating software and if they can't get that energy back in a way
that balances, then the system falls apart. I've been in this discussion
countless times and I'd like to avoid landing there again. GPL software is not
"free": it comes with a license that has a strong political agenda.
Like GPL software, the Java platform is "free" in many senses: you
don't have to pay anything for the runtime or developers kit and you can get
the sources for everything. Unlike GPLd software, the Java sources don't come
with a viral infection clause that requires you to apply the GPL to your own
code. But the sources for the JDK do come with a license that has a different
catch: redistribution requires compatibility testing. ... ...” Julio Cesar -----Mensagem original----- Gente, antes de manifestarem alguma poss�vel revolta
:-), por favor, entendam que estou repassando este e-mail (que poder�o
observar, n�o � de minha autoria) a t�tulo de informa��o. Mas minha posi��o � a favor do Software Livre, e um ambiente
completamente livre para java parece-me muito atraente, acho que vale a pena
contribuir com o projeto. a partir desta linha terminam meus apontamentos - a
mensagem original est� entre as demarca��es com sinais de =(igual) ================================================= Livre mas restrito: a Armadilha Java 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. =======================================
|
- [cejug] Java & Software Livre Aeliton
- RES: [cejug] Java & Software Livre Julio Cesar C Neto
- Felipe Ga�cho
