Une lecture française de l'affaire Google v. Oracle

Une API (Application Programming Interface) permet d'accéder aux fonctions ou données d'une application à distance, c'est-à-dire sans accéder à l'application en tant que telle, mais en passant par une interface. Cela peut notamment permettre d'utiliser les fonctions de l'application tierce de manière opaque. Le programme utilisé envoie des requêtes vers un serveur distant puis renvoie la réponse. Cette méthode permet de ne pas avoir à recréer ces fonctions manuellement. 

Il existe plusieurs types d'API. Les plus connues sont les API web. Par exemple, lorsque Facebook fournit une API aux sites Internet pour permettre à leurs utilisateurs de se connecter sans avoir à créer un compte (les utilisateurs utilisent leur compte Facebook). Le code présent sur la page du site Internet va demander l'authentification sur le site, sans avoir accès aux informations (sauf explicitement demandé).

Mais il existe aussi des API pour langages de programmation, librairies, systèmes d'exploitation d'ordinateurs, etc.

Le droit américain protège les expressions créatives par le copyright, qui est donc un équivalent du droit d’auteur. Sa protection découle directement de la Constitution (article 1, section 8, CL. 8), qui affirme que le but de la protection par la propriété intellectuelle est la promotion de l’innovation. La protection par le copyright a été précisée par trois lois (« Act ») de 1790, puis 1976 et 1998. Cette dernière allonge la protection à 120 ans à compter de la création ou 95 à compter de la publication.

A ce jour, pour qu’une oeuvre puisse être protégée par le copyright américain, elle doit être fixée de manière tangible (en opposition à l’état de simple idée), et être originale. Ce dernier critère a été défini par la décision Feist, rendue en 1991 par la Cour Suprême : l’originalité, auparavant appréciée en application de la doctrine du sweat of the brow, s’évalue désormais au regard de la créativité ayant été mise en œuvre par l’auteur. Ne sont alors protégés que les éléments d’une œuvre qui font preuve d’un « minimum de créativité » - un critère finalement assez proche de celui retenu en Europe par la CJUE depuis l’arrêt Infopaq. Dès lors, l’oeuvre qui remplit ces deux critères accède à la protection par le copyright. 

La doctrine du fair use permet à un tiers d’utiliser une oeuvre protégée par le copyright, sans avoir besoin d’obtenir au préalable l’autorisation de l’ayant-droit. Néanmoins, cet usage par un tiers de l’oeuvre protégée doit être un « fair use », une « utilisation équitable ». Là où les exceptions françaises au droit d’auteur sont limitativement énumérées, quatre facteurs (non exhaustifs) sont pris en compte par les juges américains afin de déterminer si l’usage de l’oeuvre par un tiers entre dans le cadre du fair use. Sont ainsi pris en considération : le but et les caractéristiques de l’usage, la nature de l’oeuvre protégée, la quantité et substantialité de l’oeuvre copiée, et les effets de cet usage sur le marché potentiel (c'est-à-dire les conséquences financières pour l’ayant-droit, qui naitront de l’usage de son oeuvre par le tiers). A l’issu de l’étude de ces quatre facteurs, les juges peuvent alors décider si l’usage d’une oeuvre protégée par un tiers entre dans le cadre du fair use.

Sun Microsystem crée Java en 1996 ; il consiste en un langage de programmation, une machine virtuelle et des API. À cette époque, Java n’inclut que 8 paquets de code pré-écrit ; en 2006, il offre déjà plus de 6 000 opérations présentées par 166 API. Sun est acheté par Oracle en 2010.

Or, Google utilise des API et le système de classification (taxonomy) de Java pour développer son système d’exploitation Android pour téléphones. Google aurait apparemment négocié une licence gratuite, sans qu’un accord n’ait été trouvé. Malgré cet échec, Google copie 37 API Java pour Android.

Lorsque le premier téléphone utilisant le système d’exploitation Android est mis sur le marché, Oracle attrait Google en justice sur le fondement d’une utilisation non autorisée de ses programmes protégés par copyright. Google se défend en niant toute protection possible des API par le copyright, et que si cette protection était admise, son utilisation des API serait couverte par le fair use.

Par deux instances séparées (d’un côté sur la protection de l’API par copyright, de l’autre sur l’applicabilité de la doctrine du fair use), Google obtient gain de cause en première instance, mais les décisions sont infirmées par la cour d’appel du Federal circuit. Les décisions des cours d’appel étant en conflit, cela permet à Google de saisir la Cour Suprême, qui accepte de se prononcer. En effet, cette dernière a compétence comme juridiction de premier degré en certaines matières (principalement les affaires entre deux ou plusieurs États), mais aussi et surtout comme juridiction d’appel.

La Cour a le pouvoir discrétionnaire de juger ou non les affaires qui lui sont présentées en appel, depuis que la requête en certioari est devenue la procédure de droit commun par une loi du 27 juin 1988. Selon la dernière révision du règlement de la Cour en 1995, la règle 10 donne des exemples des situations dans lesquelles la Cour peut faire la grâce d’accorder une telle requête, qui relèvent de conflits entre décisions juridictionnelles, notamment entre celles de cours d’appel fédérales.

Dans l’étude de cette affaire d’un point de vue français, il est donc nécessaire de garder à l’esprit ces spécificités de la Cour Suprême américaine. La décision Oracle n’est pas l’équivalent d’un arrêt de la Cour de cassation, mais fait partie des 70 cas traités en moyenne annuellement par la juridiction suprême américaine. Que l’affaire Oracle soit remontée jusqu’à la Cour Suprême, et que cette dernière choisisse de s’en saisir, démontre bien de l’importance que revêt la décision des juges de Washington. 

La copie de Google porte sur 11 500 lignes de codes d’API (sur les 2,8 million de lignes de code de Java). Il s’agissait donc d’un faible pourcentage ; néanmoins Oracle arguait que ces lignes constituaient la portion la plus importante du code, les fonctions pré-écrites essentielles à la rédaction de programmes plus complets.

Considérant les lignes de codes comme protégées par le copyright, la Cour donne néanmoins raison à Google  concernant la doctrine du fair use, pour deux raisons principales. D’une part, quant au but et aux caractéristiques de l’usage, la Cour décide que l’usage a suffisamment conduit à une transformation (transformative) pour considérer que Google a créé un nouveau langage, et que l’objectif de la copie était uniquement de rendre la tâche plus simple aux programmeurs. D’autres part, quant à l’impact économique, la Cour décide que la copie de Google n'a pas eu un impact significatif sur le marché. Oracle commercialisait ce langage pour des ordinateurs et non des téléphones, et ne pas accepter la doctrine du faire use contreviendrait aux objectifs constitutionnels du copyright en occasionnant un risque de préjudice pour le public.

Les critiques concernant cette décision et ses conséquences sont principalement tournées vers la manière dont elles pourront faire évoluer le développement des logiciels et autres technologies liées aux ordinateurs. Il faut noter que la Cour en est consciente, et tente de limiter sa décision à la particularité de l’instance en cours : « Nous ne disons pas que ces questions seront toujours pertinentes concernant l’application du fair use, et encore moins dans le domaine des programmes d’ordinateur. » (traductions libres). La Cour précise également que « les programmes d’ordinateur se distinguent des livres, films, et bien d’autres ‘oeuvres littéraires’, de sorte que les programmes d’ordinateur ont presque toujours une raison d’être fonctionnels [serve functional purposes]. ».

Néanmoins, cette jurisprudence (precedent) a des chances d’être appliquée de manière plus large que ce que la Cour présente. Les défendeurs pourraient utiliser la lecture extensive de la transformation (transformative use) et de l’impact économique sur le public. De plus, la Cour traite les questions sur la doctrine du fair use comme des questions de droit et non de fait, signifiant qu’elles sont à traiter par les juges et non pas les jurys.

Cette question nous semble intéressante du point de vue des enjeux de droit de la concurrence. En droit français de la propriété intellectuelle, tel que construit en application du droit de l'UE, il n'existe pas d'exception de fair use. Toutefois, en droit de la concurrence, ces API auraient pu être comprises comme des infrastructures essentielles par la Cour : « Si la qualification de l’API change, soit le logiciel ne pourrait plus fonctionner, soit le développeur […] aurait à apprendre entièrement un nouveau langage afin de pouvoir utiliser ces API. ».

De plus, le quatrième critère du fair use (l’effet de la copie sur le marché quant à la valeur de la protection du copyright) semble particulièrement mis en avant. Il s’agit selon la Cour de prendre en compte la quantité et source de la perte de marché et « les bénéfices pour le public que la copie a des chances de produire ». Mais elle prend aussi en compte des aspects très spécifiques du marché :

➩ Android est-il un substitut de marché pour Java ? En l’espèce cela n’était pas le cas, car Java n’offrait pas ce qu’Android offre (d’un côté des ordinateurs, de l’autre des téléphones). Il y a donc deux marchés en l’espèce, et pour cette raison « les programmeurs apprenant le langage Java pour travailler dans un marché (smartphones) sont ensuite capables d’apporter leurs talents dans l’autre marché (ordinateurs). ».

➩ Ne pas autoriser la doctrine du fair use en l’espèce reviendrait à placer Oracle dans une position dominante : « Au vu des coûts et difficultés à produire des API alternatifs aussi attrayants au yeux des programmeurs, autoriser la protection par le copyright ici ferait des API de Java un verrou limitant la créativité future de nouveaux programmes. Oracle aurait seul la clef. »

Ainsi, si le litige avait été présenté devant le juge français, le droit de la concurrence aurait pu mener vers une solution similaire. Les célèbres affaires Magill, IMS Health et Microsoft ont permis d’affirmer que l’exercice d’un droit de propriété intellectuelle peut être qualifié d’abus de position dominante et sanctionné en tant que tel, grâce au jeu de la théorie des infrastructures essentielles. Depuis cette série jurisprudentielle, le refus d’accorder une licence permettant l’accès à un service ou une infrastructure essentielle peut être qualifié d’abus de position dominante dans certaines circonstances exceptionnelles. 

Dès lors, la question qui se serait posée dans le cadre de l’affaire Oracle aurait été de savoir si les API en question sont suffisamment indispensables pour être considérées comme des infrastructures essentielles. Le cas échéant, le titulaire du droit de propriété intellectuelle aurait été obligé d’octroyer une licence d’utilisation des API. Le refus d’octroyer une licence aurait été qualifié d’abus de position dominante.