|
|
Simon Phipps
Chief Open Source Officer
Sun Microsystems |
|
Simon Phipps
"Passer Java sous licence GPL nous ouvre le marché des distributions Linux"
Le célèbre langage devient libre. La décision de Sun concerne toutes les briques de l'infrastructure, jusqu'aux spécifications des plates-formes applicatives Java EE, Java ME et Java SE.
13/11/2006 |
|
|
|
JDN
Développeurs. Les rumeurs vont bon train sur la licence choisie par Sun pour Java. Qu'en est-il ?
Simon Phipps. La question actuelle avec Java est de savoir comment agrandir le marché existant, qui est déjà l'un des plus importants au monde sur le front des technologies non Microsoft.
Notre réponse a été de voir quelles étaient les perspectives que nous n'avions toujours pas explorées, et il se trouve que la plate-forme Java n'est pas disponible sur beaucoup de distributions Linux, pour la simple raison que Java n'est pas Open Source. C'est pourquoi nous avons décidé de placer la totalité de la plate-forme Java - SE, EE et ME - sous licence GPL.
Pourquoi cette licence plutôt qu'une autre ?
Nous pensons que c'est la meilleure manière de résoudre tous les problèmes relatifs aux distributions Linux. Red Hat a ainsi déjà annoncé qu'il ajouterait certainement Java à Fedora. Debian devrait probablement suivre ce chemin, vu qu'Ubuntu a déjà annoncé qu'il ajouterait Java. De cette manière, nous réalisons d'un coup la plus grosse croissance du marché Java, ce qui bénéficiera à tout le monde : les franchisés, les éditeurs qui auront plus de clients, les clients actuels qui obtiendront un produit plus riche... Nous utilisons ainsi exactement la licence que la communauté Java nous a demandée.
Un exemple flagrant de bénéfice vient du Vénézuela, qui a passé un décret stipulant que ses développements gouvernementaux devaient n'utiliser que des logiciels sous GPL. Ils ne pouvaient jusqu'à présent pas utiliser Java, maintenant ils le peuvent.
C'est moi qui ai mis en place la police de licences Open Source de Sun. Pour OpenSolaris, il nous fallait une licence proche de celle de Mozilla. Nous l'avons reprise et corrigée dans CDDL, et elle fonctionne très bien pour Open Solaris depuis 18 mois. OpenSPARC utilise déjà la GPL. Jini est désormais sous licence Apache. Tout cela pour dire que nous ne sommes pas extrémistes à propos des licences. De fait, pour Java, la licence la plus adéquate pour grossir le marché s'est trouvée être la GPL.
Dans les détails, qu'est-ce que cela donnera ?
|
|
Nous ouvrons tout : Java SE, EE, ME, la JVM, le compilateur, tout" |
|
Dès lundi 13 novembre [NDLR : l'interview a été réalisée le jeudi 9 novembre], nous placerons sous GPL Java CDC, le profil Java ME - tout le code source, avec CLDC dans les semaines suivantes. Lundi verra également l'ouverture de Hotspot VM, de javac et de javahelp.
Nous avions ouvert notre implémentation de référence de Java EE l'année dernière, sous le nom de Glassfish, et nous allons passer en licence double pour Glassfish : CDDL et GPL. Enfin, l'ensemble du code de Java SE sera à terme placé sous GPL, avec l'Exception Classpath. À terme, l'ensemble du code source Java sera ouvert, ce qui inclut les JVM, toutes les plates-formes, tout. Enfin, les Core Developpers du JDK disposeront de projets Netbeans pour javac, Hotspot et autres...
Java SE est un produit imposant, plus de 6 millions de lignes de code. Nous le maintenions en interne avec un logiciel de versionnage non Open Source. Nous allons donc transférer tout le code sous Mercurial, avec une période de transition sous Subversion en mode lecture seule, ce qui nous occupera sans doute pour les 6 prochains mois. Durant cette période, nous aurons probablement d'autres surprises à annoncer.
Pouvez-vous nous préciser en quoi consiste l'exception Classpath ?
GNU Classpath est un projet de la FSF, qui utilise une forme de la GPL modifiée par Richard Stallman, ce qui permet à des applications non GPL d'utiliser cette implémentation. Nous utilisons cette licence. C'est la meilleure pour nous actuellement.
D'une certaine manière, utiliser la GPL semble relativement évident. Pourquoi avoir mis tout ce temps pour se décider ?
Simplement parce que c'est une décision irréversible. Nous avons des millions de développeurs, plus encore d'utilisateurs, il s'agit d'une énorme responsabilité. Il ne nous fallait pas prendre une décision à la légère, car si elle s'averrait mauvaise, nous n'aurions rien pu changer par la suite. Nous pensons ouvrir Java exactement au bon moment, ni trop tôt car nous aurions pu faire un faux pas, ni trop tard car d'autres auraient pu nous remplacer sur le marché visé, à savoir Linux.
Comment cela affectera-t-il les développeurs ?
Nous allons mettre en place des règles de gouvernance du code, qui s'assureront que seules les personnes indubitablement capables de participer à l'évolution de Java pourront intervenir sur le langage, ce qui maintiendra la qualité du code, principe cher au mouvement Open Source. De fait, les premiers temps, les participants seront majoritairement des employés de Sun, mais d'autres seront acceptés bien évidemment, à commencer par les personnalités du monde Java.
|
|
La communauté partira de Java 6, et travaillera pour Java 7" |
|
Pour les développeurs qui travaillent avec Java au quotidien, je pense que rien ne changera. Il y a trois sortes de personnes potentiellement affectées : les Core Developpers de Java, environ 400 personnes, qui le seront assurément car ils travaillent sur le JDK ; les développeurs Java, environ 4 millions, qui le seront peu mais seront intéressés par ce que nous offrons aux Core Developpeurs et par ce qui arrive au JDK, notamment les innovations ; et les utilisateurs Java, potentiellement 4 milliards, qui ne sentiront rien.
De son côté, le JCP ne sera pas affecté, il continuera de standardiser la plate-forme, en continuant d'améliorer son processus.
Comment voyez-vous se dérouler la période de transition entre les deux versions de Java, fermée et ouverte ?
Il n'y aura probablement pas de bouleversement pendant 1 à 3 ans, le temps que les participants se familiarisent avec le code, le digèrent et y prennent effectivement part. Je pense qu'on ne verra pas de modification avant le JDK 7. La communauté recevra le JDK 6 et devra partir de là.
Lors de notre entretien avec James Gosling, il nous avait dit vouloir, par la licence, assurer la qualité du test et de la fiabilité de Java. De même, il souhaitait une licence qui protège le nom Java. Quelles assurances avez-vous prises à ce propos ?
En utilisant la GPL, quiconque chercherait à introduire du code malicieux dans la plate-forme devrait le faire à visage découvert, ce qui nous fait croire que personne ne le fera, car il serait rapidement découvert. Par ailleurs, les règles de gouvernance, dont je parlais auparavant, s'assurent que le seul code qui soit introduit dans Java le soit avec le soutien de la communauté. Nous ouvrons par ailleurs une grande partie de tests unitaires, que nous devons préparer pour être utilisés par la communauté, ce qui prendra également du temps.
Pour ce qui est du nom, nous ne modifions pas les règles de marque : Java reste une marque déposée, tout comme le logo avec la tasse fumante, et vous ne pouvez appeler votre implémentation "Java" que si celle-ci passe les tests du Technology Compatibility Kit (TCK). Cela nous évitera certainement la récente débâcle entre Debian et Firefox : personne ne peut utiliser le nom Java ou le logo sous une implémentation différente. Si l'implémentation passe le TCK, alors elle peut utiliser le logo.
|
|
Nous conservons le nom et le logo Java" |
|
Quels sont vos plans en cas de fork ?
En soi, un fork [ndlr : projet émanant d'un autre] ne serait pas mauvais en lui même ; il le serait s'il produisait une implémentation incompatible. Je m'attends à ce qu'il y ait des forks, c'est-à-dire une reprise indépendante du code, mais je n'en vois pas l'intérêt.
Je pense que ceux qui prendront l'initiative d'améliorer Java préféreront travailler sur le code Java plutôt que sur leur propre fork. Ils se refuseraient le marché Java, et personne de sérieux ne ferait cela. Nous ne nous en inquiétons pas trop, car nous pensons que tout le monde verra l'intérêt de travailler au sein de la communauté.
De fait, si vous avez besoin d'un ramasse-miettes pour votre projet GPL, vous pouvez prendre celui de Java et l'adapter. Vous pouvez également adapter la plate-forme à votre usage, mais elle ne pourra pas utiliser le nom.
Que reste-t-il à ouvrir chez Sun, maintenant que Java, Netbeans et d'autres projets sont disponibles ?
Comme on dit, je fais déjà tourner beaucoup d'assiettes, entre JINI, OpenOffice, OpenSolaris, et nos contributions à Mozilla, Debian et d'autres projets. Après l'ajout de l'assiette Java, je me focaliserai sur l'ouverture de nos middlewares, dont nous avons déjà ouvert OpenDS et OpenSSO. À terme, nous comptons bien ouvrir toutes nos offres logicielles, et le hardware le sera autant que possible. Nous nous préparons aux promesses à venir, en somme.
Et quel est l'avenir de votre relation avec Eclipse ?
Elle sera équivalente avec celle qui existera entre Sun et la GNU Classpath : chacun a son produit, et je ne vois aucun problème à avoir une concurrence sur la qualité. Il reste bien évidemment des progrès à faire en termes de maturité dans nos rapports avec ces communautés, mais autrement, chacun tire l'autre vers le haut, et le bénéfice revient à tous.
Sans Netbeans, Eclipse n'aurait pas besoin d'innover et vice-versa. Pour l'heure, j'estime que Netbeans tient le haut du pavé, mais je m'attends à ce qu'Eclipse réagisse - ne serait-ce que par fierté - et sorte une version dépassant les espérances, ce à quoi Netbeans devra répondre... Je m'attends donc à de la compétition, de la collaboration sur certains points, mais aucun rapprochement sous une seule égide.
|
|
Propos recueillis par Xavier Borderie, JDN Développeurs |
|