En mai, Google a infligé une défaite retentissante à Oracle. Ce dernier réclamait 9 milliards de dollars pour avoir violé le copyright de Java et s’en être servi pour assurer le succès d’Android. Un juge en a finalement décidé autrement : il s’agit bien d’un cas de fair use. Qu’Oracle conteste à présent.
La guerre entre Google et Oracle semble ne pas avoir de fin. Depuis plus de six ans, Oracle cherche à obtenir réparation pour la violation du copyright sur la technologie Java, obtenue avec le rachat de Sun. Pour Google, il ne s’agissait au départ que d’un cas typique de fair use : la partie gardée de Java était minimale. D’ailleurs, un juge avait déclaré en 2012 que la firme de Mountain View n’avait gardé que les noms des méthodes.
De la protection des API
Le véritable enjeu de ce long affrontement reposait en fait sur une question : des API (Application Programming Interface) peuvent-elles être protégées par le droit sur un copyright ? En 2014, un juge avait répondu par l'affirmative, retournant alors la situation. Oracle avait alors cherché à obtenir des dommages et intérêts pour le manque à gagner : 9 milliards de dollars. L’ensemble devait se terminer en mai dernier avec la décision d’un jury, particulièrement attendue.
Malheureusement pour Oracle, ce jury avait décidé, dans une très importante décision, que l’utilisation faite de Java par Google répondait aux critères du fair use. Google jurait que des parties minimales du code avaient été reprises pour fonder sa machine virtuelle Dalvik, qui n’est pour rappel plus utilisée depuis Android 5.0. Oracle, au contraire, insistait sur le fait que plus de 11 000 lignes de code avaient été copiées en l’état pour concevoir Dalvik.
Fair use : simple tremplin ou copie manifeste ?
C’est ici que s’opère la différence entre un fair use et une copie, et Oracle n’en démord pas : Google a copié. Dans une nouvelle motion remise au tribunal de San Francisco qui avait jugé l’affaire jusqu’ici, le spécialiste des bases de données affirme qu’il ne peut s’agir d’un tel cas, puisque le fair use implique que les gains financiers réalisés soient limités. Or, Oracle estime qu’Android a rapporté pas moins de 42 milliards de dollars à Google. Un succès qui n’aurait pu avoir lieu si Java n’avait pas été utilisé.
D’aucuns diraient qu’Oracle fait des pieds et des mains pour ne pas s’assoir définitivement sur un joli pactole. Mais l’insistance de la firme soulève en fait une question sur laquelle le tribunal lui-même était hésitant : qu’est-ce qu’Android ? S’agit-il d’un produit commercial, drainant effectivement des milliards de dollars, ou bien d’une plateforme libre, s’appuyant sur de nombreux projets open source sous-jacents ? Le système couvre ces deux aspects, ce qui rend l’affaire si complexe.
Le commercial affronte le non commercial
Dans la motion remise au tribunal et obtenue par Silicon Valley, Oracle demande au juge en charge de l’affaire, William Alsup, de rester dans l’interprétation classique du fair use, « par exemple pour des critiques, des commentaires, du travail journalistique, de l’apprentissage, dans un cadre académique ou de recherche ». En clair, pas pour s’emparer du marché de la mobilité, avec les conséquences financières qui vont avec.
Pour Oracle, les gains financiers de Google sont trop « manifestes » pour être ignorés. Or, dans son compte-rendu en mai, le juge Alsup notait déjà qu’en dépit de ces gains, le fair use avait « servi également des objectifs non commerciaux, en tant que partie d’une plateforme libre et ouverte, à savoir Android ».
Une nouvelle période s’ouvre donc pendant laquelle Oracle va tenter de prouver que les gains financiers de Google sont tout simplement trop importants pour ne voir que l’aspect « libre et open source » d’Android.
Commentaires (34)
#1
Pour Oracle, les gains financiers d’Apple sont trop « manifestes » C’est pas plutôt google? que l’utilisation faite de Java par Oracle répondait aux critères du fair use.Idem(je dois être mal réveillé, je ne trouve pas le bouton de notification pour les erreurs)
#2
J’ai signalé, je me suis fait la même remarque.
Je me suis demandé pourquoi ça parlait d’Apple d’un coup.
Sur le sujet, les API ne devraient pas pouvoir être protégés. C’est une aberration si c’est le cas.
#3
Un vrai combat de hyènes.
#4
Oracle est connu pour avoir un service juridique plus gros que sa R&D, donc j’ai envie de dire que ça ne m’étonne pas qu’ils reviennent à la charge.
#5
#6
Le principe des API est de rendre interopérable les systems. Donc non on va pas breveter des API, car sinon ca n’a plus aucun interet.
D’autre part oui le code android est libre et open source…. comme Java d’ailleurs ! c’est bien la que le bas blesse : SUN avait devellopé java avec la comunautée. Oracle a fermé la porte….
Bref Google est loin d’etre un ange mais Oracle est sans doute l’une des plus détestables boite IT.
#7
#8
#9
Si jamais ils répondent qu’on peut protéger des API, il sera interdit d’interfacer les choses entre elles sans avoir un accord pour ça ?
Ce serait un adieu à toute interopérabilité des systèmes sans passer par une phase contractuelle avant, c’est moche. Et ça nous empêchera pas de le faire d’ailleurs, ce sera de nombreux procès fleuve aux états unis avec des sommes astronomiques demandées.
#10
Et un moment, RIM (pour Research In Motion me semble-t-il) était surnommé LIM (Lawsuit In Motion)
Un rapport avec le fait que BB s’est fait dépassé ?
#11
#12
Le succès d’Android est lié business model (gratuit) et à la plateforme qu’a développé Google.
Ils auraient fait ça en Python que ça n’aurait pas changé grand chose.
Enfin si, Oracle n’aurait alors probablement pas acheté Sun.
#13
Do androids still dream of electric java ? ;-)
#14
Google aurait du acheter Sun, avec la manne de développeurs Java dont ils sont à l’origine c’est honteux.
#15
#16
#17
Pas dit qu’ils n’ont pas essayé.
Mais Sun n’avais pas que Java. Il y avait aussi toutes la partie serveur (hardware et OS) + d’autres produit comme OpenOffice, MySql et VirtualBox par exemple.
Pas sur que Google aurait été intéressé par tout cela…
#18
#19
Ils pouvaient faire comme avec Motorola. On rachète, on garde ce qui nous intéresse et on revend ensuite le reste.
#20
#21
C’était plus difficile à faire avec SUN. Google ne pouvait pas se contenter de garder les brevets.
Ils auraient du également gérer l’avenir de Java, y compris sur les autres plateformes que la leur.
Pas sûr qu’ils avaient très envies…
#22
Bizarre, une API s’est fait pour être interopérable, or l’interopérabilité est protégé par la loi.
#23
#24
Bah, ça va faire comme pour le round précédent…
Au final, les actions d’Oracle et des autres nuisent fortement au logiciel libre et à l’open source, et rendent l’émergence de solutions alternatives mais compatibles beaucoup plus risquée pour les auteurs de tels logiciels.
#25
#26
Un combat entre deux escrocs….. le vainqueur sera le plus voleur des deux….
Car n’oublions pas que Google vole et s’approprie le travail des autres pour promouvoir ses services et sa pub….
Le constat est simple et évident. Sous Android, personne au final ne gagne de l’argent…. sauf Google…. donc parler de fair use et de plateforme ouverte…. est simplement un mensonge grossier !
Android est la plateforme de promotion des services Google et tous les autres ne font qu’aider à les promouvoir….
#27
#28
Un peu simpliste comme analyse…. car JC decaux n’oblige pas encore les automobilistes à passer devant son mobilier ni à regarder leurs publicités, JC decaux ne sanctionne pas les annonceurs qui vont à la concurrence, JC Decaux n’a pas de position dominante sur le marché, JC Décaux ne vole pas (encore) les données personnelles, JC Décaux paye des royalties pour les brevets qu’il utilise, JC Décaux paye pur les emplacements qu’il utilise, JC Décaux ne travaille pas depuis des paradis fiscaux, JC Décaux paie des impots,
etc. etc. etc. etc.
Bref, ton analyse compare des choux et des carottes et montre clairement comment des juges peuvent se laisser abuser (corrompre ?) par des comparaisons sans fondements….
#29
Oracle " />
(dédicace à Gokudomatic" />)
#30
Et comment Oracle est né ?
Quand Larry Ellison a copié SEQUEL (de chez IBM) pour faire SQL
#31
#32
#33