Notícia publicada por brain em março 25, 2004 09:08 AM
| TrackBack
Após semanas de controvérsia, surge uma resposta direta, e vinda do CEO da Sun, Scott McNealy. Segundo ele, não teremos a abertura do código da linguagem Java, pois no seu entender isto não resolveria nenhuma situação que já não esteja sendo tratada de outra forma. Para os que torciam pela abertura da linguagem, resta o consolo de que a Sun nem sempre se caracteriza por realizar o que anuncia!
A Sun poderia ter o Java incrivelmente incrementado se abrisse o código, a decisão de não fazê-lo é desanimadora.Uma pena!
Na prática, isso não é nenhum problema. O "Processo Comunidade" já comanda o desenvolvimento do JAVA, e é composto por muita gente. Vale lembrar, que JAVA é uma arquitetura aberta, a máquina virtual da SUN é que não é um Software Livre.
JVM <> JAVA
Querem Java Open Source ?
Tem o gcj, tem o Kaffe, tem Blackdown e se alguém quiser criar uma JVM tem a total liberdade de pegar a documentação da Sun e implementar uma.
Ao menos poderiam tornar a licença um pouco menos restritiva a ponto de permitir o empacotamento nas distribuições Linux. Não se trata de uma restrição que tolhe apenas os "puristas" do Debian - na verdade, nenhuma grande distribuição inclui o java da sun. Isso é muito ruim para o mercado desktop (mesmo o corporativo).
Só pra deixar as coisas mais claras: a SUSE inclui o pacote em RPM do JAVA e do Flash em sua distro. Me parece que o Mandreke também, no CD 5. Então existem distros com o JAVA e o Flash embutidos SIM.
Conectiva já instala o JRE da Sun por padrão. Instalou uma estação de trabalho ou notebook. Tá lá.
Só para constar: o Slackware 9.1 já vem com o Java e na instalação padrão ele sobe e configura as váriaveis de ambiente.
Portanto, o comentário que diz que as grandes distibuições não colocam o java está errado, ou o Slackware não é uma grande distibuição.
Acho a decisão correta, vocês precisam se dar conta, que a principal concorrente do .net, é SUN com o JAVA,
se Ela abre seu código, está dando munição, ou melhor o ouro, pra m$ roubar, como ele sempre vem fazendo.
Se observarem as semelhanças existentes entre outros SO's, verá que se a m$ abrir o código do windows, veremos caracteristiscas roubadas de outros sistemas.
A sun está CERTA código Fechado SIM
a IBM foi vítima de m$ no passado com o OS/2, alguem se lembra?
Em primeiro lugar: a Sun não prometeu abrir o código, prometeu discutir com a IBM a possibilidade. Segundo: o JCP (Java Community Process) é aberto pra quem quiser participar. Graças a mão de ferro da Sun é que Java desde a primeira versão tem um padrão conciso.
Eu acho que dentro de alguns anos a virtual machine deverá perder a visibilidade atual passando a ser mais transparente. A tecnologia JAVA assim como o .NET é muito mais do que a VM.
A Sun deveria abrir o código fonte da VM e poderia
aprimorar os outros produtos como ambiente integrado de desenlvolvimento,frameworks,APIs,etc.
Enquanto isso quem quises desenlvolver esses outros "acessorios" ficaria livre para faze-lo como open-source.
Nas futuras versões do windows as APIs do SO serão portadas para .net e isso vai atrapalhar as coisas para o Java nesse SO.
Até la acredito que ja teremos uma implementação open-source do .net viável (mono,dotgnu,etc).
O Java vai acabar perdendo mercado tanto no Linux como no Windows.
O java é aberto. Toda a especificação da plataforma esta disponível para qualquer um. Acho que a galera do Open Source deveria parar de reclamar do Java e ver mais sobre o que ele pode trazer de beneficios pra todo mundo. Eu uso Java a muito tempo e nunca paguei um centavo pra ninguem, e nem uso software pirata, eu tenho algo a reclamar?? lógico que não. Tem muita coisa pra melhorar ainda no Java, mas ele vem evoluindo a cada versão e graças ao JCP não é só a SUN que decide para onde ele vai. Acho muito errado "desanimar" porque somente a JVM não é aberta, e deixar ele de lado é um excelente negocio, pra Microsoft claro, que não teria concorrencia. Particularmente eu acho que o MONO ou qualquer outra implementação .NET pra linux NUNCA vai ser 100% compativel com o .NET do windows e NUNCA vai ser tão bom quanto o JAVA. Talvez algum grupo queira desenvolver uma plataforma aberta melhor do que o Java e o .NET, resolvido o problema :)
Tudo bem que o fato da Sun não ter liberado a sua VM com uma licença livre não seja o fim do mundo, mas essa atitude também não traz nada de positivo para a Sun, só vai continuar o estado atual.
Liberar a VM com uma licença GPL não iria permitir na prática que a M$ se apoderasse dela. Aliás, a Sun moveu uma ação contra a M$ justamente porque ela colocava uma máquina virtual própria obsoleta no Windows. Portanto não é fechando o código que ela evita problemas.
O efeito de uma VM aberta da Sun seria mais psicológico, dando mais credibilidade ao Java e permitindo que desenvolvedores independentes pudessem melhorar a VM da Sun.
Eu sinceramente penso que a M$ vai mesmo é engolir o Java com o maldito .Net/C#, que teoricamente também é padronizado e documentado, mas na prática vai ser usado para prender mais os usuários a plataforma M$. A Sun para mim perdeu uma boa oportunidade de juntar a comunidade linux em torno de sua VM e assim popularizar mais o Java. Se a M$ vencer não vai adiantar de nada ficar com código fechado.
Pessoal, no javafree foi movida uma enquete para determinar a reação dos desenvoldedores java à abertura do código para LGPL.
As conclusões gerais são as seguintes:
1- A IBM, a principal arquiteta da "idéia" sempre almejou o controle da tecnologia Java. O código fonte já está disponível e mesmo que não estivesse, códigos podem ser reescritos. CONTROLE de uma marca consagrada como o Java é a palavra chave. Uma estratégia importante para esse objetivo é a abertura LGPL. Ela pode criar então sua implementação "superior" e usar sua poderosa máquina de marketing para enterrar o java como conhecemos. Como a IBM não tá nem aí pra compatibilidade e portabilidade, ganhará uma arma para seus concorrentes (principalmente iAS J2EE) obederecerem ao SEU padrão e sempre ficarem atrás. Alías, não conseguindo por hora seu intento, a IBM e a BEA atacam com a BPELJ (uma fusão entre BPEL e Java) num esforço de sair na frente e dar ao websphere um recurso o SunONE não tem.
2- A abertura do código não atende aos objetivos nem dos desenvolvedores nem dos usuários, além dar abertura para o aparecimento de versões incompatíveis (não haverá mais a necessidade de homologação de JVMs ou obrigatoriedade de seguir especificações. Certificações podem ser criadas, é verdade, mas quem será a autoridade certificadora? Teremos o certificado IBM, que é incompatível com o certificado da ORACLE, etc, etc, etc) e a remoção das "restrições" da plataforma Java (a Micro$oft já tentou fazer isso, lembram? Na época do Visual J++).
3- O que faz o java ser tão bom são justamente suas restrições, o fato da plataforma não ser uma "casa da mãe Joana" generalizada.
4- Não vejo essa coisa do .NET "engolir" o Java. Ao menos pelo que eu vejo, isso não está acontecendo. Há uma divisão de mercado, sim (com J2EE sempre à Km na ponta). E isso é normal. O retrato é: a Micro$oft tem um produto semelhante (plagiado) que conta apenas com sua aprovação (e de um monte de empresinhas que ela ainda não comprou por que não precisa), coeso pq só ela que mexe (ela quer que o projeto Mono se dane, e vai fazer esforço para que ele esteja SEMPRE incompatível e atrasado, não se iludam). O JCP tem o Java, um padrão com a aprovação das principais corporações no setor de TI mantido coeso por causa do JCP. Se liberar pra LGPL, o padrão deixa de ser coeso e perde pro .NET em confiabilidade (É sim, pq é assim que o mercado PENSA).
4- Em suma: quer escrever seu próprio framework gráfico, sua JVM, seu Aplication Server, fique a vontade. Basta seguir o raio da especificação, definida pelos esforços de toda a nossa comunidade.
Caso o contrário, chame do que quiser, não de Java.
isso ai copernico...
Isso que formamos uma comunidade de desenvolvedores Java com o slogan: "Se é Java, é FREE"
Free é uma coisa... agora bagunça no código é outra...
O código já é aberto, quem quiser ver, fique a vontade... agora se abrir... cada um faz uma coisa diferente do outro, acabando com padrões....
Tá ai pro povo que quiser acompanhar:
http://www.javafree.com.br/forum/viewtopic.php?t=4728
Um grande abraço a todos!
Gentoo r0x
Lucas
Copernico,
Muito boas as suas explanações, mas sinceramente se o problema é o domínio do NOME Java, qual seria o problema da licença LGPL ?
Assim como qualquer um hoje pode fazer um fork do linux ou do Mozilla e gerar outro sistema/browser (mas não pode chamar de linux/mozilla porque são MARCAS registradas), quem gerasse uma JVM derivada do código da Sun não poderia chamar de Java também, assim como hoje o Kaffe não pode se chamar Java.
Se é problema de marca e de copyright, basta registrar a marca Java(TM) de propriedade da Sun e colocar na licença que qualquer código derivado dela deva ser GPL/LGPL e não será considerado Java.
Complementando, acho que a visão de quem é contra a abertura do código-fonte é de comodidade, de quem quer apenas USAR algo de forma prática e não pagar por ele, não de tentar ajudar a melhorar problemas da linguagem/JVM.
Todo mundo sabe que a JVM da Sun tem graves problemas de desempenho. E se aparecesse um gênio, olhasse o código da JVM da Sun e sugerisse modificações para que o desempenho melhorasse muito ? A Sun só iria ganhar caso a licença fosse GPL/LGPL, pois ninguém poderia pegar a sua JVM e vender como se fosse sua, além de não poder chamá-la de Java.
O linux é o que ele é hoje porque muita gente pode ver e dar palpites sobre o seu código.
Eu não sei como as especificações da linguagem são feitas hoje, mas por que não aceitar sugestões de seus usuários (caso só a Sun possa dar palpites nesse sentido) ?
Não sei não, mas eu acho que achar bom que o fato da Sun ter controle total é a mesma coisa que achar que é bom ter um déspota esclarecido no governo (um ditador benevolente e que sabe o que está fazendo).
"Complementando, acho que a visão de quem é contra a abertura do código-fonte é de comodidade, de quem quer apenas USAR algo de forma prática e não pagar por ele, não de tentar ajudar a melhorar problemas da linguagem/JVM."
Não. A Visão de quem é contra é a possibilidade de a abertura despadronizar a JVM, quem quer ajudar entra no JCP que inclusive está tomando medidas para desburocratizar a participação dos interessados.
"Todo mundo sabe que a JVM da Sun tem graves problemas de desempenho."
Esse é o problema, todos os que "dizem que sabem"
poderiam entrar no JCP e sugerir mudanças. Se fosse para melhorar dúvido que os menbros do JCP ( a SUN inclusive ) não aprovessem. Agora o que acontece é que muita gente mete o pau sem saber do que esta falando. E algumas pessoas que sabem do que estão falando não querem entrar no JCP
"E se aparecesse um gênio, olhasse o código da JVM da Sun e sugerisse modificações para que o desempenho melhorasse muito ?"
Entra no JCP e ajuda. A Sun e os outros membros aprovariam, melhorar o desempenho da JVM é bom para todos.
"...pois ninguém poderia pegar a sua JVM e vender como se fosse sua, além de não poder chamá-la de Java..."
O Problema não é pegar e vender. O Problema é ter IBM-Virtual Machine, MS-Virtual Machine, Apple-Virtual Machine, etc...
Logo quando o desenvolvedor quando fosse criar aplicação teria de perguntar : Mas vai rodar em qual JVM ???
Ai vc. responde. É só todas seguirem a especificação, só que isso não funciona.
Pegue o exemplo do C, se vc. escreve um programa na plataforma windows compilando com turbo C, ou Visual C++ não compila no gcc.
Vc. replica, roda se vc. usar o ANSI C
E eu respondo, mas quem programa usando apenas o ANSI C ???
Cada Empresa iria colocar funcionalidades na sua VM que outras não colocariam. Ai para aproveitar essa funcionalidade vc teria que escrever para essa jvm. Acaba o sonho do "write once, run everywhere"
Estão usando os mesmos argumentos que se usa contra o Linux: se é aberto não tem confiabilidade, se é aberto vira uma confusão, se não existe uma grande empresa por trás não há qualidade, suporte e afins....sinceramente....se vocês usam Linux e não querem a abertura do Java realmente há uma contradição.....até hoje o "bazar" do Linux vem funcionando muito bem...
Complementando :
Mesmo liberando sobre a GPL, a IBM lança a IBM-Java Virtual Machine e disponibiliza o código.
A MS lanca a MS-Java Virtual Machine e pasmem, libera o código também.
Ambas estão dentro da GPL, pegaram , melhoraram e disponibilizaram.
Mas ai dá um pau na aplicação e eu ligo na IBM :
Está rodando na MS-Java Virtual Machine, procure a Microsost para resolver o problema.
No Linux poderia acontecer isso também ?
Não Poderia. Alguém poderia pegar o Kernel e
criar uma versão exclusiva do Linux. Chamaria de XLinux, mas ningúem usaria porque as grandes distros usam apenas o kernel supervisionado pelo Linus Torvalds, junto com membros da equipe que mantém o Kernel
São produtos diferentes e situações diferentes. Não adianta dizer : No Linux tem funcionado até agora.
Pessoal, obrigado pela atenção que estão dedicando ao tópico, porque ele é mesmo muito importante.
Vamos esclarecer alguns pontos:
1- Não, não se trata só do NOME Java (que sim, já é registrado para a SUN). E sim do legado de uma plataforma consagrada e da autoridade de quem a controla. É por coisas assim que as corporações brigam de foice... Por exemplo, o Apache Group tb. não empresta seu sêlo a qualquer coisa.
2- Sobre a JVM: Qualquer um pode implementar uma JVM, pessoal! No site da SUN (vcs. conhecem, mas fica aqui registrado: http://java.sun.com) é possível encontrar todas as informações necessárias para implementação, com todo o comportamento que é necessário para que uma JVM passe nos testes de homologação (se não passar, vc. não pode usar a denominação "JVM"). A implementação que vc. faz de uma JVM é um produto seu, vc. programou, então vc. distribui com a licença que quiser. O KVM é GPL. A JVM da Apple é proprietária (tanto que a Sun não pode disponibilizá-la para download em seu site - Pq a JVM compatível com windows pode? Bem, pq a JVM que está lá foi codificada pela SUN). Se algum gênio (como o Tosatti, o Stalman ou o Linus :] ) quiser criar uma JVM de alto desempenho que seja LGPL, com certeza vai conseguir fazer isso. Em momento algum a SUN defende a sua JVM como a MELHOR implementação e sim como uma implementação DE REFERÊNCIA (desculpem pelos caps, mas não tem negrito aqui...). Nem mesmo a idéia de JVM é nova, outras plataformas já faziam isso antes do java. Infelizmente a M$ lançou a 1a. versão do .NET com o código que conseguiu copiar do Java 1.1 (ao invés de investir e criar uma implementação própria, mas é assim que ela costuma fazer), por isso que o coletor de lixo do .NET ainda é tão atrasado em relação ao java atual.
3- Então vamos colocar os pingos nos iis, pra não haver falhas de interpretação. O que está sendo discutido não é a abertura da implementação da JVM (ela é só mais um programa, gente!). O que está fazendo tanto barulho é a abertura de TODA A PLATAFORMA. Isso significa modificar as especificações e a própria API, sem restrições.
4- Eu uso o jikes e o KVM em linux e acho que eles funcionam muito bem. Enquanto a plataforma java não for liberada não importa qual a implementação que estou usando eu tenho certeza de estar usando Java, compatível com qualquer outra implementação.
5- Manoel: as especificações Java sofrem influência dos seus usuários sim! :)))) O que ocorre é o seguinte: tudo na plataforma passa por um processo conhecido como JCP (Java Community Process), suportado por vários sistemas de workflow. Toda proposta (JSR) é analisada por um conselho escolhido por eleições diretas entre os membros da comunidade (qualquer indivíduo ou empresa pode ser membro da comunidade). Uma vez aprovada, com ou sem emendas, o conselho escolhe profissionais entre os membros para formar o grupo de trabalho que terá a tarefa de desenvolver a especificação e uma implementação de referência - O pessoal do projeto jakarta do Apache Group, estão entre os profissionais mais cotados). O processo de evolução do Java é aberto quem manda é o JCP. O único direto ao qual a SUN se reserva é uma cadeira vitalícia no conselho (uma ÚNICA cadeira). Existe também um "acordo de confidencialidade" onde reza que os resultados ou decisões dentro de um grupo de trabalho não podem ser divulgados até que a JSR seja definitivamente liberada (o "draft" da especificação seja publicado oficialmente). Isso nos permite pegar a M$ de surpresa, como fizemos agora com o Java 1.5.
Vários desenvolvedores brasileiros participam pessoalmente ou através de suas empresas no JCP. No fundo, o processo se parece muito com o do W3C ssó que é beeeeeemmmm mais ágil. Java não teria chegado ao que é sem o JCP.
6- Para quem ainda acha que a JVM tem "problemas de performance": benchmarks recentes feitos entre java 1.4+ e outras plataformas mostram um desempenho comparável ao C++ e dando poeira em muitas outras plataformas. O 1.4 só perdia em operações trigonométricas, mas isso já deve estar resolvido na nova versão. Claro, estou falando da JVM da SUN, a performance de cada JVM é responsabilidade de seu criador. Mas, pelo que eu sei, o KVM também não tá muito atrás não...
Resumindo: Não "usamos o Java de forma prática", quem faz isso é o usuário final. Nós desenvolvedores trabalhamos por ele :).
É o JCP, um processo democrático, quem manda no Java, não a SUN. Somos uma "república parlamentar". Quem quiser fazer parte, junte-se a nós!
Resumindo e Complementando:
Java não precisa ser aberto porque ele já é. Só que com uma licença e um processo diferente, que não permite que ninguém tome posse da bola nem mude as regras do jogo.
Se vamos condenar a plataforma por isso, porque não vamos pleitear os SO BSD para o LGPL tb?
A maioria dos sistemas e bibliotecas que crio como desenvolvedor são abertos, mas não os distribuo como LGPL (mesmo pq ela não é completamente legal no Brasil). Uso minha própria licença, baseada na LGPL sim, mas com ressalvas adicionais para proteger a integridade do meu trabalho (muitas vezes com benefício do meu usuário final).
Nem tudo que é livre é GPL.
Java não é livre, ponto.
Java aceita ajuda, mas tem um controle monárquico, ao contrário do modelo "Ditador Benevolente".
Se a perda desse controle gera caos, não entendo Perl, Python e PHP fazerem tanto sucesso e crescerem sendo liberadas sob "licenças de software livre" (http://www.fsf.org/licenses/license-list.html).
O problema é que esse é um controle forçado, não-natural. O Software Livre permite a seleção natural das linguagens.
Uma das coisas que mais me desagradam em Java é o fato de Java não ser "uma" coisa, mas um amontoado de tecnologias, umas que acho interessantes e outras que não, mas que só podem ser adquiridas em pacote.
Uma das vantagens de Java ser liberado, seria a possibilidade de modularizarmos as tecnologias de Java. A partir daí seria feita a seleção natural em todas essas tecnologias e Java poderia ajudar e ser ajudada por outros projetos no nível Código-Fonte. Traduzindo: riqueza em conhecimento.
Enfim, considero a recusa da Sun um fato simplesmente lamentável. E continuarei investindo nas linguagens de script :)
"Java não é livre, ponto."
Java é livre, ponto.
( Falar por falar é simples )
"Java aceita ajuda, mas tem um controle monárquico, ao contrário do modelo "Ditador Benevolente". "
Um controle Monárquico ?
Já ficou claro que não é a SUN e sim o JCP que detêm o controle
"Se a perda desse controle gera caos, não entendo Perl, Python e PHP fazerem tanto sucesso"
Mas não estamos falando só daLinguagem e sim da Plataforma. Não adianta ficar falando que funciona em X se X é diferente de Java
"O problema é que esse é um controle forçado, não-natural. O Software Livre permite a seleção natural das linguagens."
É um controle exercido por uma comunidade.
Novamente, qualquer um é livre para participar e sugerir mudanças. Não sei porque essa resistência em entender esse ponto. Falam como se Java fosse um produto fechado que só a SUN tem acesso.
"Novamente, qualquer um é livre para participar e sugerir mudanças..."
Mudanças no que se tornará a nova versão do Amontoado Java, mas não trabalhos derivados, substituições e mudanças que mudem um pouco o caminho (não estou falando de *gerar incompatibilidades*, mas de *adaptar*). O conceito de Software Livre é: você pode utilizar livremente (ok), modificar (epa! Eu não posso modificar o Java: quem modifica é a Sun e eu só posso sugerir. E se eu quiser uma mudança que só será útil para mim?) e distribuir (não sei como anda o classpath da Sun, mas tinha um problema nesse ponto).
O que se está tratando como liberdade afinal? Eu posso mudar a constituição, posso mudar o mundo. Mas isso esse "posso" tem significado muito diferente do "posso modificar" de um software realmente livre.
"mas não os distribuo como LGPL (mesmo pq ela não é completamente legal no Brasil)."
FUD ALARM! A CC-LGPL é o quê então? A adoção PELO GOVERNO dessa licença não diz nada? Ah, valha-me!
http://www.planetarium.com.br/planetarium/noticias/2004/1/1073652245/
http://creativecommons.org/license/cc-lgpl?lang=pt
Tsc.
Patola,
O simples fato de uma licença ser adotada pelo governo brasileiro não quer dizer que ela seja legal. ( O Waldomiro também foi adotado pelo governo, mas sua conduta não foi nem um pouco legal ahuahuahuha)
Pode haver muita discussão jurídica em torno de uma licença xGPL.
O que deve-se buscar é a sua regulamentação via legislativo para não haver mais dúvidas.
Abraços
Cássio
Não vou entrar na discussão sobre Java ser livre ou não. Java é livre. Mas as únicas implementações da JVM que funcionam 100% hoje não são distribuidas sob licença GPL (ou compatível).
Vou simplesmente fazer um convite.
Convido a todos os desenvolvedores que gostam de software livre a aprenderem Python. É rápido. Eu garanto. Você também não vai precisar jogar nenhum dos conhecimentos que já tem fora para aprender a programar em Python. Acredito que com umas 8 horinhas um programador Java (não precisa ser experiente) consegue aprender Python. As implementações da linguagem Python possuem licenças compatíveis com a GPL.
Para aqueles que querem aprender Python mas por algum motivo precisam ou preferem usar uma JVM (proprietária) podem experimentar o Jython.
Para aqueles que gostam do Java do jeito que está e não fazem questão de aprender algo novo e querem programar simplesmente para garantir um bom emprego, podem continuar do jeito que estão. O meu convite é para aqueles que querem aprender coisas novas.
Mas também é só um convite. Aceita quem quer.
(para mais informações sobre Python: http://www.pythonbrasil.com.br e http://www.python.org).
Não entendi seu comentário Augusto... o que você quer dizer com isso!? o.O
O Java já é aberto, você pode ir no site da Sun e baixar o codigo fonte da JVM, documentação, especificação da linguagem (redundante), tudo!
Todos podem participar do desenvolvimento, basta se inscrever no JCP e um abraço.
Um dos grandes pontos fortes para a Sun não adotar a licença GPL por um motivo bem conhecido pela comunidade linux, os softwares com licença GPL acontecem muitos fork. Existindo um fork no Java, perderia, seria ao meu ver, a maior vantagem desta linguagem, "portabilidade", isso é eu compilar um programa em Java e poder rodar em qualquer maquina que possua a JVM.
Existe outras JVM, e percebe-se que não seguem o padrão Java. Escreva um aplicação que roda no Kaffe ou Blackdown, muitas vezes não roda na JVM Sun, o contrario tambem é valido.
A ideia principal é manter os padrões.
Abraços,
André Felício.
Cássio:
O Legislativo não regulamenta licenças. Você já viu por acaso algum documento do legislativo falando algo como "esse documento nós regulamentamos, pode confiar, está OK!"? Não, né? O máximo que pode acontecer é um processo que valida ou invalida determinado contrato, incluídas aí as licenças.
A CC-LGPL e CC-GPL são resultado de muito tempo de discussão e de uma licença feita e abençoada pela Fundação do Software Livre e pelo governo brasileiro. As duas únicas falhas jurídicas encontradas nas licenças LGPL e GPL com relação ao direito brasileiro - ser em inglês e apresentar isenção de responsabilidades - foram corrigidas. E como estão de acordo com as leis de copyright, não há como contestar sua validade. Seria como contestar qualquer outra licença de uso!
Se ela apresenta um status jurídico igual ao de qualquer outra licença de uso - e eu argumentaria que apresenta um status ainda mais elevado pela bênção do governo brasileiro -, não há como você justificar esse "temor" pela legalidade da licença. Pode crer que criar a sua própria, mesmo com a ajuda de um advogado, seria ordens de grandeza mais "arriscado".
Senhores: acidbase, josé felício, LinuxNewsReader:
Quando falamos em 'aberto' e 'livre', podem existir muitas interpretações. Quando falamos em um fórum de software livre e GNU/Linux, pensava estar bem óbvio que é de algo consoante com as guidelines da free software foundation (as 4 liberdades) - http://www.gnu.org/philosophy/free-sw.html - ou da open source definition da open source initiative - http://www.opensource.org/docs/definition.php . Se chamamos de "livre" e "aberto" qualquer coisa que mostre código, então podemos até falar isso do horrível programa shared source da microsoft... portanto acho que devemos adotar uma definição mais restrita, em vez deste 'achismo' sobre o que pode ser livre e/ou aberto.
Caro Patola (Cláudio Sampaio),
1 - Você considera o Mozilla/Apache como sendo livre? se sim em quaquer um dos softwares, então você esta descordando de seu consceito de livre citado anteriormente (GPL e etc).
2 - Os comentarios e a interpretação são relacionados a noticia.
Depois dessa, agora não sei mais o que é livre!!
O Java é "livre"! Este negocio de levantar bandeira por religião ou apenas por ignorancia, (já coloquei minha roupa de amianto), não ajuda em nada para estes comentarios.
Discordar de Copernico é ignorancia e talvez até burrice (claro, não estou falando sobre licenciamento). O que ele falou é fato e não teoria/especulação.
Ler e se informar antes de comentar algo ajuda muito, melhor do que comentar com base em teorias/tolices e etc.
A noticia é apenas sobre colocar o Java na licença GPL, que ao meu ver não seria vantagem, isso pelo motivo que citei anteriormente.
Abraços,
André Felício.
PS.: Não to querendo gerar maiores flames. Desculpe se alguem interpretar de forma diferente.
Só complementando, alguem já leu a licença do Java Sun? Leiam e se esclareçam melhor.
Tenho mais "liberdade" que a licença GPL. Só um exemplo:
Se eu quiser desenvolver minha VM, posso pegar todo material da Sun e lançar com a lincença que eu bem entender.
Se fosse GPL, só poderia lançar como GPL.
Claro a restrição é, se eu quiser chamar de Java (manter portabilidade), preciso seguir os padrões.
Mais liberdade do que isso é dificil, é a mesma coisa que dizer que a licença BSD não é "livre" só por causa que não é GPL.
Quanta bobagem, André...
Você está comparando um padrão que especifica uma linguagem, ao software que trabalha com essa linguagem.
É claro que eu posso fazer uma VM pra Java, e liberar em qualquer licença. Eu só tenho a especificação!
Agora, se a Sun libera a VM dela na GPL, qualquer alteração que eu fizer tb tem que ser GPL. Se eu quiser adicionar recursos à linguagem e tiver que modificar a VM pra isso, tem que ir por GPL.
E, se eu quiser resolver o maior problema e maior fonte de reclamações da plataforma Java - performance, falta de uniformidade, incompatibilidade entre sistemas diferentes - tb tenho que lançar o produto em GPL.
Você diz que o Java é livre?? Cadê o código? Você pode mexer nele? Pode estender? Pode ser "free as beer"... mas não é free, não. Religiões à parte, trate de rever seus conceitos.
"falta de uniformidade, incompatibilidade entre sistemas diferentes" - hm, talvez estejamos falando de coisas diferentes.
É engraçado ver que aqui claramente temos dois grupos: os que usam Java e (assim como eu) preferem o sistema JCP do que perder o padrão, e aqueles que não usam. Mas isso é normal...
sempre quem não conhece desce a lenha mesmo.
E sobre o JCP, já foi explicado tudo. Mas não adianta: ou é GPL, ou não agrada os xiitas (que nem usam Java, usam Python). Vão encher os BSDeiros também, ué...
Bom, concordo com o Manoel Pinho quando ele disse que a maior vantagem da Sun abria a JVM dela seria o efeito psicológico, ainda mais agora que o .NET está avançando.
Alguém falou que a MS copiou o J2EE 1.1 e isso não é bem assim. Ele está subestimando o .NET e esse é o maior erro a meu ver dos concorrentes da MS: achar que ela fica parada no tempo.
A MS pegou todas as especificações que os desenvolvedores pediam para a Sun incorporar na linguagem e não foram atendidos, ela desenvolveu no .NET. Algumas dessas especificalções só agora a Sun acordou e vai colocar no 1.5. Então, quem está mais atrasada nem sempre é a MS.
Outra: a máquina virtual do .NET é muito, muito, mais rápida que a JVM da Sun. Nao tem nem comparação. E o fato da MS portar todas as aplicações Win32 para .NET vai dar um impulso nessa plataforma que se a Sun não reagir, todos vamos perder, já que o Windows vai ficar muito mais fechado. Da mesma forma que a programação DOS deu lugar ao Win32, esse vai dar lugar ao .NET, e isso é fato. A Sun ou outras empresas tem que agir rápido para que a MS não fique com um monopólio ainda mais forte e o Linux encontre uma barreira.
Já está mais do que claro que a palavra "livre" ou "free", nesta discussão é apenas um honorífico. Tem o seu apelo retórico, cativa as mentes dos leitores e, por isso, cada lado da contenda quer trazer a palavra para perto de si. Um diz: "Java é livre", para que os leitores lancem olhares respeitosos para o Java. O outro retruca: "Java não é livre", para que os leitores repudiem Java.
Já passou da hora de perceber que esta discussão não importa. Em primeiro lugar, manter este jogo retórico não traz ganho cognitivo. Não se chega a lugar nenhum. Em segundo lugar, a amplitude semântica do termo "livre" é larga demais para querer restringir "é livre" para "está sob GPL". Isso é um atentado contra a linguagem.
A discussão que realmente importa é: quais as vantagens e desvantagens de se colocar a tecnologia JAVA sob licença GPL? Quem ganha e quem perde com isso? Do ponto de vista do desenvolvedor Java (aquele que desenvolve a tecnologia JAVA), será melhor ou pior? Em quais situações será melhor, em quais será pior? As vantagens compensam as desvantagens? E do ponto de vista do programador (aquele que usa a linguagem JAVA para escrever aplicativos) será mais vantajoso ou não? Por fim, quais serão as vantagens e desvantagens para o usuário final (aquele que simplesmente roda aplicativos java)? Terá mais dificuldades para instalar os seus aplicativos? Como os possíveis problema de incompatibilidade poderão afetá-lo?
Só depois de avaliar todas essas questões, de modo sério e mais imparcial possível, é que se pode chegar a uma conclusão mais clara quanto a ser vantajoso ou não, em geral, colocar a tecnologia JAVA sob a GPL.
Alguns dos colegas já responderam muitas destas questões, como o Copernico. A discussão, eu penso, deveria seguir este caminho. Todos terão a ganhar, assim.
O conceito de liberdade é muito amplo, mas estamos em um portal de Software Livre. Há um consenso sobre o que é Software Livre entre FSF, Debian, OSI e as demais comunidades que o defendem, ao menos em alguns aspectos. Acredito que Java não siga esses critérios (estou certo neste ponto?).
Dizer que um software é livre em um portal de Software Livre, ele não sendo considerável Software Livre segundo as definições de nenhum desses três grupos, a meu ver é fazer desinformação (não digo que necessariamente com este objetivo).
Acho que quando o pessoal diz que o JVM é + lento, estão na realidade se referindo as montagens de tela, widgets, montagem de listas e afins. Mesmo eu nao sendo um programa Java, tenho certeza que para calculos e processos internos ele seja rápido.
Essa discussão toda de Java é livre/não é livre tá parecendo uma briga de colégio, a liberdade é algo relativo que vária de pessoa para pessoa e assim é melhor, pois na mão dos imperfeitos homens a liberdade absoluta seria um caus. O que há de errado em o JAVA não ser aberto para uns e ser padrão aberto para outros ? Viva a liberdade de pensamento!
Alguém disse que "livre" é "somente ser GPL"? Bom, eu nunca disse isso. André Felício e Eros Carvalho, leiam atentamente as duas referências que eu passei: as 4 liberdades da free software foundation e a open source definition da open source initiative. Nenhuma delas se restringe apenas à GPL - e claramente englobam outras licenças como BSD, Apache, MIT, LGPL, MPL, etc. Na Open Source Initiative temos até uma listagem das licenças consideradas como "open source"!
Quando permitimos que qualquer definição seja válida, temos a aberração de conceitos que permite que a Microsoft diga que está "liberando" seu código quando faz o shared source, como exemplo mais gritante. Liberando nada! Ela está é prendendo mais, fazendo as pessoas só poderem ver o código assinando um contrato de confidencialidade e não podendo nem compilar!
Então vamos parar com essa bobagem de que "Java é livre". Prestem atenção no título desta reportagem: a Sun está dizendo que NÃO vai fazer o java virar software livre, isto é, ela está implicitamente dizendo que ele NÃO É. Querer criar sua própria definição de "livre" só porque gosta de Java é algo que me parece quase infantil.
O Patola tem essa característica de acreditar que só ele entende a GPL (ou CC-GPL) ou o que significa liberdade.
Mas vamos em frente.
Eu já li sobre a posição da FSF sobre Java. Ela apóia Java e diz que a linguagem *e* a plataforma Java são livres. Ok. Ponto final sobre isso ou ainda restam dúvidas?
Entretanto, a JVM da Sun *e* a da IBM não são VMs livres, são VMs grátis. O grande problema que eu vejo é o fato das únicas implementações 100% confiáveis (homologadas) hoje usarem licenças proprietárias.
Eu sei que tem Kaffe, gcj (que não é VM, é compilador Java), ..., ..., possuem licenças GPL (ou compatíveis) mas elas não estão em estágio avançado de compatibilidade com a plataforma e também não são confiáveis o suficiente para usá-las em processos críticos em produção.
Peço desculpas pro Patola pelo meu comentário. Eu é que não tinha entendido corretamente o que ele havia dito nos 2 comentários anteriores.
Esse é o problema da linguagem escrita. Um pouco de sonolência + discussão complexa + assunto complexo == interpretação incorreta.
Ok, uma parte da confusão vem não só das palavra "livre" ou "aberto", mas também da palavra "Java". Ela pode se referir à JVM, à linguagem, à implementação da linguagem, à linguagem + as bibliotecas, ao framework de desenvolvimento e ainda outras coisas... =)
Quando eu falo de java, vou deixar bem claro sobre o que estou falando: sobre a implementação da Sun do Java e as bibliotecas da linguagem. E acredito que é desta que a mesma está falando quando diz que não a vai colocar como open source.
Ah, sim, aCiDBaSe... o gcj não é uma máquina virtual, mas o gij é. =) Mais do que isso: GIJ - The GNU Java bytecode interpreter. GIJ is not limited to interpreting bytecode. It includes a class loader which can dynamically load shared objects, so it is possible to give it the name of a class which has been compiled and put into a shared library on the class path.
Primeiramente gostaria de dizer que ler estes threads são horriveis, tem que reservar uma bora parte do seu tempo :)
Cortei algumas partes, pois não sou um bom leitor de livros, mas a minha opinião é que se o Java fosse GPL/LGPL conseguiria mais ajuda da comunidade e não ficaria tão restrita a comunidade Java, e ainda poderia ser mais aceita por programadores de outras linguagens, pois a esperaça de melhoria em performance seria maior.
E quanto ter medo do código virar uma bagunça, eu descordo plenamente, pois eu usaria a implementação da arvore oficial, e que problema traria isso???
Parem com a politicagem...
Além de que a buracracia acabaria...
Muitos desenvolvedores não escolhem o Java por alguns features que a JCP/Sun insistem em não colocar... e a merda do .Net aproveitou isso e colocou muitas delas, acredito que esse foi um dos fatores para o .Net ter conseguido o pequeno espaço que tem hj, sem colocar o nome da M$ no meio.
Abre logo sob GPL e continuaremos usando a arvore official... uso o OpenOffice desde que nasceu com a abertura do código do StarOffice, não é uma comparação a altura, mas mostra que bagunça não vira não. A comunidade OpenSource não é só um bando de muleques codando por diversão em casa...
» Postado por: Marcos Alexandre em março 26, 2004 08:31 AM, 200.233.149:
>Outra: a máquina virtual do .NET é muito, muito, >mais rápida que a JVM da Sun. Nao tem nem >comparação.
Peraí, eu também acho que não tem comparação, até porque (desculpem a ignorância) eu não sei fazer a máquina virtual do .NET rodar no Linux, será que é por isso que o eclipse é bem pesado no windows 2000 e no meu Linux (Kurumim) de casa é rápido???
Agora, voltando ao foco da notícia...
Programo em Java pelo fato de ser multiplataforma. E uma coisa que me deixa muito irado é a falta de padrão, applets que só funcionam na VM da microsoft (O Banco do Brasil tem que ter duas versões do Office Bank para empresas), páginas de internet que só abrem no IE, etc. Do meu ponto de vista, o Java pode virar Open Source desde que não mude os padrões, gostaria de continuar desenvolvendo no meu Linux e o programa funcionar em qualquer SO que tem uma JVM. Adoro o Linux, já instalei e utilizei diversas distros, e o que mais me incomodava era a justamente a falta de padrão, alguns arquivos de configuração ficavam em diretórios diferentes, claro, sei que existe um padrão para isso, é só seguir (me corrijam se estiver errado).Só tenho que pesquisar um pouco mais e descobrir que código deve ser aberto, o compilador? Como temos o gcj, acho que não. A VM? Bom, temos a VM da IBM, da Sun e várias outras, então também não. Seria a core API? Essa eu não tenho certeza, mas acho que os fontes estão lá para qualquer um ver. Vou procurar entender melhor o caso, muitos comentários aqui foram bastante esclarecedores.
Bem, deu para perceber que comecei a programar em Java a pouco tempo :) ...
Paz
Gente, isso virou um flame... Calma, não existem egos em jogo aqui, só idéias e tecnologias.
Só como informação: Não é verídico que a VM .NET é "muito mais rápida que Java". Isso é black propaganda da M$. Todos os testes de performance que conheço (inclusive alguns que eu mesmo fiz, pq fui programador VB desde a versão 4 e quando .NET foi lançado eu recebi os CDs de beta-teste e tenho acompanhado, embora não usado em desenvolvimento, desde então) e a JVM 1.4 é mais rápida em quase todos os quesitos (e em questão de I/O, a java.nio dá até poeira...).
Python é uma ótima linguagem, gosto muito dela, mas vamos e venhamos: é mais lenta que java, mesmo que ninguém aqui tenha apontado o fato até agora.
Vou adiantar esse post. Depois comento mais (estou ocupado com um projeto aqui, que usa Java e COBOL :) ).
[]s
Copérnico,
Você deve estar se referindo ao benchmark de 9 linguagens que foi bublicado no OSNews recentemente para dizer que Python é mais lento que Java.
Ok. Benchmark == Teste de Bancada e só. Se você quiser eu faço um teste de bancada comparando Python com Java que mostraria que as duas tem performances equivalentes. Basta eu, por exemplo, comparar I/O em Python com Java e funções trigonométricas. Neste subset da vida real elas empatariam :) Já no teste da OSNews ele comparou calculos com inteiros usando tipos primitivos em Java contra Objetos inteiros em Python. Realmente parece ser uma comparação de bananas com maçãs. Python possui bibliotecas específicas para cálculos que, se usadas, apresentariam uma performance equivalente.
Mas não é este o caso.
O fato de Python possuir como principal implementação um software livre permite que só nesta semana fossem aplicados 3 patches no interpretador para melhorar a performance da linguagem. E esses patches são constantemente enviados para os desenvolvedores da linguagem, de forma que, se hoje Python é mais lento que Java pode ser que amanhã não seja.
Assim como o fato do Windows 'ser mais fácil de usar' do que o Linux pode se tornar mentira em pouco tempo. (*Eu* já acho que é mentira :))
Copernico, Java É mais lento, principalmente montagem de telas e widgets. O processamento dele é rápido, isso e verdade, mas enquanto eles não conseguirem que as ferramentas GUI feitas em Java sejam rápidas, estão deixando uma brecha enorme pra MS crescer.
Essa história de ficar negando as ferramentas da MS não é nova. A Netscape fazia isso: "IE é muito ruim". A Lotus também caiu na mesma: "O 123 é a melhor planilha de todos os tempos". O resultado todo mundo já conhece.
Felizmente, a Sun acordou. Só espero que eles saibam agir.
Isso so confirma que para a maioria das empresas grandes o software livre eh apenas para nao perder mercado, quando a coisa aperta e se pede para abrirem um dos principais atrativos delas acontece isso.
Isso so confirma que para a maioria das empresas grandes o software livre eh apenas para nao perder mercado, quando a coisa aperta e se pede para abrirem um dos principais atrativos delas acontece isso.
Mas nao acho que a Sun esteja errada . Eu faria o mesmo, como mtos aqui (que nao dao o braco a torcer ).
Em termos de Janelas e outras coisas, o .NET é mais rápido. Motivo simples: ele não mantém sempre em memória paralelamente todo o código que está sendo executado, e fica verificando se algo foi mudado, como a JVM. Ele mantém apenas uma pequena parte da estrutura. Vantagem: é mais rápido. Desvantagem: um pouco menos seguro (já existem vírus pra .NET).
Python É mais lerdo que Java. Ponto. É puramente interpretada. Se for pra usar patches, vamos então usar o SWT do IBM no Java, mas o que é fora do padrão. Aliás, sempre que se fala de Java, vem alguém falar de Python... isso enche o canelone, hein?
=Infelizmente a M$ lançou a 1a. versão do .NET com o código que conseguiu copiar do Java 1.1 (ao invés de investir e criar uma implementação própria, mas é assim que ela costuma fazer), por isso que o coletor de lixo do .NET ainda é tão atrasado em relação ao java atual.=
- Isso é o mesmo palavreado da gente que nao sabe admitir que o .Net é largamente superior a framework java. Eles falam mas nao provam nada.
=Se a perda desse controle gera caos, não entendo Perl, Python e PHP fazerem tanto sucesso e crescerem sendo liberadas sob "licenças de software livre"=
- Perl é disponibilizado sobre a licensa 'Artistic' do larry wall
=Acho que quando o pessoal diz que o JVM é + lento, estão na realidade se referindo as montagens de tela, widgets, montagem de listas e afins. Mesmo eu nao sendo um programa Java, tenho certeza que para calculos e processos internos ele seja rápido.=
- Para alguem que se diz da comunidade java só me posso surpreender com tal afirmaçao descabida de conhecimento. Se o Java demonstra ser horrivel em 'montagens de tela, widgets, montagem de listas e afins' imagina em aplicativos matematicos e processos internos. Uma lastima meus senhores.
Vejam: http://img.osnews.com/img/5602/results.jpg
O java perde largamente para linguagens da Microsoft.
Claro que para alguns que programaram em VB nao sentem isso mas para quem já tocou em VB.Net pode sentir um trabalho responsavel ai.
Por ultimo gostaria de endereçar meu convite a programadores cansados da porcaria do Java a juntarem-se ao projecto Mono.
http://www.go-mono.com
Agora, senhores, desculpem o meu último post. Ele violou uma das regras dessa lista aqui embaixo (pense 2 vezes antes de entrar em discussões inúteis, tipo "essa ou aquela tecnologia é melhor ou pior"). Desculpem, eu só pensei uma vez, devia ter pensado . Ninguém é perfeito.
Não é realmente isso que está em discussão aqui. O Eros levantou algumas questões as quais eu creio que devemos nos esforçar todos para responder, representando cada um nossos nichos. Esse é o motivo desta discussão: mostrarmos como somos afetados pela questão.
Eu posso responder da posição de desenvolvedor Java, usuário avançado do Java, usuário iniciante/intermediário do Linux (sei me virar num bom bsh, mas ainda adoro distros orientadas a desktop como o Kurumin e considero mexer com Slackware como um esporte radical :). Gosto de conforto, como todo bom usuário... ).
Bom, vamos lá. Como desenvolvedor (e instrutor) JAVA, a licença GPL não me atende. Ela permitiria forks na tecnologia, adicionando modificações que atendem a alguns caprichos de poucos (uma das requisições recusadas no JCP: mesclar sintaxe XML junto com a sintaxe, permitindo o uso de tags em código fonte. "Ótimo" pra quem come XML com farinha (será). Terrível para todos os outros) e dificultam a vida de muitos, o que permitiria a escrita de códigos fonte maravilhosamente mal construídos e maior dificuldade no domínio da linguagem. Permitiria a já afirmada (repetidamente, nesta lista) incompatibilidade entre versões (para os mais exaltados: SIM, incompatibilidade como as que OCORREM entre distros Linux. Em um SO, isso é aceitável. Em uma plataforma de desenvolvimento - percebam que nunca me referi a java como apenas linguagem, NÃO É ACEITÁVEL).
Como usuário do Java, a maioria dos usuários não sabe disso, mas é ruim também (muito mais do que saber que aquela distro xiita que eu uso não quer distribuir o java da Sun só pq ele não é GPL). O que vc. acharia se lesse um how-to dizendo que "o open-office que vc. tem nesse CD não funciona bem com a JRE tal, que vc. tem...". Um usuário avançado saberia trocar a JRE e resolver o problema. Usuário doméstico não sabe (e nem tem obrigação de saber). Particularmente, meus clientes gostam muito do fato de rodar meus programas no Conectiva que instalei pra ele no escritório e rodar o mesmo programa em casa, no seu Win XP OEM (eles reclamam que fica mais lento no XP, mas enfim...).
Usário de Linux: Mesmo não sendo "fera" (termo típico de usuário :] ), consigo fazer o Java funcionar no meu Kurumin (baseado no Debian, o que dificulta um pouco as coisas). Já usei tanto o Kaffe quanto a JVM da Sun. Não uso gjc, pq a velocidade das aplicações java não-nativas em Linux não me incomoda a muito tempo e ele ainda não roda bem aplicações desktop (não, eu NÃO gosto do SWT nem do GTK+ para Java. Isso é preferência pessoal).
E então senhores? Concordo que é assim que devemos conduzir a discussão. O que acham?
[]s
"Por ultimo gostaria de endereçar meu convite a programadores cansados da porcaria do Java a juntarem-se ao projecto Mono."
Gente, o Eros tinha razão. Estamos dicutindo aqui um posicionamento a respeito da tecnologia java. Não é do escopo desta discussão propagandear tecnologias nem saber qual é a melhor. Eu tenho resultados pessoais de testes que me fazem ter opinião formada e não uso parelhas. Pode ser interessante, testar o Mono (até agora só usei .NET no windows), mas duvido que me dê alguma coisa que eu já não tenha.
Vamos corrigir o escopo da discussão. Ela é importante.
[]s
Escuta, "critico"...
Eu tive a curiosidade de olhar a página q vc. postou como referência. E lá vi que vc. não é apenas contra o Java, como também contra o Linux e mesmo o software Livre! Não que seja errado, precisamos de críticas pq elas nos fazem evoluir.
Mas vc. não acha que este é o lugar impróprio para suas colocações?
Mas fica registrado para os colegas um local onde podemos encontrar críticas ao nosso trabalho e modo de vida: http://criticalinux.blogspot.com
[]s
Quanto ao mono: me mostre um programa feito no MS Visual Studio rodando no Mono, e eu pensarei em usar. Não vale Hello World. E quero com WinForms.
Alá o crítico! Ei, crítico, você já leu a página da free software foundation?
"=Se a perda desse controle gera caos, não entendo Perl, Python e PHP fazerem tanto sucesso e crescerem sendo liberadas sob "licenças de software livre"=
- Perl é disponibilizado sobre a licensa 'Artistic' do larry wall"
Engraçado, crítico. Aqui - http://www.fsf.org/licenses/license-list.html - consta que a Artistic License é livre. Ohhh, você não sabia?
Citando a página:
The license of Perl.
This license is the disjunction of the Artistic License and the GNU GPL--in other words, you can choose either of those two licenses. It qualifies as a free software license, but it may not be a real copyleft. It is compatible with the GNU GPL because the GNU GPL is one of the alternatives.
We recommend you use this license for any Perl 4 or Perl 5 package you write, to promote coherence and uniformity in Perl programming. Outside of Perl, we urge you not to use this license; it is better to use just the GNU GPL.
Copérnico,
Não concordo com suas colocações. Você de novo afirma certas coisas como se repeti-las as tornasse mais verdadeiras:
"Como desenvolvedor (e instrutor) JAVA, a licença GPL não me atende. Ela permitiria forks na tecnologia, adicionando modificações que atendem a alguns caprichos de poucos..."
Isso foi explicado e explicado novamente... A comparação com distribuições (que são montadas a partir de muitas partes diferentes) não procede, e não há nenhum motivo especial que faça com que Java seja diferente de perl, python, ruby ou qualquer outra linguagem livre nesse aspecto... elas não tiveram os forks "diferenciados", e os desenvolvedores não encontram incentivo para fazerem o mesmo com Java. Ela continuaria sendo governada pelo JCP, mas a implementação da Sun é que seria livre, pra podermos usar o código no que quiséssemos (por exemplo, incluir o CLASSPATH padrão no gij e levantá-lo pra compatibilidade com o Java 1.5). Putz, por que você não entende isso? O processo continuaria, haveria o mesmo processo que hoje em dia existe pra certificar uma máquina virtual java e suas bibliotecas como "java", tudo continuaria o mesmo.
AGORA, existe uma situação que levantaram que realmente pode levar a forks perigosos sim. No caso de uma IBM ou Microsoft da vida (que são imensas corporações e têm uma máquina de marketing imensa a seu favor, podendo impôr "padrões fora do padrão") ter o interesse em desvirtuar a linguagem, aí sim, poderíamos ter um fork malicioso - aberto, mas malicioso - que fosse como a implementação 'ligeiramente incompatível' de java da microsoft, que foi sujeita a um processo. Bom, na verdade, acho que esse perigo só aconteceria com a Microsoft: a IBM já tem sua própria implementação licenciada da linguagem Java e não acho que ela quer destruir a linguagem e sim ter mais controle do que a Sun. E o fato de virar software livre não influiria (tanto) pra isso.
Mas a Microsoft não sabe jogar direito com software livre. E se a Sun usar uma licença bem-planejada, as incompatibilidades da Microsoft ficarão na cara e serão muito mais difíceis de impôr.
Voltando à sua frase, ainda:
"Como desenvolvedor (e instrutor) JAVA, a licença GPL não me atende."
Outro erro. Quem disse nessa discussão que só poderia ser a GPL? Poderia ser uma licença livre qualquer, existem muitas. LGPL, BSD, MIT, Artistic, MPL, etc... Cada uma com suas vantagens e desvantagens. GPL seria muito ruim colocar na biblioteca de classes, porque impediria o desenvolvimento comercial, mas a LGPL serviria bem.
Pô, esses dois pontos foram MUITO batidos, e você os repete lá no fim da discussão? Na boa, sem querer ofender, mas isso me parece bastante má vontade de entender os outros.
Enquanto a Sun fica bobeando, olha o que acontece:
http://news.netcraft.com/archives/2004/03/23/aspnet_overtakes_jsp_and_java_servlets.html
"In this month's Web Server Survey the number of IP addresses with sites using ASP.NET has overtaken those using JSP and Java Servlets. The number of IP addresses found with ASP.NET has shown very strong growth in the past year with a 224% increase from 17.2K to 55.8K. JSP & Java Servlets despite being overtaken is the next fastest growing in percentage terms with a 56% increase. ... "
Já há mais sites com ASP.NET do que com JSP e Java servlets...
Não subestimem o poder de marketing e mercado da M$.
Gente é importante lembrar que o desenvolvimento da linguagem java é muito semelhante ao processo Opensource. pois existe o JCP - Java Comunity Process que define quais serão os rumos que a linguagem irá tomar, atentem para o detalhe qualquer pessoa pode participar. O papel da Sun é apenas garantir a qualidade do produto
Dynamite: a gente sabe disso. Mas os anti-java, fecham os olhos quando a gente escreve sobre o JCP.
Prá que código aberto desta linguagem terrivelmente mal desenhada? Como parece estar entranhado na "cultura Sun", Java parece um amontoado de complicações desnecessárias feitas por um matemático maluco.
AcidBase escreveu:
"Não vou entrar na discussão sobre Java ser livre ou não. Java é livre. Mas as únicas implementações da JVM que funcionam 100% hoje não são distribuidas sob licença GPL (ou compatível)."
Oswaldo Santana, vou te responder novamente o que eu já havia respondido em outra oportunidade em outro tópico relacionado a abertura do Java.
"Talvez você não se lembre (ou não saiba) que as versões Linux(Unix) do JDK original da Sun (a partir da 1.2) foram baseadas no trabalho do grupo OpenSource Blackdown.org (http://www.blackdown.org) que desenvolvia a VM Java para o Linux com extrema conformidade ao padrão desde 1996 (aproximadamente).
Todos sabemos que em 1999 a Sun (em conjunto com a Borland) fez um trabalho conjunto com o pessoal da BlackDown.org para utilizar o código de sua VM a partir da JDK1.2 e quando finalmente lançaram a versão final (pela primeira vez na história de java simultaneamente para Windows, Linux e outras plataformas - o que agora é comum) a Sun, fez um marketing absurdo do lançamento de Java 1.2 (renomeado para Java 2 - J2SE, J2EE), inclusive fazendo resalvas à Borland e é claro, a ela mesma, mas não citaram a Blackdown.org ignorando o trabalho desse grupo, que foi a PRINCIPAL base para que a versão Linux estivesse pronta juntamente com a Windows e Solaris. Após uma chuva de protestos por parte da comunidade Open Source, a Sun voltou atrás e deu os créditos (vale lembrar que em menor escala) também à Blackdown.
Hoje a Sun vem a público dizendo ser "amiga do open source" e só isso já basta para não abrir o código de sua plataforma. Com um amigo desses quem precisa de inimigo, ou seja, não dá para confiar em uma empresa com essa postura diante da comunidade Open Source, pois não sabemos em que momento a Sun poderá ser uma nova Microsoft.
A postura da Sun já não engana ninguém e só os mais inocentes não conseguem ver para que caminho que ela está levando Java.
Abraços,
Leidson Campos Ferreira
PlanetaMessenger.org"
José Antonio Meira da Rocha disse:
"Prá que código aberto desta linguagem terrivelmente mal desenhada? Como parece estar entranhado na "cultura Sun", Java parece um amontoado de complicações desnecessárias feitas por um matemático maluco."
José, podemos dizer que a Sun tem fortes tendencias a ser Microsoft, podemos dizer que a Sun não é "amiga" do Open source como ela diz, podemos falar mil coisas sobre a mesma, mas felizmente a Sun fez um excelente trabalho na linguagem Java, não existem complicações desnecessárias como você citou e muito menos é uma linguagem mal desenhada, muito pelo contrário é excelentemente bem desenhada e moderna.
A minha impressão é que você fez um comentário sem conhecimento de causa. Bem...foi o que pareceu.
Abraços,
Leidson
Manoel disse:
"Enquanto a Sun fica bobeando, olha o que acontece:
http://news.netcraft.com/archives/2004/03/23/aspnet_overtakes_jsp_and_java_servlets.html"
Bem Manoel eu concordo com você, mas é um problema dessas empresas que estão usando o ASP.net, correndo forte risco da Microsoft mudar tudo de uma hora pra outra, como fez com o ASP e o VB, e aí essas empresas terão que portar tudo de novo mais uma vez.
Abraços,
Leidson
Leidson,
Não estou torcendo para a M$, muito pelo contrário, e acho uma estupidez alguma empresa hoje basear sistemas importantes em tecnologias MS, mas temos que concordar que eles são espertos e tem muito dinheiro, além de ainda terem um monopólio no desktop que pode ser usado para derrubar a concorrência.
Quanto ao resultado do netcraft já disseram que ele é muito impreciso pela metodologia que usaram, que não identifica o uso do Java de algumas formas. De qualquer jeito, preciso ou não, esse resultado demonstra o rápido crescimento da adoção do .Net.
Embora tenhamos um Mono no linux e o Java tenha um desenvolvimento razoavelmente cooperativo e uma licença quase livre na prática, temo muito que a desunião entre a IBM e a Sun provocada por esse episódio só enfraqueça o potencial do Java para enfrentar a dura concorrência com o .Net. Seja qual for o interesse real da IBM na abertura do Java, o fato é que (na minha opinião) a desunião das duas gigantes agora vai causar mais estragos do que os danos que seriam decorrentes de uma abertura do Java, citados por alguns.
Manoel,
Nesse seu último post, você traduziu o medo de grande parte da comunidade Java, que empresas que trabalham puramente com base em interesses comerciais (no caso IBM e Sun), venham a desestabilizar a tecnologia Java.
Quanto a seu post mostrando o crescimento do .Net, acredito que é um fato, mas com certeza, grande parte das empresas ao redor do planeta, estão bastante relutantes em basear TODOS seus sistemas em tecnologias exclusivamente proprietárias (podemos traduzir M$).
Nos últimos anos existe sim uma conscientização quanto ao perigo que uma empresa corre ao manter apenas uma base tecnologica, ainda mais proprietária, onde o fornecedor pode estipular sua política de licenciamento e de preços da maneira que bem entender.
Boa colocação Manoel.
Um abraço.
Leidson
Senhores,
A partir de agora, acho que é hora de mudar um pouco o tom nesta discussão, a fim de conseguirmos chegar a conclusões.
Mas antes é inevitável responder a algumas declarações. :[
Patola:
"Não concordo com suas colocações. Você de novo afirma certas coisas como se repeti-las as tornasse mais verdadeiras".
Até onde é possível observar, as colocações SÃO verdadeiras independentemente de sua repetição ou não. Se precisar reapresentar os fatos para demonstrar ou frisar algum ponto, pretendo fazê-lo.
Java é sim, diferente de perl, python ou ruby. Estas são apenas linguagens, enquanto java é uma plataforma. A é apenas um dos elementos dessa plataforma: A máquina virtual, a API, as especificações de cada tecnologia (JMX, JAXP, etc.). Que este fato não sirva para que se use o termo "amontoado java": a definição, o relacionamento e o crescimento dessas especificações são cuidadosamente controlados pelo JCP, ao contrário do que ocorreria em um desenvolvimento descentralizado da plataforma.
Em última instãncia, a maior parte plataforma Java atual é formada de especificações. Um draft descreve uma tecnologia, sua interface e os contratos que a implementação precisa atender. É desenvolvida uma especificação de referência (que não tem a obrigação de ser a melhor implementação). A API que permite o acesso ao serviço é definida na especificação. Esta pode ser implementada por cada provedor da melhor forma, desde que obedeça à especificação.
Continuando, Patola, sobre sua colocação a respeito dos forks gerados por corporações como a M$, a IBM, etc. Bem, eu pensei que sempre era exatamente disso que sempre estivemos discutindo! A preocupação com a abertura do código vem de encontro justamente a esses ataques à especificação realizados com vários objetivos (não apenas o de contaminar a plataforma intencionalmente). Os pequenos forks não me preocupam, mas os que têm o apoio e a propaganda de uma emrpesa como a IBM e a M$, sim.
Uma corporação (como a IBM, por exemplo) visa, em primeiro lugar, o lucro e a supremacia frente a seus concorrentes. Sem o controle do JCP, uma empresa pode usar a estratégia M$: Incluir alguns recursos chamativos, embora mal especificados, e usar uma propaganda agressiva para forçar um padrão. Ao longo prazo, toda a plataforma pode sofrer.
Acho que vc. está enganado quando diz "esse perigo só aconteceria com a Microsoft: a IBM já tem sua própria implementação licenciada da linguagem Java e não acho que ela quer destruir a linguagem e sim ter mais controle do que a Sun. E o fato de virar software livre não influiria (tanto) pra isso". O maior campo de batalha da IBM é o J2EE (pra quem não está a par da "sopa de letrinhas", trata-se da tecnologia java para servidores de aplicação), a luta para pôr o IBM Websphere no topo do mercado, contra o Sun ONE que saiu primeiro com a compatibilidade com a nova especificação J2EE 1.4.
Depois de não ser bem sucedida na campanha a favor da abertura da plataforma Java, a IBM e a BEA iniciaram um trabalho junto com a Sun para apresentar as especificações usadas no WebLogic Workshop 8.1 ao JCP e propô-los como padrão. No meu entender, é assim que as coisas devem acontecer. Qualquer mudança deve passar pelo crivo do JCP. Não vou me repetir dessa vez :] descrevendo novamente o funcionamento do mesmo e o motivo pelo qual este representa um processo democrático que leva em conta os interesses de toda a comunidade. O conceito "a Sun aceita ajuda" é incorreto. "Aceitar ajuda" é eu usar seu trabalho para desenvolver meu produto para depois vendê-lo de volta pra você com código fechado. O Sr. Balmer anunciou uma "comunidade" assim para seus produtos, para "fazer frente à comunidade Open-Source". Tsc.
Agora em relação à abertura da JVM: realmente o código atual da JVM é fechado pela Sun (e mesmo aberto, isso seria feito com a licença da Sun, que é um pouco mais restritiva). O que é aberto, isso sim, é a especificação para implementação de cada JVM específico ( http://java.sun.com/docs/books/vmspec/index.html ). Como disse aí em cima, o que menos importa na plataforma java é o código de implementação, a especificação é o que mais importa.
Em tempo: embora o código esteja disponível, é um pouco difícil encontrar os fontes da API java (não é a JVM em si, mas os fontes das classes que formam a API). Isso é uma crítica: a Sun deveria disponibilizar esse código de maneira visível no java.sun.com.
Pra quem gostaria de dar uma olhada ou utilizar esse código, ele pode ser encontrado nos fontes do OpenOffice ( http://download.openoffice.org ) - obs: A última vez que abri esse código faz tempo, ainda na versão 1.0, não tenho certeza do que ainda está distribuído realmente no pacote dos fontes, mas vale dar uma olhada.
Outro ponto a considerar é o que está realmente em discussão: Não é a abertura da JVM que está provocando tanto barulho (VMs não são uma exclusividade do java e não são novidade para a comunidade) e sim a abertura da plataforma Java em si (invalidando o Java Comunity Process). É com isso que não concordamos.
Se a Sun, resolver abrir o código de sua JVM, pouco importa, desde que o código desenvolvido a partir dela continue respeitando as especificações definidas pelo JCP.
Existem várias implementações de JVM (e compiladores!) livres, algumas realmente muito boas, ao contrário do que se apregoa. Para quem gostaria de avaliar algumas delas, dê uma olhada em http://joeq.sourceforge.net/other_os_java.htm. Uma das opções é o Guaraná, um projeto de JVM brasileiro. O que está faltando ver é uma implementação livre de JVM do Apache Group. Tenho certeza de que eles iniciariam um ótimo trabalho.
Com o risco de me tornar repetitivo, mas esperando ter contribuído com mais informações sobre a questão, volto a concluir: A desquelificação do JCP como processo que controla o crescimento da plataforma Java causará prejuízo a desenvolvedores e usuários.
[]s
Copérnico, julgo suas informações como incorretas porque, como o JCP é um processo, não há como torná-lo "open source". A Sun mesmo na reportagem e em suas declarações não especifica bem o que ela chama de "java" nesse contexto, mas acredito eu ser a sua implementação de referência (JVM + compilador + bibliotecas). Se você ler minhas mensagens acima, eu disse: "Quando eu falo de java, vou deixar bem claro sobre o que estou falando: sobre a implementação da Sun do Java e as bibliotecas da linguagem".
A meu ver, o processo do JCP não mudaria uma vírgula, e nem tem por que fazê-lo.
Senhores dessa lista, perdoem-me meu silêncio esses dias. Estive ocupado com um projeto.
Não Patola, não é assim. A GPL e mesmo a LGPL (principais licenças do FSF, padrão para outras licenças compatíveis) são incompatíveis com o processo JCP, impedindo determinadas restrições que nele são utilizadas. Uma delas é o acordo de confidencialidade (em vigor dentro de um Expert Group até que uma revisão pública seja liberada), outra é a obrigatoriedade de submeter todas as propostas de alteração ao comitê do JCP (não permite, portanto, a "liberdade completa de modificar e redistribuir o código" dessas licenças).
E, como disse antes, uma cisão do Java em uma versão fora do JCP só iria enfraquecer o padrão ao mesmo tempo que nada acrescenta à plataforma, pois já existe uma forma da comunidade atuar sobre a mesma e afastar o risco de que ela se torne proprietária.
Esclarecendo sua dúvida sobre o que a Sun entende como "Java": Os Java Runtime Enviroment (JRE) que geram a JVM são produtos que obedecem a uma especificação e não fazem realmente parte da plataforma Java (a especificação faz parte, mas o programa em si, não), por isso podem seguir qualquer espécie de licença. O mesmo vale para os compiladores.
Já as bibliotecas, a parte fundamental delas faz sim parte da plataforma. O código-fonte dessas bibliotecas (a API Java) se encontra disponível em qualquer download do J2SDK (Kit de desenvolvimento - tinha me esquecido desse detalhe em meu último comentário, gente! Ao instalar o J2SDK, vejam o código dentro do src.zip). A maior parte desse código NÃO É GPL ou compatível, mas sim protegido pela licença da Sun (código pode ser disponível, mas não pode ser alterado total ou parcialmente. Pode ser distribuído livremente e livre de taxas, com a mesma licença original). Atualmente, uma boa parte desse código não é realmente escrita pela Sun, por se tratar de implementações de especificações (ODMG, W3C, Apache, etc) controladas pelo JCP. Isso faz com que as licenças das implementações seja variada. Isso é correto, visto que uma vez que uma especificação é liberada, a implementação em si pode ser distribuída de qualquer forma que o autor desejar. Esse código é incluído no J2SDK sob autorização de seus autores e/ou de sua licença.
As partes mais importantes da coisa, as que estão em discussão, são:
* Não, ninguém pode modificar o CORE do Java. Não posso modificar a classe java.lang.String, por exemplo (graças ao Bom Deus) e oferecer como Java (porque ela é protegida pela licença da Sun).
* A plataforma em si, o que inclui o "esqueleto" das implementações das especificações construídas no JCP também não pode ser alterada. Isso faz com que todas as implementações de Java tenham que manter a mesma API.
* A linguagem e sua arquitetura, assim como a especificação de JVM também não podem ser modificadas por meios outros que não o JCP.
Transformar a licença do Java, além de não ser simples, causaria conseqüências perigosas a médio e longo prazo. E desnecessário, visto que muito pouco da tecnologia Java pode ser realmente considerado "não livre". Isso porque vc. pode implementar classes novas, baseadas no CORE do Java, com a licença que vc. bem entender e distribuir como quiser, desde que:
a) O faça sem incluir a API CORE.
b) Distribua juntamente com a API Java, mas a mantenha exatamente como vc. obteve (completa e com a proteção das licenças envolvidas).
c) Se as suas modificações devem fazer parte de uma distribuição Java, elas precisam terem sido aprovadas pelo JCP.
Considero a solução atual razoável. Não acho realmente necessário mudar nenhuma vírgula... Não vejo a utilidade da abertura.
Não sei se já foi postato, mas pra quem pediu WinForms rodando em Linux, aí vai:
http://www.mono-project.com/about/applications.html
Falow, abraços a todos,
Bruno
Comentários desativados: Esta discussão é antiga e foi arquivada, não é mais possível enviar comentários adicionais.