Canada: Oracle c. Google: La Décision En Appel

Si Pierre Nguyen parle souvent de biscuits, moi je parle souvent du dossier Oracle c. Google.

J'ai écrit en décembre 2012 au sujet de la décision rendue par le juge Alsup du District Court du nord de la Californie, puis en février 2013 quand le mémoire présenté en appel par Oracle avait été rendu public.

Franchement, personne ne m'a interpellé dans la rue pour me parler de ces billets qui, je croyais, n'avaient intéressé personne. C'était jusqu'à ce que je donne une présentation (plutôt bien accueillie, je pense) au Centre de recherche du CHUM intitulée « Ce que le jeu de Monopoly peut nous apprendre sur le droit d'auteur dans les logiciels ». Les questions et les courriels de suivi des membres de l'auditoire m'ont convaincu qu'il y avait un intérêt à continuer d'en parler. C'est justement quelques semaines après cette présentation que le jugement de la Cour d'appel pour le 9e circuit a été publié, et c'est le sujet du présent billet. Pardonnez cependant le délai : La décision a été rendue en mai, mais j'ai été trop occupé entre mai et juillet à consentir à recevoir des courriels en réponse à des demandes en ce sens transmises en préparation de l'entrée en vigueur de la Loi anti-spam canadienne.

Pour rappel, ce dossier est fascinant puisqu'avoir voulu inventer un problème difficile pour une question d'examen de fac de droit dans un cours de droit d'auteur dans les logiciels, il aurait été difficile de faire mieux.

Au surplus, les concepts sont très similaires en droit canadien où on a aussi reconnu la difficulté de déterminer comment (et si) le droit d'auteur protège les logiciels, en particulier les éléments « non littéraires » des logiciels comme leur « structure, séquence et organisation » (ci-après, SSO). Certaines décisions canadiennes pertinentes citent d'ailleurs avec une certaine autorité les décisions américaines clefs sur le sujet. Pas de doute, donc, que le résultat ultime de cette saga aurait au moins une certaine influence en droit canadien.

J'ai résumé les faits et la décision de première instance dans mon premier billet, m'extasiant au passage devant la clarté du jugement du juge Alsup, ce dont je suis un peu gêné maintenant que le jugement a été cassé en appel sur tous ses points:

Donnons-lui cependant que son explication des données techniques du problème était et demeure excellente.

Les faits

Pour ceux qui ne veulent pas aller relire mes vieux billets, résumons la cause ainsi :

Oracle prétend que Google a reproduit (ce que Google admet) dans son logiciel d'exploitation pour appareils mobiles Android les noms et la SSO de 37 « packages » de « l'application programming interface » (API) Java. Google avait cependant programmé elle-même du nouveau « code implémentatif » pour chacun des « packages » reproduits.

Un « API » est une sorte de carré de sable pour développer des applications compatibles avec plusieurs plateformes. On sait comment il peut être payant de détenir un API populaire auprès des programmeurs : c'est en grande partie ce qui explique les succès des iPhone et Android de ce monde.

Concrètement, ça signifie donc que Google a inséré dans le code source d'Android 37 « paquets » de code informatique nommés exactement de la même façon que leur équivalent dans l'API Java et ayant exactement les mêmes fonctions que leur équivalent dans l'API Java. Sauf pour leur nom cependant, le code informatique des 37 « paquets » était différent. Seulement 3 % des lignes de code de l'API Java avaient donc été reproduites.

Les « paquets » de code sont utilisés par les programmeurs qui y font des renvois : Au lieu de devoir tout recopier une fonction dans leur « cSur » du code de leur application, ils n'ont qu'à insérer un « appel » de la fonction correspondante en invoquant le « paquet » correspondant.

Par exemple, au lieu de devoir écrire dans mon programme informatique plusieurs lignes de code servant à permettre d'identifier et retenir le plus grand nombre parmi une série de nombres, je pourrais tout simplement invoquer une fonction (ou méthode) que quelqu'un a déjà programmée pour moi. Dans l'API Java, la méthode « max » dans la classe « Math » contenue dans le « package » java.lang sert précisément à cela.

Au lieu d'écrire plusieurs lignes de code, je n'aurais donc qu'à écrire (à peu près) :

Pourquoi Google a-t-elle fait cela? Elle voulait que les programmeurs déjà habitués de programmer des applications en utilisation l'API Java puissent retrouver les mêmes fonctions dans les mêmes « packages » dans Android en pouvant les invoquer en utilisant les mêmes noms que dans l'API Java.

La seule question devant la Cour, le reste ayant plutôt été décidé par un jury, était celle de savoir si les éléments reproduits par Google, soient les noms des « packages » et leur SSO, étaient protégés par le droit d'auteur. Dans la négative, Google ne pouvait évidemment pas être condamnée, même si le jury, saisi indépendamment de la question de l’existence de contrefaçon, a effectivement décidé qu'il y avait copie.

Pour les raisons que j'ai déjà expliquées, le juge Alsup a conclu que les éléments reproduits par Google n'étaient pas protégés.

D'après la Cour d'appel du 9e circuit, le juge Alsup a fait deux erreurs fondamentales, dont je discuterai l'une après l'autre, maintenant que cette trop longue introduction à ce trop long billet (merci à ce blogue de me rassurer) est terminée.

Première erreur : Croire que Google ne pouvait organiser le SSO de Android d'une seule façon pour qu'il soit « interopérable » avec Java et accepter que ce besoin d'interopérabilité soit un frein à la « copyrightability » de l'API de Java

Google plaidait qu'elle devait absolument utiliser les noms et l'organisation des « packages » de l'API Java pour pouvoir rendre son code « interopérable » avec celui de l’API Java.

Or, il y a un concept en droit d'auteur, le « merger doctrine », qui dit que lorsqu'il y a une ou très peu de façons d'exprimer une idée, l'expression de l'idée et l'idée elle-même « fusionnent ». S'il n'y a qu'une seule façon d'exprimer une idée, par exemple une équation expliquant une nouvelle loi de la physique (comme E = mc2), l'expression de l'idée (soit l'équation) est impossible à distinguer de l'idée elle-même (soit, dans le cas de E = mc2, la relation d'équivalence masse-énergie).

Google prétendait que puisqu'elle n'avait qu'une façon de programmer Android, la SSO de l'API Java ne pouvait donc pas être protégée par droit d'auteur puisque « le code est devenu l'idée », alors que nul ne peut avoir un droit d'auteur dans une idée.

Dans les faits, ce que voulait Google, c'était pouvoir profiter de l'existence d'un bassin de programmeurs familiers avec l’API Java. La preuve démontre Google aurait pu organiser la SSO de Android de façon complètement différente de celle de l'API Java et réussir quand même à créer un logiciel en mesure d'accomplir les mêmes fonctions que celles de l'API Java. Google n'aurait simplement pas bénéficié du même raccourci et d'une popularité aussi immédiate auprès des programmeurs.

Rappelons que le juge Alsup n'avait pour seule mission que de déterminer si les éléments reproduits étaient protégés par le droit d'auteur : purement une question de « copyrightability » donc.

Dans ce contexte, il était donc mal avisé pour le juge Alsup de considérer les options qui s'offraient à Google pour programmer Android.

Il fallait plutôt considérer les options qui s'offraient aux créateurs de l'Suvre dont on analyse la « copyrightability », soit les programmeurs qui ont conçu l'API Java, pas ceux de Google lorsqu'ils ont conçu Android. Si le travail des ingénieurs ayant conçu la SSO de l'API Java était suffisamment créatif et que plusieurs options s'offraient à eux quant au choix du nom des « packages » et à leur organisation, l'Suvre est en principe « copyrightable » puisqu'on ne peut pas dire que l'idée et l'expression de l'idée ont « fusionné ».

Petite illustration :

Je deviens écrivain. Mon premier livre contient les éléments suivants :

" Il y a la planète Hoth, où il fait très froid, la planète Endor dont les habitants, les Ewoks, sont comme des petits ours et la planète Naboo dont les habitants sont des gungans.

" Les gardiens de l'ordre sont appelés les « jedi » et leur arme de prédilection est le « sabre laser ».

" Mon personnage principal est un garçon intrépide du nom de Luke Skywalker qui est un des leaders d'une membre d'une bande de rebelles avec sa sSur jumelle, la Princesse Leia et un ancien contrebandier du nom de Han Solo.

" Le vaisseau spatial de combat de prédilection des rebelles est le X-Wing.

" Les méchants sont les dirigeants de l'Empire, soit l’empereur lui-même, un grand maître des forces obscures du nom de Darth Sidious et son serviteur, un cruel mi-homme/mi-robot du nom de Darth Vader à la voix caverneuse et à la respiration difficile.

L'histoire de mon livre, intitulé, disons « Naboo Love Taboo », est complètement originale : il s'agit d'une comédie romantique racontant la brève histoire d'amour entre Luke Skywalker et une femme gungan (une gunganne?).

Évidemment, aussitôt mon livre publié, je reçois une mise en demeure de Lucasfilm, qui invoque contrefaçon de son droit d'auteur. En réponse, j'avoue candidement avoir copié une partie de la SSO de Star Wars en reprenant les noms et « fonctions » de certains personnages, de certains vaisseaux et de certaines planètes. Par contre, je me défends en argumentant que je n'avais pas le choix puisque mon but était justement de créer une comédie romantique dans l'univers bien connu de Star Wars et ainsi intéresser les gens qui sont déjà amateurs de cette saga, sans quoi il aurait été beaucoup plus difficile de trouver un auditoire pour mon premier livre. En quelque sorte, je voulais que mon Suvre soit « interopérable » avec l'univers de Star Wars.

Ainsi, je n'avais donc qu'une seule façon de nommer et d'organiser les planètes, vaisseaux et personnages pour en arriver à mes fins. En conséquence, ces éléments de l'Suvre de George Lucas ne peuvent pas être protégés par le droit d'auteur.

On voit tout de suite que cet argument ne fait pas de sens. C'est pourtant assez près de ce que Google a plaidé (avec succès en première instance) en réussissant à faire passer l'interopérabilité comme une nécessité. Évidemment, quand la seule question dont on doit décider est celle de la « copyrightability » il faut plutôt se demander si George Lucas a fait preuve de créativité en nommant ainsi les planètes, personnages et vaisseaux de l'univers de Star Wars.

Si George Lucas n'avait eu, lui, qu'une seule façon de nommer planètes, personnages et vaisseaux (comme, par exemple, Maurice Druon qui n'avait pas le choix dans ses Rois maudits, de prendre les noms des personnages historiques ou comme l'auteur d'un livre de vampires ne peut prétendre avoir un droit d'auteur sur le fait que ses personnages ont des longues dents et ont pour « fonction » de croquer leurs victimes et boire leur sang), il est vrai que ces éléments n'auraient pas été considérés comme protégeables.

Il était cependant clair, d'après la preuve, que les programmeurs de Sun (qui a été achetée par Oracle) qui ont créé l'API Java auraient pu organiser et nommer les « packages » de toutes sortes de différentes façons (par exemple en insérant plusieurs méthodes dans un même « package » plutôt que de créer plusieurs « packages » unifonctionnels, ou l'inverse) et créer un API fonctionnel.

Ainsi, la Cour d'appel du 9e circuit a considéré que le juge de première instance a erré en analysant, dans un débat portant purement sur la « copyrightability », les options qui s'offraient à la défenderesse Google lorsqu'elle a créé Android plutôt que les options qui s'offraient aux créateurs de l'Suvre « copiée ».

C'est étrange, parce que le juge Alsup reconnaissait pourtant…

" que les créateurs de l’API Java avaient fait preuve de créativité:

" que le langage Java n'imposait absolument pas à Google de copier la structure du code de l’API Java:

Comment, dans les circonstances, la cour de première instance a-t-elle pu se tromper autant?

Au final, on semble avoir simplement donné trop de poids au fait que Google prétendait être liée par la façon de programmer l'API Java et au « besoin » d'interopérabilité (une sorte d'interopérabilité bien particulière par ailleurs puisque Android n'est pas et n'a pas été conçu pour être directement compatible avec Java... en somme, une interopérabilité qui semble ne bénéficier qu'à Google).

Comme on l'a vu, si Google se sentait ainsi liée, c'est simplement parce qu'elle voulait bénéficier du fait que Java était bien connu des programmeurs qui pourraient facilement créer des applications pour Android. C'est d'ailleurs une grande partie de ce qui explique l'indéniable succès d'Android.

Enfin, et c'est ce qui conduit au deuxième point sur lequel il y a eu une erreur importante, le juge Alsup a considéré de toute façon que la SSO de l’API Java était une « méthode d'opération », soit quelque chose de purement fonctionnel, et que ce type « d'invention » ne pouvait être protégée que par brevet.

Deuxième erreur : Considérer que la SSO était purement fonctionnelle et donc dépourvue de protection en vertu du droit d'auteur puisque ça tombe plutôt dans le champ des brevets

D'après Alsup donc, même s'il n'y avait pas eu « fusion » de l'idée et de l'expression, la SSO de l'API Java était une « méthode » qui ne pouvait être protégée que par brevet. Le problème avec cette conclusion est que tout code informatique a nécessairement pour but d'accomplir une certaine fonction.

De là, il n'y a qu'un pas à franchir pour conclure qu'un programme informatique ne pourrait jamais être protégé par droit d'auteur, ce qui est contraire à tout ce que dit à ce sujet le droit américain (et canadien soit dit en passant).

La Cour d'appel explique plutôt que l'expression (dont la SSO) d'une méthode peut être « copyrightable » si l'auteur avait plusieurs options devant lui pour créer cette fonction. Comme on l'a vu, c'était le cas des programmeurs de Sun qui ont créé l'API Java.

Bref, si je vous explique en alexandrins (ou à tout le moins d'une façon suffisamment originale) une méthode pour cuisiner un biscuit (bon, un autre!), mon texte n'est pas dépourvu de protection pour la seule et unique raison que j'explique une méthode et que c'est donc fonctionnel. Ainsi, tout le monde n'est pas libre de copier mon texte ou son organisation (encore une fois, si cette organisation est originale), même s'il est vrai que tout le monde demeure libre de trouver un moyen différent d'expliquer la même méthode.

La Cour d'appel du 9e circuit a donc infirmé la décision du juge Alsup au sujet de la « copyrightability » et un soupir de soulagement a été poussé par plusieurs des intervenants qui ont soutenu Oracle en appel. Si la décision du juge Alsup avait été confirmée, on aurait bien pu se demander ce qui restait en terme de droit de PI pour protéger les logiciels, sauf dans les cas peu subtils où il y a eu copie servile de grands pans de code.

La suite?

Le jury en première instance avait déterminé qu'il y avait contrefaçon, mais avait été incapable de s'entendre au sujet de la défense de « fair use », ce qui n’était pas grave en vertu de la décision du juge Alsup puisque rien ne sert de discuter d’un moyen de défense à une contrefaçon d’une oeuvre non protégeable. Compte tenu du résultat en appel sur la question de la « copyrightability », le dossier est renvoyé au jury avec des nouvelles instructions pour qu’il se prononce sur le « fair use ».

À défaut d'écrire « Naboo Love Taboo », je me suis engagé à écrire un article sur le droit d'auteur dans les logiciels pour les Développements récents 2014 en propriété intellectuelle et j'en profiterai pour analyser la décision de la Cour d'appel du 9e circuit d'un point de vue canadien. Je vous sens déjà trépigner d’impatience tellement vous avez hâte.

Norton Rose Fulbright Canada LLP

Norton Rose Fulbright is a global legal practice. We provide the world's pre-eminent corporations and financial institutions with a full business law service. We have more than 3800 lawyers based in over 50 cities across Europe, the United States, Canada, Latin America, Asia, Australia, Africa, the Middle East and Central Asia.

Recognized for our industry focus, we are strong across all the key industry sectors: financial institutions; energy; infrastructure, mining and commodities; transport; technology and innovation; and life sciences and healthcare.

Wherever we are, we operate in accordance with our global business principles of quality, unity and integrity. We aim to provide the highest possible standard of legal service in each of our offices and to maintain that level of quality at every point of contact.

Norton Rose Fulbright LLP, Norton Rose Fulbright Australia, Norton Rose Fulbright Canada LLP, Norton Rose Fulbright South Africa (incorporated as Deneys Reitz Inc) and Fulbright & Jaworski LLP, each of which is a separate legal entity, are members ('the Norton Rose Fulbright members') of Norton Rose Fulbright Verein, a Swiss Verein. Norton Rose Fulbright Verein helps coordinate the activities of the Norton Rose Fulbright members but does not itself provide legal services to clients.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.