Fonte: Sun Liberalizes Java Compatibility Testing (em inglês), por Java News Desk, 10 agosto 2007, em Java Developer’s Journal (JDJ).
A Sun, que sempre foi exigente e protecionista quanto a seus testes de compatibilidade Java, afirmou no dia 8 passado que estava colocando sua certificação “escreva uma vez, rode em qualquer lugar (WORA, “write once, run anywhere“) nas mãos da comunidade, com o lançamento da Licença OpenJDK Community Technology Compatibility Kit v1.0 (PDF, em inglês, 08/08/2007).
Rich Green, vice-presidente executivo de Software da Sun, no anúncio de imprensa Sun Releases New License for Java Compatibility Tests to the OpenJDK Community (em inglês, 09/08/2007), afirmou: “É um novo marco no lançamento da tecnologia Java como software de código aberto. Estamos ansiosos para ver implementações baseadas no OpenJDK passarem no JCK, para que tenhamos implementações livres e compatíveis da tecnologia Java disponíveis em distribuições GNU/Linux em todo lugar”.
Embora o licenciado precise participar da Comunidade Sun OpenJDK, a licença permite que a Sun licencie certos kits seus de compatibilidade da tecnologia Java (JCK/TCK) para facilitar as atividades daqueles que:
- desenvolvem e queiram distribuir sob Licença GPL uma implementação da Especificação Java SE 6 com compatibilidade testada;
- desejem verificar que mudanças feitas pelo licenciado no código base do OpenJDK não quebram a compatibilidade.
A licença é para o JCK (Java Compatibility Kit), o TCK (Technology Compatibility Kit) para a plataforma Java SE, que é uma suíte de testes, ferramentas e documentação para determinar se uma implementação satisfaz ou não a especificação Java Platform Standard Edition 6. A implementação que passa nos testes do JCK recebe a marca e o logo “Java compatible”.
Até então, os desenvolvedores de software livre da tecnologia Java estavam brigando para obter acesso aos testes. Porém, o projeto Apache Harmony, implementação independente do Java SE 5 JDK como software livre sob Licença Apache v2, ainda não se qualifica a usar o TCK neste licenciamento, pois não é nem GPL nem baseado no OpenJDK.
A Sun ainda não pôde liberar toda a tecnologia Java como código aberto por causa de partes dependentes/vinculadas a terceiros. O projeto OpenJDK inicialmente disponibilizou a JVM HotSpot, o compilador javac e JavaHelp como componentes de código aberto.
A Comunidade OpenJDK vêm evoluindo nos Projetos de JDK abertos:
- OpenJDK, projeto principal Open-Source JDK Community.
- JDK 6 Project.
- JDK 7 Project. Veja também Colaborando com a Sun no JDK 7 (em inglês) e A Estrada Aberta: Olhando à frente para Java 7 (em inglês), por David Flanagan, 09/08/2007.
- Tiger (J2SE 5.0) Releases – desde J2SE 5.0 update release 3, a Sun tornou o código fonte das atualizações do Tiger disponíveis para a comunidade de desenvolvedores sob as licenças restritas Java Research License (JRL) e Java Internal Use License (JIUL).
Para saber mais:
- Sun lowers barriers to open-source Java (em inglês), por Stephen Shankland, 08/08/2007, em CNET News.com.
- Sun Grants TCK Access to OpenJDK Based Projects (em inglês), por Michael Urban, 09/08/2007, em JavaLobby.
- Score Another for Clarity and Transparency (em inglês), por Rich Green em seu blog, 09/08/2007.
- Free and Open Source Java FAQ (em inglês) atualizado, incluindo tópicos sobre TCK.
- Planet JDK (em inglês), portal de blogs sobre JDK.
- FAQ Apache Open Letter to Sun Microsystems.
- Sun anuncia o fim da transição do Java para Open Source, por Luca, 09/05/2007, no GUJ Fórum.
- Java EE 6 e JavaFX Compiler, artigo de 22 de julho neste blog que cita a questão com o projeto Apache Harmony.
- Java livre e open source, outro artigo deste blog, na data que marcou o lançamento dos primeiros componentes do Java como código aberto sob licença de software livre GPL v2, em 13/11/2006.
- Projeto JCK 6a em java.net: lançamento dos fontes do Java Compatibility Kit (JCK) 6a como somente-leitura, apenas para avaliação e compreensão pela comunidade Java.
- Java SE TCK weblog (em inglês).
Na minha opinião, com essa medida, a Sun dá um passo para frente e dois passos para trás. Em outras palavras, não ajudou a comunidade em absolutamente nada.
Quem acompanha as votações de JSRs importantes percebe que alguns participantes acabam reprovando JSRs não em por razões técnicas, mas por receio de que a Sun imponha restrições sobre a especificação e/ou implementação (em termos de licensa e tudo mais). E, convenhamos, é exatamente isso o que está acontecendo com o TCK.
Pelo visto, a richa entre a Apache e a Sun vai ficar ainda pior, visto que ela efetivamente começou justamente por essa dificuldade em se conseguir o TCK para se testar a compatibilidade do Harmony com o padrão Java. É como se a Sun falasse para a Apache: disistam do Harmony, pq ele nunca será considerado Java.
Sinceramente, estou com medo do que poderá acontecer como resultado desse fato! 🙁
Abraço!
Não sei. Já é uma melhora passar a licenciamento do JCK de totalmente restrito a aberto para licenciados sob GPL e participantes do OpenJDK.
O ponto crucial da incompatibilidade com o projeto Apache Harmany está no fato da licença Apache v2 (Harmony) ser mais permissiva que a GPL v2 (OpenJDK). A licença Apache não exige que inovações implementadas sobre o código permaneçam abertas.
Entendo também o lado da Sun, já que essa tolerância adicional da licença Apache pode, em tese, permitir o surgimento de alguma implementação proprietária a partir do código livre.
Garantir o JCK licenciado sob GPL pode ainda não resolver a pendência com a Apache, mas pelo menos já permite algo que muita gente sente falta: o surgimento de distribuições GNU/Linux (sob licença GPL) que incluam por padrão uma implementação Java totalmente compatível com Java SE JRE/JDK.
Atualmente, ótimas distribuições Linux como Ubuntu (baseada em Debian/GNU) vêm só com o GNU Classpath e GCJ, muito incompletos, exigindo que se baixe manualmente o Sun JDK para Linux para qualquer uso decente de Java no Linux.
De qualquer forma, no blog de Rich Green (vice-presidente de software da Sun), ele parece mostrar que está sensível à situação com a Apache. Vejamos que melhorias a situação têm no futuro.