Oracle gagne en justice contre Google sur l’usage de Java, allons-nous tous en souffrir ?

 

La Genèse

En 2008 est officiellement publiée la 1er version de Android, un système d’exploitation mobile racheté puis développé par Google.

Or ce système d’exploitation fonctionne à l’époque avec une machine virtuelle nommée Dalvik assez similaire à la machine virtuelle Java, ou JVM, que distribue à l’époque la société Sun Microsystems.

La JVM de Sun Microsystems supporte donc Java. Quand à Dalvik, celle de Google, elle supporte une forme de Java dérivée, plus adaptée aux appareils mobiles qui à l’époque en 2008 ont des capacités plus que limitées. Cette forme de Java est plus simplifiée, plus légère et plus facile à optimiser.

Sun Microsystems et Oracle, pas la même culture

A l’époque, Google s'était alors très fortement s’inspiré du Java traditionnel dans sa version Java pour android. Il faut dire aussi que d’anciens développeurs de chez Sun Microsystems tels que Joshua Bloch sont les chefs de pont du projet Android.

Ceci n’avait cependant rien de très secret et déjà a l’époque, Google entre en discussion avec Sun Microsystems pour obtenir des droits sur l’usage de Java. Si la chose reste jusqu'à 2009 entre personnes de bonne volonté, les protagonistes ne trouveront pourtant aucun accord.

Mais les choses se compliquent réellement en 2009 lorsque la société Oracle rachète Sun Microsystems et prend le contrôle de la licence Java. Les discussions se poursuivent entre Google et Oracle cette fois mais Oracle n’est alors pas du tout décidé à concéder quoi que ce soit sur ce qu’il considère alors être une poule aux œuf d’or.

Oracle va alors aller plus loin et attaque Google en justice. 9 milliards de dollars sont alors en jeu.

Une histoire de Plagiat ?

Pour quels motifs Oracle attaque t-il donc Google ? Là est tout le problème.

Oracle va en premier lieu reprocher à Google d'avoir plagié le code source de Java : plus de 11000 lignes de code sont concernées.

Voici par exemple le code de la classe PolicyNodeImpl dans les 2 versions :

A gauche on voit à a version de l’API Java pour la JVM et à droite la version pour Android. Pas de doute, si l’on exclue le nom des variables, le code est exactement le même.

Pour défendre cet argument en particulier, Oracle va notamment se concentrer sur une classe nommée TimSort.java faisant appel à un algorithme dit de "rangeCheck" dont 9 lignes sont exactement similaires dans les 2 versions, 9 lignes seulement.

Joshua Bloch à l’origine de ce code chez Google va avouer à demi-mot la copie mais en arguant que après tout, n'importe quel developpeur expert aboutirait à ces mêmes 9 lignes pour ce type d’algorithme. Sous entendant que s’il avait du réécrire cet algorithme de 0, il aurait obtenu exactement le même résultat.

Google remporte le 1er round

En Mai 2012, Oracle sera démi de sa plainte, les juges invoqueront la règle de minimis indiquant que Google n’avait pas tiré un profit significatif de cette copie. Fair enough.

Google retirera toutes les sections de code douteuses en 2014 avec la réécriture du successeur de Dalvik : la machine virtuelle nommée ART (Android Runtime).

Peut-on breveter une API ?

Mais Oracle ne s’arrête pas la ; il va faire rebondir sur un autre argument plus secondaire dans sa plainte initiale, les droits d'auteur sur l'API Java elle-même.

En effet Java pour Android s’inspire très fortement de l’organisation des classes et des packages du Java originel, la taxonomie est similaire. On retrouve par exemple les package java.lang ou java.io et les classes qui sont à l’intérieur sont très similaires comme des classes ultra populaires comme java.lang.String ou java.io.File.

Les méthodes qui se trouvent dans les classes sont aussi quasiment les mêmes. Toute l’API de Java de plus de 37 packages se retrouve dans Java pour android.

Cette plainte font s’indigner entreprises et communautés de développeurs : reproduire une API est extremement commun dans l’industrie du logiciel, on cherche même autant que possible à systématiser les API.

Traduit dans un autre contexte, c’est comme si chaque fournisseur d’electricité venait avec ses propres formes de prises électriques : pas évident à gérer pour le fabriquant d’aspirateur n’est ce pas ?

La plainte de Oracle est aussi terriblement hypocryte, car quelques années auparavant c’est Sun Microsystems qui avait ataqué Oracle pour les mêmes raisons et Oracle avait répliqué qu’une API ne pouvait pas être breveté ou soumis à droit d’auteur.

La justice va finalement trancher encore une fois en faveur de Google en 2016. Selon la cour, copier une API sera considéré comme du fair-use car selon la justice : ce qui a de la valeur ce sont les implementations, pas les APIs.

Oracle gagne en appel, c'est le choc !

Mais Oracle va faire appel de la décision et c’est ce qui nous amène en octobre 2020, la justice donne cette fois raison à Oracle.

L’argument qui a sans doute fait mouche est le suivant. Apple a dépensé des milliards pour créer sa propre API sur Ios, Google aurait donc pu et dû faire de même pour Android. Ne l’ayant pas fait, Google a obtenu un avantage compétitif indu.

Et maintenant, quelles sont les conséquences ?

Si la condamnation fait juris prudence, c’est toute l’industrie du logiciel qui en sera secouée.

Pour nous les développeurs, passer d’une implementation d'une API à une autre deviendra un véritable casse tête car nous devront adapter notre code à chaque nouvelle implementation.

Il vous faudra également bien prendre garde à ne pas reproduire une API de Oracle, Microsoft ou tout autre société en qui vous faite confiance pour établir des standards en terme d’interopérabilité.

Alors est ce que la chose est entendue ? Non, il faudra attendre 2021 pour voir si cette décision sera transmise dans le droit commercial aux Etats-Unis. Ne reste plus qu’a attendre aussi calmement que possible.

Et Android dans tout ça ? Faut-il passer à Kotlin ?

Une dernière question qui se pose, c’est quel est l’avenir de Android dans ce contexte ?

D'abord, il faut savoir que bien évidemment Google, refroidit par l'aventure, a bondit sur l'occasion de passer sa mouture de Java sous OpenJDK, le standard open source de Java. Et c'est en 2016 avec Android N(ougat) que le projet devient un réalité. Par conséquent, seules les versions précédentes de sa machine virtuelle de Google peuvent encore "théoriquement" être mises en cause.

Mais si cela n'est pas suffisant, c’est peut être un 3ème acteur qui pourrait finalement mettre fin au débat : Jetbrains.

En créant le langage Kotlin Jetbrain a offert une alternative aux developpeur Java qui s’évere particuierement intéressante pour android, car ce dernier ne réutilise pas les API Java. Même si ce langage est dévenu rapidement tres populaire pour plein d’autres raisons techniques, ce n’est peut etre pas un hasard si en mai 2019, Google a annoncé que Kotlin devenait officiellement le langage de préférence pour le dévelopement d’applications Android.

🎥 La version vidéo

🙏 Remerciements/Special Thanks

Un grand merci à Aurich Lawson et Arstechnica de m'avoir autorisé à réutiliser leur magnifique illustration.

A very special thank you to Aurich Lawson and Arstechnica for letting me reuse their wonderful illustration of the case.

Références

• http://theregister.com/2011/02/23/oracle_claims_go...
• https://www.infoworld.com/article/3575359/how-oracle-v-google-could-upend-software-development.html
• https://en.wikipedia.org/wiki/Joshua_Bloch
• https://techcrunch.com/2019/05/07/kotlin-is-now-googles-preferred-language-for-android-app-development/#:~:text=Google%20today%20announced%20that%20the,be%20offered%20first%20in%20Kotlin.
• https://www.zdnet.com/article/supreme-court-takes-on-google-vs-oracle-the-biggest-software-development-case-ever/
• https://stackoverflow.com/questions/23583968/what-are-the-37-java-api-packages-possibly-encumbered-by-the-may-2014-oracle-v-g
• https://www.documentcloud.org/documents/1157205-13-1021-opinion-5-7-2014-1.html
• https://www.washingtonpost.com/technology/2020/10/07/google-oracle-supreme-court/
• https://arstechnica.com/tech-policy/2020/03/before...