Par: Xavier Beauchamp-Tremblay

Ce n’est pas à tous les jours qu’on voit un juge, qui fait de la programmation informatique, remettre à sa place un avocat célèbre (célèbre au point où – certains y verront un des ultimes hommages qu’un homme puisse recevoir – son personnage a été interprété par George Clooney dans une pièce de théâtre).

C’est pourtant ce qui est arrivé aux États-Unis (where else?) dans une affaire (Oracle v. Google) dans laquelle un jugement a été rendu en mai dernier.

Puisqu’elle date de quelques mois, le dossier n’est donc pas d’une actualité brûlante, mais il vaut la peine d’en parler pour deux raisons:

  • La question du droit d’auteur dans les logiciels continue de mystifier plusieurs entrepreneurs (et juristes);
  • Le jugement du juge américain (le juge Alsup) est si bien rédigé qu’il pourrait quasiment servir intégralement de manuel pour un cours Droit d’auteur dans les logiciels 101.

On m’excusera si le billet est long (moins, quand même que certains articles sur le sport professionnel), mais le sujet est complexe et il tombe en plein dans le mille de la mission vulgarisatrice de cet humble blogue. Heureusement, mon dernier article était pas mal plus léger!

Introduction

Dans cette affaire donc, Oracle poursuivait Google en contrefaçon de droit d’auteur (et de brevet, mais c’est une autre histoire).

Oracle prétendait que Google avait reproduit (dans son logiciel d’exploitation Android) la « structure, la séquence et l’organisation » de 37 « packages » de l’interface de programme d’application (API) de Java.

En passant, j’ai vérifié dans Termium et la traduction suggérée pour « packages » est « progiciel ». En l’espèce, je ne crois pas qu’elle soit adéquate. Je pense que l’expression « paquet-programme » est plus appropriée, mais on nous dit (sur Termium également) qu’elle est à éviter.

Tant qu’à faire une parenthèse, notons aussi que « Java » est également le nom d’un langage de programmation qu’il ne faut pas confondre avec le logiciel « Java ». Tout le monde était d’accord quant au fait que Google était parfaitement libre d’employer ce langage de programmation.

Donc, le jugement rendu par le juge Alsup ne concernait que la question de l’existence (ou l’absence) d’un droit d’auteur dans la « structure, la séquence et l’organisation » des 37 « packages ». La plupart des autres questions (dont la question de déterminer s’il y a eu ou non contrefaçon) ont effectivement été laissées à l’appréciation du jury.

Qu’est-ce qu’un API et un « package »?

Pour les gens qui ne sont pas familiers avec la programmation informatique (je n’en suis pas moi-même un expert, même si j’ai déjà sévi dans HTML et CSS, notamment pour peaufiner le présent site, et dans DOS à l’époque du 80286 IBM de mon père… en 1989), le juge Alsup est assez gentil pour nous donner des explications compréhensibles sur ce qu’est un « API » et un « package » (c’est en fait un des principaux intérêts du jugement pour les juristes):

  • Le logiciel (ou plateforme) Java permet de créer une machine virtuelle permettant aux développeurs de logiciels de développer des programmes qui pourront fonctionner sur différents ordinateurs sans avoir à tout réécrire le code pour chacun. C’est un peu une sorte d’adaptateur électrique universel pour le voyage qui évite aux jet setters d’avoir à traîner deux types de séchoirs durant leurs aventures autour du monde.
  • Pour ce faire, la plafeforme Java est donc composée de 166 « mini-programmes » (les fameux « packages ») pré-écrits qui ont chacun une fonction (« subroutine » ou méthode) et qui sont regroupés en « classes »…  Dans le cas de Java, une fois décortiquées, les 166 packages comprenaient plus de 6000 fonctions.
  • Par analogie, un « API » est une bibliothèque où chaque « package » est une étagère, chaque « classe » un livre et chaque « méthode » un chapitre d’un livre expliquant comment faire une opération quelconque (une opération mathématique ou une impression d’écran par exemple).

Ce que Google avait répliqué

Google (dans Android) avait répliqué 37 des 166 « packages » de l’API de Java (l’ensemble du code de Android contenait au total 168 « packages »):

  • Pour ces 37 « packages », la « bibliothèque » de Android était organisée exactement de la même façon que celle de Java;
  • Les chapitres des livres placés dans la bibliothèque de Android portaient le même titre (les « headers » ou « declarations ») et expliquaient comment faire précisément la même opération que ceux placés aux même endroits dans la bibliothèque de Java;
  • Sauf que les chapitres des « livres » de la bibliothèque de Android étaient ultimement rédigés de façon différente que ceux de Java (i.e. les « implémentations » étaient différentes);
  • Les seules lignes de code (pour les profanes, un code source logiciel ressemble à un texte, avec des lignes et des paragraphes, mais qui est incompréhensible pour la personne qui ne connaît pas le langage de programmation employé) identiques entre Java et Android étaient les « headers » (soit les titres des chapitres);
  • Ces « headers » ne représentaient que 3% de toutes les lignes de code contenues dans les 37 « packages » de Android.

Le droit d’auteur dans la structure, la séquence et l’organisation

Bref, sauf pour les « headers », il n’y avait pas de copie littérale du code de Java. Ça explique pourquoi la question soumise à la cour était de déterminer si Oracle pouvait prétendre détenir un droit d’auteur dans la « structure, la séquence et l’organisation » des fameux 37 « packages ».

La réponse? Non.

Pourquoi? (Prenez maintenant une grande respiration):

  • On ne peut pas détenir de droit d’auteur dans des noms, des titres (notre contributeur Claude Brunet préciserait: sauf pour des titres comme ceux de certaines oeuvres de Rabelais) et des courtes phrases.
  • Les 3% de lignes de codes identiques entre Java et Android (les « headers ») étaient précisément cela: des noms ou des titres.
  • Or, non seulement on ne peut pas détenir de droit d’auteur dans un simple titre, mais les « chapitres », suivant les règles du langage de programmation Java, ne pouvaient pas porter un nom différent.
  • Même si Oracle ne plaidait pas nécessairement détenir un droit d’auteur individuel dans chacun de ses « titres », elle plaidait que Google avait violé son droit d’auteur en reproduisant les mêmes titres pour des « chapitres » expliquant précisément la même « méthode » (mais dans des mots différents) que dans le chapitre correspondant de Java (bref, en reproduisant la « structure, la séquence et l’organisation »).
  • Or, l’organisation et la nomenclature des 37 « packages » de Java étaient dus entièrement à des considérations pratiques (créer un programme efficace, rapide et facile à employer en tenant compte des capacités des appareils sur lesquels il devait être installé).
  • La jurisprudence considère que des structures créées en fonction de considérations pratiques ou de facteurs externes (des exigences de compatibilité, des spécifications mécaniques des appareils devant utiliser le programme, des conventions de programmation, etc.) n’ont pas le niveau d’originalité requis pour pouvoir être protégées par le droit d’auteur.
  • Le tout nous amène à la dichotomie idée/expression: le droit d’auteur ne protège pas une simple idée, mais plutôt l’expression de celle-ci. Or, quand des seules considérations pratiques ou des facteurs externes guident presqu’entièrement l’exercice de création, on considère que l’expression se « fusionne » dans l’idée et n’est donc plus susceptible d’être protégée par le droit d’auteur (ce qu’on appelle le « merger notion » ou « merger doctrine »).
  • Ultimement, même si on avait déterminé que la « structure, la séquence et l’organisation » des 37 « packages » de Java laissait suffisamment de place à du travail créatif et n’était pas entièrement guidée par des considérations pratiques ou externes, il s’agissait aussi d’une « méthode ».
  • Or, le droit interdit spécifiquement la protection des méthodes par le droit d’auteur. Celles-ci doivent plutôt être protégées par des brevets. Le contraire permettrait de contourner le système des brevets et de détenir une protection de presque 100 ans (au lieu de 20 ans pour un brevet) pour une méthode parce que le programmeur a dû faire preuve de créativité pour y arriver.

Ouf!

En résumé, si je fais un livre de 37 chapitres pour vous apprendre une révolutionnaire méthode de jardinage, et que:

  • vous reproduisez tous les titres de mes chapitres;
  • tous vos chapitres expliquent la même chose que le chapitre correspondant dans mon livre;
  • l’ensemble de votre livre explique exactement la même méthode que ma méthode révolutionnaire;
  • le texte des chapitres de votre livre est différent du mien (les mêmes étapes et méthodes sont expliquées, mais dans des mots différents);

il n’y a probablement pas grand chose que je pourrais faire (en vertu du droit d’auteur américain du moins).

Et qu’en est-il au Canada?

Reste que malgré ce que dit la chanson « Vivre en ce pays » de Charlebois, du point de vue du droit d’auteur, vivre au Canada ce n’est pas tout à fait comme vivre aux États-Unis.

En arriverait-t-on à la même conclusion que le juge Alsup au Canada? Justement, c’est pratiquement cette même question qui était soumise à la Cour d’appel de l’Ontario dans Delrina Corp. v. Triolet Systems Inc. (jugement de 2002).

La cour y explique que les droits anglais et canadien diffèrent du droit américain en ce qu’ils ont tendance à appliquer avec moins de sévérité envers les créateurs la distinction idée/expression, donnant peut-être ainsi plus d’importance à l’effort.

Malgré tout, la cour considère que les droits anglais et canadien reconnaissent (et vous reconnaîtrez les principes énumérés ci-dessus et provenant de la décision américaine dans Oracle v. Google):

Pour ces raisons, j’ai tendance à croire que si les faits de l’affaire Oracle v. Google étaient présentés à un tribunal canadien, celui-ci devrait en venir à la même conclusion que celle du juge Alsup.

Notez cependant que dans l’affaire québécoise Conexsys Systems Inc. c. Aime Star Marketing Inc. (jugement de 2003), la juge Trahan procède (dans un jugement fleuve) à une analyse semblable à celle de la Cour d’appel de l’Ontario dans Delrina, mais sa conclusion est différente.

La juge Trahan y mentionne justement que « l’approche anglaise/canadienne accorde une plus grande protection au droit d’auteur en reconnaissant, à certains égards, l’importance du « skill and labour » dans la création de l’œuvre ».

Bien que le résumé de la preuve et des détails techniques, avec le plus immense respect, n’est peut-être pas aussi compréhensible que celui du juge Alsup (un programmeur amateur diplômé en mathématiques, rappelons-le) on comprend cependant qu’il y avait dans cette affaire Conexsys beaucoup plus de similarités dans « l’implémentation » (la juge Trahan insistant sur le fait qu’il y a eu copie servile) que dans l’affaire Oracle. Reste que je ne suis pas certain que ce jugement survivra à l’épreuve du temps, considérant notamment qu’on y parle de la copie de la méthodologie de programmation.

Bref, avec toutes les réserves qui s’imposent, nous Canadiens pouvons en apprendre beaucoup sur le droit d’auteur dans les logiciels à partir de la décision du juge Alsup… ce qui fait bien sûr de ce jugement une excellente lecture du temps des fêtes!

Note: Cette saga évolue et nos articles publiés sur cette question sont rassemblés ici.