Publié par
Il y a 6 années · 9 minutes · Events

Revue de Presse Xebia

Revue de Presse Xebia
La revue de presse hebdomadaire des écosystèmes Java/JEE proposée par Xebia.

Evènements de notre communauté en France et à l’étranger

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 »:

  1. la phase 1 s’est jouée jusqu’au 7 mai et portait sur les infractions aux droits d’auteur (copyright);
  2. la phase 2 se joue en ce moment et porte sur les infractions aux brevets déposés (patents);
  3. 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:

  1. 37 APIs Java situées sous les packages java.* et javax.* (détails ici);
  2. Une poignée de classes sous le package sun.*, qui auraient été décompilées (détails ici);
  3. 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 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:

  1. Le « brevet Gosling » cible Dalvik: il s’agit de la résolution dynamique de références symboliques.
  2. 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.

Xebia France

Xebia est un cabinet de conseil international spécialisé dans les technologies Big Data, Web, les architectures Java et la mobilité dans des environnements agiles. Depuis plus de 11 ans nous avons la volonté de partager notre expertise et nos actualités à travers notre blog technique.

2 thoughts on “Revue de Presse Xebia”

  1. Publié par Bruno L., Il y a 6 années

    Sur les aspects factuels, votre analyse du procès Oracle/Google est intéressante, mais dire que ça se présente bien pour Oracle me semble faux :-)
    En effet passer de 6 milliards à quelques centaines de milliers de dollars semble plutôt indiqué que c’est un fiasco.

    Pour suivre ce procès il faut vraiment se méfier des manipulations, par exemple vous citez Florian Muller, depuis le début de la plainte cet expert en copyright s’est très souvent exprimé et ses analyses ont été reprises dans beaucoup d’articles, or au début du procès il a clairement indiqué sur son blog qu’il était en contrat avec Oracle…

    Pour ceux qui ont du temps, la meilleure source pour suivre le procès est de lire les retranscriptions détaillées sur le site http://www.groklaw.net
    Vous pourrez constater que ce procès est complètement suréaliste : on y voit les plus grands experts Java expliquer les API Java, le fonctionnement d’une machine virtuelle à un jury de personnes complètement novices en informatique.

    On y apprend aussi que sur le partie brevet, le jury n’arrive pas à statuer sur le brevet ‘Gosling’ (normal il faudrait comprendre l’assembleur pour ça) mais qu’en fait ce brevet est en cours d’annulation par l’organisme qui gère les brevets…

    Le pire dans tout ça c’est que ce procès est un énorme gaspillage de moyens et de temps, mais qu’en plus il y aura probablement appel (de la part d’Oracle si ça en reste là, de la part de Google si le juge décidait que le copyright est valable pour les APIs)

  2. Publié par Bruno L., Il y a 6 années

    Le fiasco se confirme pour Oracle : le jury vient de statuer sur la non violation des 2 brevets : http://www.groklaw.net/article.php?story=20120523125023818.

    La dernière chance pour Oracle est que le juge valide le copyright sur les APIs (ce qui est hautement improbable à mon avis).

    Donc sauf surprise, Oracle peut au mieux espérer 150000 dollars (somme maxi théorique) pour les 9 lignes de code jugées comme recopiées, mais il est tout à fait possible que ça soit zéro car :
    – Oracle n’avait pas attribué de valeur à ces 9 lignes lors de son évaluation des dommages.
    – Oracle se tournerait en ridicule en insistant sur l’importance de ces 9 lignes, le juge ayant rappelé que lui même avait été capable d’écrire le même code. Sans compter que l’histoire de ces 9 lignes est très marrante : c’est la même personne qui a développé la version initiale et sa copie (Joshua Bloch). Les 9 lignes recopiées font partie d’un code plus vaste (900 lignes) qui améliore les performances de l’ancien algorithme de tri des tableaux. Le plus drôle est que le code du nouvel algorithme, développé en 2007, a été donné par Joshua Bloch, alors salarié Google, au projet OpenJDK.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *