Quelle est l'idée générale présidant à cette décision de passer Java en Open Source ?
Nous pensons qu'il est possible de faire croître une société en augmentant le marché, et pas en tuant la compétition. L'annonce du passage de l'intégralité de la plate-forme Java sous licence GPL a justement pour but de faire croître le marché. Nous sommes en train d'inventer un nouveau Sun. Les gens achètent des logiciels, mais en réalité, ce n'est pas ce qu'ils veulent. Ce qu'ils veulent, c'est la valeur qu'un logiciel peut délivrer. Voilà le marché que je suis en train de préparer. Regardez Solaris : la plupart des gens achetaient en réalité un flux de mises à jour, un service de support, de la documentation, l'accès à un catalogue de formations... Ce que nous leur proposons aujourd'hui, c'est d'acheter ce qu'ils désirent vraiment. Et le paradoxe, c'est que cela génère plus de revenus. Il y a plus de six millions de licences d'OpenSolaris en circulation, et beaucoup sur du matériel d'autres constructeurs.
Quel est le calendrier de ce passage sous GPL ?
Dès lundi, le compilateur, le système d'aide et la machine virtuelle HotSpot, notamment, passent en Open Souce. Côté Java EE, [le serveur d'applications] GlassFish, qui était déjà en Open Source, passera sous GPL aussi. Dans les semaines et mois à venir, ce seront les 6 millions de lignes de code de la plate-forme Java SE qui seront sous GPL. Et d'ici six mois, nous allons migrer notre système de code source vers un CVS [système de contrôle de versions] public. Les évolutions seront décidées au sein de la communauté OpenJDK.
L'aspect viral de la GPL peut faire peur à des entreprises clientes, surtout si c'est exploité par des concurrents. Le FUD (Fear, Uncertainty and Doubt - peur, incertitude et doute) guette...
On propose un système de licence triple, et on n'utilise que des licences déjà utilisées, qu'il s'agisse de la GPL, de notre licence commerciale ou de la GPL avec exception Classpath. Cette dernière exonère un développeur de l'obligation de mettre sous GPL du code développé au-dessus d'un code en GPL. Donc je crois que si quelqu'un essaie de générer du FUD, on lui rira au nez.
Pourquoi avoir choisi la GPL, plutôt que, par exemple, votre licence CDDL ?
Je n'ai pas de religion envers telle ou telle licence. Nous utilisons des licences GPL, LGPL, Apache... Ma philosophie est de fournir la bonne licence pour la bonne communauté. La CDDL est géniale pour la communauté OpenSolaris. Elle offre beaucoup d'innovations, en termes de correction de bugs, de portage...
Quel modèle de gouvernance allez-vous mettre en place pour OpenJDK ?
Nous avons beaucoup réfléchi à cela, recueilli des conseils. Quand vous examinez la façon dont cela fonctionne dans nombre de communautés, vous pouvez constater que n'importe qui peut en retirer quelque chose, mais qu'il est très difficile d'y ajouter quelque chose, seuls les membres les plus qualifiés peuvent le faire. Nous nous dirigeons vers ce modèle.
Qui pourra être « committer » (apte à soumettre du code) ? Comment le deviendra-t-on ?
Nous n'avons pas encore fixé exactement le modèle. Les concepteurs de Java sont des gens très talentueux, et seront les premiers committers. Ils accueilleront des gens en-dehors de Sun, au fur et à mesure. Généralement, cela se décide au fil du temps : il y a une liste de diffusion, et les compétences finissent par être reconnues. C'est un processus qui devrait prendre plusieurs années, comme pour tous les processus de ce type.
Cette annonce est-elle davantage destinée à la communauté des développeurs Java ou à la communauté Open Source ?
Les deux. Il s'agit d'une part d'assurer la plus grande compatibilité possible, ce qui est important pour les développeurs. Par ailleurs, nous voulons accroître le marché en rendant Java acceptable pour les développeurs de logiciels libres.
Qu'est-ce que cette annonce change concrètement ? La DLJ (Ditro License for Java), qui permet de redistribuer le JDK (Java Development Kit) avec les distributions Linux, n'était-elle pas suffisante ?
En apparence, je suis d'accord, beaucoup penseront que cela ne change pas grand chose. La DLJ, sur laquelle j'ai travaillé, permet en effet à Debian ou Fedora de proposer le JDK. Mais la GPL ouvre la porte en grand à la possibilité d'inclure directement le JDK, cela nous ouvre un nouveau marché immense. C'est bon pour les éditeurs Linux, pour les éditeurs d'applications, et pour les utilisateurs. Un plus gros marché signifie davantage de choix, de compétition et de valeur.
Qui sera impacté ?
Les développeurs, qui peuvent dès maintenant rejoindre la communauté OpenJDK. Pour ceux qui ne font qu'utiliser le JDK, les changements interviendront à terme, avec notamment une baisse des coûts.
Que devient le JCP (Java Community Process) dans ce schéma ?
Le JCP est un organisme de standardisation, chargé de définir ce que Java veut dire. Cela n'a rien à voir avec les différentes communautés, qu'il s'agisse de Glassfish, Harmony ou maintenant OpenJDK. Au contraire, toutes les trois vous diront que pour que la compatibilité soit préservée, il faut un organisme de standardisation.
La suite de tests de compatibilité TCK (Technology compatibility kit) est-elle concernée par le passage en Open Source ?
Pas initialement, non. Nous nous interrogeons sérieusement à ce sujet. Elle reste en tout cas gratuite pour les organismes à but non lucratif.
Cette multiplication des communautés Java n'est-elle pas préjudiciable ?
Non, il y a déjà de la place pour quatre implémentations de Java EE : JBoss, Jonas, Geronimo et Glassfish. Côté Java SE, Geir Magnusson [le leader du projet Harmony chez Apache] est un bon ami. Je m'entends bien aussi avec les gens de Classpath. J'attends beaucoup de notre collaboration. Je crois que la diversité développe et enrichit le marché.
Pourquoi avoir pris cette décision maintenant ?
C'est l'aboutissement d'un long processus. Je suis arrivé chez Sun en 2000, et les dirigeants parlaient déjà de passer Java en Open Source. Cela a donc pris 6 ans !
Quels obstacles a-t-il fallu abattre ?
Je ne parlerais pas d'obstacles, il s'agissait plutôt de prendre ses responsabilités. La décision que nous prenons sera irrévocable, or elle impacte 10 millions de développeurs. Ce n'est donc pas quelque chose qu'on fait à la légère...
Vous qui tiriez des revenus des licences Java dans les appareils mobiles, par exemple, vous risquez de voir cette source de revenus s'évanouir...
Tout le monde ne souhaite pas travailler en mode ouvert. Nous pensons que la plupart choisiront de continuer avec la licence commerciale classique. Il ne devrait pas y avoir de changement conséquent, plutôt une lente érosion.
Les éditeurs de produits Java ne sont donc pas tenus de se mettre à l'Open Source...
Pour les gens qui voudront que rien ne change, rien ne changera !
Après Java, avez-vous toujours l'intention de passer votre portefeuille logiciel en Open Source ?
Oh oui, il reste du travail. Nous avons déjà mis nos technologies d'annuaire et de gestion des identités en Open Source. Pour Java, ce sera achevé d'ici six mois. Puis il y aura les logiciels hérités de Storagetek, de Seebeyond... Il y a encore beaucoup à faire, je ne compte pas prendre ma retraite de si tôt !
Le blog de Simon Phipps : www.webmink.net/minkblog.htm
Initialement, en 1991, Sun Microsystems lance un projet nommé Green dont l'objectif est de créer un langage de programmation léger et portable pour l'électronique grand public (télécommandes, fonctionnement d'appareils électroménagers, appareils portables...). James Gosling et son équipe créent alors un langage orienté objet inspiré du C++ dénommé Oak (le chêne). Le projet serait tombé aux oubliettes sans Bill Joy, cofondateur de Sun, qui estime nécessaire de promouvoir un langage portable et léger à un moment où le Web décolle, avec ses environnements matériels hétérogènes et ses débits de données faibles.
En mai 1995, Sun baptise son langage Java, "café" en langage familier américain. Il s'agit d'un langage orienté objet qui s'exécute sur un environnement d'exécution (runtime), le JRE (Java runtime environment). Ce dernier est constitué d'une JVM (la machine virtuelle Java), qui interprète le code et interagit avec le système d'exploitation, et d'une bibliothèque de composants.
La déclinaison en trois plates-formes d'exécution a lieu en 1999. En plus de la version existante, dite édition standard (J2SE), qui définit le JDK (Java Development Kit), la plate-forme d'exécution, Sun crée alors J2EE (Java 2 Enterprise Edition), une déclinaison des concepts pour la création d'applications d'entreprise, qui introduit la notion de composants Javabeans (les EJB). La déclinaison J2ME concerne quant à elle les terminaux mobiles.
Les spécifications sont élaborées par le JCP (Java Community Process), une organisation mise sur pied par Sun. Contrôlé par le créateur de Java, le JCP est néanmoins ouvert aux autres acteurs importants du marché Java, qui votent les évolutions de la plate-forme, proposées sous forme de JSR (Java specification requests).
Aujourd'hui, le JCP compte environ 700 participants (indépendants ou affiliés à une entreprise). Il n'est aucunement impacté par l'annonce de la mise en Open Source de Java, qui concerne le langage et les plates-formes, non les spécifications.
Sun reste par ailleurs propriétaire de la marque Java et, pour avoir le droit de bénéficier de cette marque, un produit doit passer le TCK (Technology compatibility kit), une série de tests de compatibilité.
A qui cette annonce est-elle destinée à votre avis ?
La première cible est la communauté Open Source, notamment Linux, d'où le choix de la GPL plutôt que la CDDL, par exemple [licence d'OpenSolaris, NDLR]. Cela correspond à une envie de Sun de voir Java intégré plus étroitement aux distributions Linux. On devrait à terme arriver à des distributions dédiées à Java, alors qu'aujourd'hui, la machine virtuelle Java n'est pas optimisée pour Linux. Pour des applications serveurs, on conseille même plutôt celle d'IBM que celle de Sun, qui souffre d'instabilité chronique. La GPL permettra aux contributeurs d'optimiser la JVM pour cette plate-forme. Peut-être même arrivera-t-on à des distributions spécialisées, avec une JVM optimisée, voire intégrée au noyau, comme on trouve des distributions orientées sécurité, bureautique, etc.
La deuxième cible, ce sont les opérateurs télécoms. Ils ont un grand nombre de plates-formes pour lesquelles il faut construire des JVM. Nokia et Motorola ont des projets dans ce domaine. L'annonce devrait d'ailleurs couper l'herbe sous le pied de Motorola, qui veut établir une communauté autour de Java ME [sous licence Apache, NDLR].
Quels avantages cela présente-t-il pour les développeurs ?
La JVM de Sun souffre depuis le début d'un support assez déficient. La gestion de bugs soumise à un système de vote, cela a l'air bien, mais dans les faits... On aimerait pouvoir payer un service de support, mais ce n'est pas possible. Une ouverture permettra de corriger plus rapidement les bugs, sachant qu'il y en a qui sont signalés depuis cinq ou six ans. Cela devrait donc améliorer la qualité générale. Sinon, pour le travail du développeur, cela ne devrait pas changer grand-chose, tout ce qu'on utilise est public depuis longtemps. Il n'y aura pas de grande révolution au quotidien.
Le passage en GPL ne risque-t-il pas de susciter des craintes chez vos clients ?
Pour la plupart des développements en Java, une licence binaire est suffisante. Quant aux développements internes aux entreprises, ils ne sont jamais concernés par le côté viral de la GPL. Pour les éditeurs, il faudra réfléchir davantage sur le choix de la licence. Mais le recours à l'exception Classpath est très bien, cela règle le cas de 90% des applications Java, puisque globalement, les applications Java sont clientes de la JVM. Il ne restera que quelques cas spécifiques d'applications intégrées à la JVM.
Ce passage en Open Source présente-t-il des risques sur l'intégrité du code ? Verra-t-on des bifurcations (fork) ?
Le caractère viral de la GPL protège plutôt bien, je crois, contre les risques de fork. Et puis qui pourrait prendre sur soi l'initiative de forker un projet aussi gigantesque ? A part IBM, peut-être, personne n'y aurait vraiment intérêt. Cela ne devrait pas arriver. Sauf bien sûr si Sun fait l'erreur de ne pas mettre en place une gouvernance de projet satisfaisante.
Comptez-vous adhérer à OpenJDK ?
Je verrai comment cela s'organise. Etant à titre personnel très intéressé par les évolutions du langage, s'il y a moyen d'adhérer à une communauté qui influe sur ces évolutions, j'y adhérerai probablement.
Sun pouvait-il aller plus loin ?
Il reste des doutes sur la façon dont Sun va gérer le projet. Il reste propriétaire de la marque, ce qui peut poser des problèmes. On se souvient que JBoss a interdit à Geronimo d'utiliser des bibliothèques, libres mais nommées JBoss, en jouant sur la marque déposée. Sun conserve donc des arguments juridiques pour interdire potentiellement l'utilisation de Java.
Et le fait que le JCP reste en-dehors de cette annonce ?
Il y a des critiques assez fortes sur le pilotage du JCP, mais je ne les partage pas. Sun a réussi à maintenir une cohésion avec le JCP. Même s'il n'est pas parfait, il est relativement transparent, et finalement plus efficace que des organismes de ce type, chargés de définir des normes ? Certains auraient aimé que le JCP passe sous une gouvernance de type Apache ou Eclipse, mais je pense que cela n'est pas souhaitable. Apache et Eclipse font des produits, pas des normes. Et quand vous regardez les organismes qui définissent des normes, vous avez le modèle type OMG, usine à gaz, avec un important retard de phase, ou OpenSOA, qui n'est pas très transparent, et livre des spécifications toutes faites. Le JCP ne fonctionne pas si mal, finalement. On peut même dire qu'il a accompli un boulot plutôt spectaculaire depuis dix ans. Il y a des ratés (la partie persistance, par exemple), mais surtout des succès.
Qu'est-ce qui est concerné exactement par cette annonce ?
Dans un premier temps, il s'agit d'une grande partie de Java SE, le socle d'exécution des applications Java. En premier lieu le compilateur à la volée et le système d'aide. Mais tout sera concerné à terme. De même, la partie Java EE, déjà Open Source au travers du projet Glassfish, passera sous GPL.
Qu'attend Sun de ce mouvement ?
Java ayant atteint une certaine maturité, il ne lui restait plus guère qu'une frontière à franchir, celle de Linux. Il y a encore une énorme marge pour optimiser le fonctionnement de Java sur Linux, et le passage en GPL permet d'envisager des développements intégrés au noyau de Linux. Par ailleurs, cela évitera certaines polémiques, comme celle concernant l'utilisation du langage pour la version 2 de la suite bureautique libre OpenOffice.
Pourquoi cette licence et pas une autre ?
La GPL est la licence adoptée par la communauté Linux, première visée par l'annonce.
Pourquoi la licence « linux-friendly » JDL n'était-elle pas suffisante ?
La JDL permettait aux éditeurs de distributions Linux de redistribuer le JDK, pas de l'intégrer.
Que pourront faire les utilisateurs de Java qu'ils ne pouvaient pas faire avant ?
La principale différence sera la possibilité donnée aux connaisseurs de participer aux évolutions du JDK en adhérant à la communauté OpenJDK.
Sun exprimait il y a peu sa peur d'une divergence (fork) du code, qu'est-ce qui a changé ?
La plus grande menace a été écartée avec l'accord amiable avec Microsoft, et Sun estime que le nombre de terminaux capables d'exécuter du Java en circulation aujourd'hui est la meilleure garantie contre une tentative de bifurcation du code : le risque d'incompatibilité serait trop élevé. En outre, Sun reste propriétaire de la marque Java.
Qu'est-ce que l'exception Classpath ?
Il s'agit d'une clause, mise au point par la Free Software Foundation, annulant le caractère viral de la GPL lorsqu'il s'agit de modules de code indépendants. En l'occurrence, cela permettra de distribuer un programme écrit en Java sous licence propriétaire, quand bien même il s'exécutera au-dessus d'un environnement en GPL.
Que vont devenir les royalties qu'on devait payer à Sun pour mettre la JVM dans des terminaux ?
Sun espère bien continuer de toucher cette manne dans la mesure où la licence commerciale reste en place et où les fabricants de terminaux n'auront pas forcément le désir de passer sous GPL.
Que devient le JCP, l'organisme qui définit les spécifications de Java ?
Il n'est pas du tout impacté par cette annonce. Le JCP travaille sur les spécifications, tandis que les différentes communautés comme celle que Sun met en place, OpenJDK, se préoccupe du code.
Le nom Java devient-il libre ?
Non, Sun en garde le contrôle. Et pour bénéficier de ce nom, un programme devra toujours passer avec succès la batterie de tests de compatibilité (le TCK), qui reste lui aussi sous licence propriétaire, et payant (pour les sociétés à but lucratif).
