La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.
Evènements de notre communauté en France et à l’étranger
- Larry vs. Larry (par Alexandre Dutra)
- Java 8 – Lambda Project : itération 1 (par François Sarradin)
- Lancement de BuildHive par Cloudbees (par Stéphane Moreau)
Evènements de notre communauté en France et à l’étranger
Larry vs. Larry
Le procès opposant Oracle à Google s’est enfin ouvert le 15 avril dernier, et traverse actuellement une période critique.
Si vous avez suivi le feuilleton, vous savez déjà que le procès a été divisé en trois « phases »:
- la phase 1 s’est jouée jusqu’au 7 mai et portait sur les infractions aux droits d’auteur (copyright);
- la phase 2 se joue en ce moment et porte sur les infractions aux brevets déposés (patents);
- la phase 3 n’a pas encore de date arrêtée, et portera sur les dommages et intérêts éventuels.
Revenons d’abord sur la phase 1. Le débat a tourné autour d’une poignée de fichiers qu’Oracle accuse Google d’avoir utilisés illégalement. Ces fichiers se divisent en 3 catégories:
- 37 APIs Java situées sous les packages java.* et javax.* (détails ici);
- Une poignée de classes sous le package sun.*, qui auraient été décompilées (détails ici);
- La désormais célèbre méthode « rangeCheck » de java.util.Arrays qui se serait retrouvée comme par magie dans les classes TimSort.java et ComparableTimSort.java d’Android.
Il va de soi que le nerf de la guerre concernait avant tout les 37 APIs en jeu, le reste étant dérisoire. Les 9 lignes de la méthode « rangeCheck » sont d’ailleurs si triviales que même le juge Alsup, révélant à la surprise générale ses qualités de développeur, a estimé qu’elles étaient à la portée de n’importe quel étudiant.
Mais revenons aux APIs: il s’en est suivi un débat passionnant, bien que parfois surréaliste, sur la « copyrightabilité » d’une API.
Un certain émoi s’est en effet créé aussitôt dans la communauté informatique, certains ici et là s’inquiétant qu’une API protégée par le droit d’auteur ne soit un frein au logiciel libre et que si Oracle venait à emporter ce procès, ce serait carrément la fin de nombre de langages de programmation.
Or Florian Mueller, qui suit le procès depuis le début de la plainte d’Oracle, a calmé les esprits en rappelant que ce n’est pas la première fois qu’une API est portée devant les tribunaux. Certes, la pratique dans l’industrie informatique tend vers le laxisme: les infractions au droit d’auteur, notamment sur les APIs, sont monnaie courante, au mieux réglées à l’amiable, le plus souvent passées sous silence. Mais cela ne change en rien le fait légal: qu’une API soit « open source » ne signifie pas qu’elle est libre de droits. Les APIs Java, en l’occurrence, sont publiées sous licence virale GPL, ce qui aurait obligé Google a mettre Android sous licence GPL également – à moins d’acheter une licence commerciale auprès de Sun/Oracle. Même l’exception de classpath n’y change rien: d’un point de vue légal, il serait facile de démontrer qu’Android effectue beaucoup plus qu’un simple « lien » vers des APIs Java: en fait, il les incorpore et les redistribue.
Reste néanmoins qu’il est difficile de juger du degré de plagiat quand il s’agit d’interfaces: faute de mieux, la jurisprudence américaine s’appuye en général sur la notion de SS&O: Structure, Sequence and Organization, selon laquelle la structure, l’ordre et l’organisation mêmes d’une API (l’ordre de déclaration des fonctions, leurs noms, la documentation associée, etc.) sont en soit une oeuvre intellectuelle sujette à protection.
C’est bien entendu la position qu’a défendue Oracle, tandis que Google estimait de son côté que Java étant un standard, ses APIs ne sauraient être protégées par la propriété intellectuelle. Google a même engrangé des points lorsque Jonathan Schwartz, ex-CEO de Sun, et dont on connaît le peu d’estime qu’il porte à Oracle, est monté à la barre pour affirmer que, d’après lui, une API Java n’est pas sujette à la propriété intellectuelle.
Mais Google a avancé un deuxième argument choc: quel que soit le statut des APIs incriminées, leur utilisation dans Android relèverait du « fair use » (usage loyal). L’argument a d’une certaine manière fait mouche, notamment en noyant le débat dans cette notion juridique assez floue. Il a cependant du plomb dans l’aile: en effet la jurisprudence estime que l’usage loyal doit, entre autre, servir l’intérêt public. En l’occurrence, il faudrait au minimum que l’intéropérabilité entre Java et Android ait été préservée… ce qui n’est pas le cas. Sans compter que Google, en matière d’usage loyal, a mauvaise réputation: ce n’est pas la première fois que la firme de Mountain View s’attaque avec désinvolture à la propriété intellectuelle d’autrui. On se souvient en effet de l’épisode rocambolesque des headers du noyau Linux que Google a passés à l’eau de Javel – pour l’instant, pas de procès à l’horizon, mais cela pourrait arriver à tout moment.
Le verdict sur la phase 1 a été rendu le 7 mai dernier: le jury a reconnu Google coupable d’infraction au droit d’auteur sur les 37 APIs ainsi que sur la méthode « rangeCheck ». Les classes décompilées, quant à elles, ont échappé à la sanction du jury, mais le 12 mai dernier le juge Alsup est passé outre avec un référé dans lequel il estime qu’elles ont bel et bien été décompilées et copiées. Le juge doit maintenant prononcer un arrêt définitif sur le fait que les 37 APIs Java sont ou ne sont pas protégées par le droit d’auteur, mais il sera certainement favorable à Oracle. Enfin, quant à la notion de « fair use », le jury a refusé de statuer faute d’éléments précis, ce qui se soldera vraisemblablement par un autre jugement en référé (ce que souhaite Oracle).
C’est donc un quasi sans-faute pour Oracle, qui voit cependant ses gains potentiels dans ce procès se réduire comme peau de chagrin. Jugez-en plutôt: estimés au départ à 6 milliards de dollars, ces gains ont ensuite été abaissés à 1 milliard, puis à une centaine de millions, au fur et à mesure que les pièces à conviction se réduisaient en nombre. Et pire: si le juge Alsup donne raison à Google sur les 37 APIs, Oracle pourrait se retrouver avec la modique somme de 150.000 dollars en dédommagement de… 9 lignes de code correspondant à la méthode « rangeCheck ».
En attendant, la phase 2 du procès a débuté la semaine dernière sur des questions qui piétinent, et avec des jurés de plus en plus à bout de forces. De tous les brevets originellement cités, seuls deux sont toujours en litige:
- Le « brevet Gosling » cible Dalvik: il s’agit de la résolution dynamique de références symboliques.
- Le « brevet ’520 » concerne quant à lui une méthode optimisée pour initialiser les tableaux statiques, et vise plus particulièrement l’outil « dx » d’Android qui convertit le bytecode Java en exécutable Dalvik.
Dans les deux cas, les contre-arguments de Google apparaissent fragiles, d’autant qu’ils sont parfois contredits par les commentaires du code source. Mais la position du jury semble fluctuer d’autant que celui-ci semble avoir du mal à appréhender des notions extrêmement pointues.
D’ici quelques jours nous saurons quel sera le jugement sur les 37 APIs (au moment même où nous bouclons, il semblerait que le juge Alsup soit en train de préparer son arrêt en mettant l’accent sur l’intéropérabilité entre Java et Android) ainsi que l’issue de la phase 2, mais pour l’heure, il n’est pas trop aventureux que de dire que la balance penche légèrement du coté de Larry Ellison plutôt que de celui de Larry Page.
Java 8 – Lambda Project : itération 1
L’équipe du projet lambda vient d’arrêter sa première itération et de livrer une nouvelle version de l’OpenJDK. Ce projet, encadré par la JSR 335, a pour but de faciliter l’utilisation de la programmation fonctionnelle dans le quotidien du développeur Java, aidant ainsi le développeur à améliorer sa productivité. Le projet lambda devrait intégrer le JDK 8 en 2013.
Voici ce que vous trouverez dans cette itération :
- Améliorations du compilateur et des bibliothèques.
- Support complet de la sémantique des defender methods (aussi appelées virtual extension methods).
- Traitement en flux des lots de données (façon Collection) et des Map.
- Prototypage de l’implémentation parallèle (ie. collections multi-thread).
- Ébauche d’une mise en place de la diminution du boxing sur les types primitifs.
D’autres fonctionnalités ont été sortie du scope de cette itération. Mais elles devraient réapparaître dans les itérations suivantes.
- Définition l’API Java finale pour les lambda et les collections.
- Implémentation parallèle complète, basée sur fork-join.
- Prise en compte complète des types primitifs.
Vous êtes gracieusement invités à tester cette version de l’OpenJDK, afin de la confronter à des problématiques que vous avez rencontrées et de partager vos expériences sur la mailing list du projet lambda.
À ce propos, le London Java Community propose un Lambdas Hack Day ce dimanche 27 mai. Les détails et inscriptions sont ici.
Lancement de BuildHive par Cloudbees
La plupart d’entre vous utilise déjà GitHub, sinon il est temps de s’y mettre !
En effet, CloudBees vient d’annoncer la sortie de BuildHive. BuildHive est une plate-forme d’intégration continue qui permet de compiler automatiquement les projets hébergés sur GitHub avec un serveur Jenkins CI, et tout ça, sur le Cloud !
La configuration est assez simpliste et un guide (en anglais) peut être trouvé à cette adresse.
Pour information, ce projet a été créé à l’origine par Kohsuke Kawaguchi l’hiver dernier. Vous pouvez lire l’annonce qu’il a écrite la semaine dernière sur le blog de CloudBees.
N’hésitez pas à nous donner votre avis si vous testez BuildHive sur votre projet GitHub.