Le blog de L'ami S'ami

MAJ 13/11 - 20h00 :

Le 13 Novembre restera un jour à marquer d'une pierre blanche pour toute la communauté Java, le webcast officiel de Sun est là pour nous le rappeler. C'est la première fois que je découvrais Rich Green aux côtés de Jonathan Schwartz. Que dire sinon que ces deux managers dégagent une grande sérénité (au delà d'une certaine complicité). Et à l'heure où Java est libéré, il est important de souligner que le temple restait (encore) bien gardé.

Tout développeur Java doit se sentir aujourd'hui un peu fier au delà des enjeux (et des pièges) qui attendent cette ouverture.

-----

Posté le 13/11 - 8h30 :

C’est désormais officiel (autre article sur news.com), Sun choisit finalement la licence GPL pour distribuer Java, l’une des plateformes les plus populaires du moment. Mais dans le même temps, la firme conserve la licence actuelle (CDDL) qui sera proposée en double choix à l’utilisateur. Les briques logicielles concernées par ce changement sont :
- J2ME (implique CDC/CLDC)
- Java (J2SE/J2EE)
- JVM
- Glassfish (le serveur d’application de Sun)

Ne sont pas concernés par cette licence :
- le TCK (Test Compatibility Kit) permettant de certifier les produits avec le label « Java »

Cette décision, si elle ne constitue pas en soi une réelle surprise (Sun a toujours dit qu’il souhaitait envoyer un message fort à la communauté Open Source) risquent inévitablement de susciter de nombreuses interrogations. Celles tout d’abord liées aux conditions exactes de la clause dite « classpath » adossée aux termes du nouveau contrat de Sun. Les détails de la classpath exception tels que stipulés par la licence GPL sont les suivants :

Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.
As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

En d’autres termes, tout industriel ou particulier peut, s’il le désire, lier (au sens « link » binaire) ses développements à un produit GPL sans pour autant subir la viralité de la licence.
La plupart des sociétés développant aujourd’hui en Java n’auront donc pas à ouvrir le code source de leurs applications.

En revanche, lorsqu’un composant impliqué par la licence GPL est modifié, il doit être distribué sous licence GPL. Cela concerne notamment la machine virtuelle mais aussi le JDK et J2ME.

Concrètement, des éditeurs tels que IBM ou BEA devront, s’ils souhaitent étendre ou modifier l’implémentation de la JVM fournie par Sun, proposer leur produit en GPL.

A noter toutefois que ces nouvelles règles n’interdisent théoriquement pas de développer des implémentations J2SE ou des JVM totalement exotiques (suivez mon regard vers MS ;-)). En revanche, ces dernières ne disposeront pas du label et de l’appellation d’origine contrôlée (par Sun) Java ™. C’est là où l’initiative du constructeur californien prend tout son sens. A défaut de bénéficier des rentes induises par la vente de produits Java, Sun protège l’utilisation du label en faisant payer des royalties pour la certification. L’outil permettant d’adosser ce label n’étant autre que le Tck, qui, on l’aura noté au passage, ne fait pas partie du nouveau système de licence GPL, CQFD.

Autre conséquence de poids dans cette annonce, le mode de gestion du projet Open Source en lui-même. Celui-ci reste sous le giron de Sun et sera vraisemblablement hébergé sur le portail dev.java.net. En théorie, cela signifie que toute personne, physique ou morale peut disposer de droits de commit sur le code source de Java. Dans la pratique, encore faut-il que l’éditeur le lui autorise, directement ou indirectement via un système de délégation (un commiter pourra-t-il donner les droits de commit à un tiers ?).

Bref, on imagine bien les nombreux travers que peuvent engendrer un tel projet. A l’inverse d’outils moins visibles (Hibernate, Eclipse, etc ..), Java représente plus de 5 millions de lignes de code. IBM en premier lieu mais aussi Oracle, (Microsoft, qui sait ?) ou d’autres éditeurs, pourraient prétendre à commiter sur la foie d’arguments recevables sur simplement une classe ou tout un pan des API Java. Or seul le leader du projet, (le maintainer) en l’occurrence Sun, peut-il donner son accord.

Ce qui emmène inévitablement à se poser les questions suivantes : comment seront choisit les commiters ? Quid des propositions contradictoires ? Qui décidera des release ?

Il y a fort à parier que les points de discorde tourneront autour de ces sujets. On l’a déjà vu par le passé (et encore aujourd’hui) avec le noyau Linux, source perpétuel de conflits. Là où Linux dispose de leader reconnus (Torvals ou Cox), Sun ne pourra s’abriter que sur un étendard marketing, qui n’est autre que sa marque. La communauté demandera des comptes et des arguments techniques, il faudra que la firme y réponde. A ce jeu, les sociétés ou les communautés de développeurs ayant les meilleurs atouts techniques auront les meilleures armes.

Dans cette future bataille qui s’annonce, difficile de ne pas penser aux dégâts collatéraux sur le JCP (Java Community Process). Cet organe essentiellement destiné à contrôler de manière collective le futur de Java au travers de spécifications, devra s’assurer que le code du J2SE (mais aussi de J2ME et J2EE) respecte les règles édictées par le JCP. Or, à priori, tout commiter tiers peut être amené à modifier le code source de Java. On voit mal comment Sun va pouvoir garantir (et argumenter si ce n’est pas le cas) que seuls les membres du JCP sont en mesure de modifier le code de Java.

Dans un tel contexte, l’ouverture de Java peut déboucher sur un vrai micmac technico-politico-stratégique dans lequel Sun tentera de conserver les grands pouvoirs. D’autant plus que Java n’est pas Eclipse, Java est la base de la base, le Framework sans qui rien n’est possible. Il suscitera inévitablement des convoitises.

Difficile donc aujourd’hui d’évaluer réellement les bénéfices d’une telle décision même si pour la communauté Linux, ils semblent clairs : Java peut être désormais utilisé et distribué librement avec Linux.

Du côté des éditeurs de machines virtuelles à destination des mobiles (Nokia, Ericsson ou Motorola), les effets sont immédiats. Ces derniers pourront librement développer et diffuser des implémentations de JVM mobiles sans contrepartie financière. Sauf s'ils souhaitent disposer de la garantie et du label Java.

Quant aux entreprises et intégrateurs pour qui la licence Java n’a jamais été un frein à son adoption, la situation est plus confuse. Ceux-ci disposaient en Sun et le JCP d’une garantie quasi formelle de la cohérence de Java. L’ouvrir au monde entier, c’est aussi risquer de jouer au jeu des alliances stratégiques mais dangereuses. Pour assurer équitablement son rôle d’arbitre, Sun devra éviter de tomber dans le piège du clientélisme qui consiste à orienter Java vers le plus offrant plutôt que le plus méritant.

Car à l’horizon se profile une destinée tout autre que celle prédite par la firme, une destinée qui pourrait bien passer par un Fork du code source de la plateforme, lequel sonnerait le glas d’un des langages les plus populaires de sa génération.

Sun ne peut l’oublier. La communauté Open Source est une communauté exigeante dont les buts ne sont pas toujours ceux affichés par les grandes firmes commerciales. La récente intrusion du clan Hibernate dans les spécifications J2EE 1.5 est là pour nous le rappeler.

Je prends le risque de prédire ce funeste destin si Sun ne respecte pas ses engagements. En attendant, les dés sont jetés, alors que la fête commence …

Ps : Notons au passage que Mono va subir inévitablement cette annonce car elle réduit de facto sa pertinence, en tout cas d'un point de vue licence.

Liens annexes

Joshua Marinacci's Blog (employé Sun) : Il pense également que le fork est le danger principal : "(...) The GPL has always provided an option to fork just in case someone takes the code in a bad direction (...) "

Le blog d'Alexis, autre employé de Sun. Une analyse toujours pertinente.