Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La confrontation de Google et d'Oracle devant la Cour suprême ne s'est pas très bien passée pour l'éditeur d'Android
Les juges semblent prêts à envisager les droits d'auteur sur les API

Le , par Stéphane le calme

267PARTAGES

4  0 
Rappelons que la Cour suprême est constituée de neuf juges, mais que la juge Ruth Bader Ginsburg est décédée le 18 septembre 2020, à six semaines de l'élection présidentielle. Son siège n'a pas encore été remplacé.

Mercredi, certains des huit juges de la Cour suprême semblaient sceptiques quant à l'argument de Google selon lequel les interfaces de programmation d'application (API) ne sont pas protégées par la loi sur le droit d'auteur. La haute cour entendait des plaidoiries dans le cadre de la bataille juridique de Google avec Oracle, qui a déjà duré dix ans. Oracle fait valoir que Google a enfreint ses droits d'auteur sur le langage de programmation Java lors de la réimplémentation des API Java à l'usage des développeurs d'applications Android.

Les enjeux de cette affaire sont importants pour Google, qui pourrait devoir à Oracle des milliards de dollars de dommages et intérêts. Plus important encore, une victoire d'Oracle pourrait remodeler la façon dont la loi sur le droit d'auteur traite les API, donnant aux titulaires le pouvoir de verrouiller les concurrents qui souhaitent créer des logiciels compatibles.

Pendant des décennies avant le procès d'Oracle, la plupart des gens de l'industrie du logiciel supposaient que les API ne pouvaient pas être protégées par le droit d'auteur. Cela signifiait qu'un éditeur de logiciels pouvait réimplémenter les API du produit d'un concurrent afin de permettre à un logiciel, conçu pour fonctionner avec le produit du concurrent, de fonctionner avec le sien.

Une victoire pour Oracle remettrait cela en question. Cela ne générerait pas seulement du travail supplémentaire pour les juristes du droit d'auteur, cela pourrait conduire à un monde où les problèmes de compatibilité des logiciels surgissent plus souvent dans la vie quotidienne. Cela pourrait également affecter directement les moyens de subsistance des développeurs, qui pourraient se trouver être plus fréquemment obligés d'apprendre de nouveaux langages de programmation ou d’apprendre à utiliser d'autres outils logiciels lorsqu'ils changent d'emploi.

Il est toujours risqué d'extrapoler à partir des plaidoiries de la Cour suprême. Parfois, les juges posent des questions plus difficiles à un parti, mais se prononcent de toute façon en faveur de ce parti. Mais au vu du déroulement des échanges, il est difficile d’imaginer une majorité de cinq juges acceptant l'argument de Google selon lequel les API ne peuvent pas être protégées par le droit d'auteur. Si Google gagne, il semble que ce soit pour des raisons plus restreintes (des raisons qui ouvriraient la porte à davantage de poursuites en matière de droits d'auteur sur les API à l'avenir). Quoi qu’il en soit, il semble y avoir de bonnes chances qu'Oracle l'emporte.


Des juges qui se montrent sceptiques

Au milieu des années 2000, Google savait qu'il aurait besoin de beaucoup de développeurs pour créer des applications pour sa prochaine plateforme Android. Pour accélérer le processus, Google a réimplémenté le langage de programmation Java plutôt que de développer un nouveau langage de programmation à partir de zéro. Google a écrit un nouveau code pour exécuter des programmes Java selon les spécifications exactes du logiciel Java officiel de Sun (Oracle a par la suite acquis Sun). Cela a permis à des milliers de développeurs Java existants de devenir des développeurs Android sans avoir à apprendre un nouveau langage.

Pour réimplémenter Java, Google avait besoin de copier les noms et les types d'arguments de fonctions telles que java.lang.Math.max. Sinon, un programme Java utilisant ces fonctions ne fonctionnerait pas sur le système d'exploitation de Google. L'article 102 (b) de la Loi sur le droit d'auteur stipule que personne ne peut protéger « une idée, une procédure, un processus, un système, une méthode de fonctionnement, un concept, un principe ou une découverte ». Google a conclu que des fonctions comme Math.max sont des « méthodes de fonctionnement », car les développeurs « exploitent » la plateforme Java en les invoquant. Par conséquent, Google n'a pas payé de licence à Sun, ce qui a conduit à un procès quelques années plus tard.

C'est une pratique répandue dans l'industrie du logiciel. Oracle, par exemple, a réimplémenté l'API S3 d'Amazon afin que les clients qui ont créé des logiciels pour la plateforme cloud d'Amazon puissent facilement passer à la plateforme cloud rivale d'Oracle.

La stratégie d'Oracle tout au long de la bataille juridique, déjà vieille d’une décennie, a été essentiellement de nier qu'il y a quelque chose de spécial dans les API. Selon Oracle, une spécification d'API (essentiellement juste une liste de noms de fonctions et de types d'arguments) est un code informatique qui peut être protégé par copyright comme n'importe quel autre code. Oracle affirme que si les tribunaux suppriment les spécifications API de la protection des droits d'auteur, les avocats pourraient utiliser les mêmes arguments pour affaiblir la protection des droits d'auteur de tout programme informatique.


Samuel Alito, juge à la Cour suprême

Le juge Samuel Alito a soulevé cette préoccupation dans sa première question à l'avocat de Google, Thomas Goldstein :

« Je suis préoccupé par le fait que selon votre argument, tout code informatique risque de perdre sa protection en vertu de 102 (b) », a déclaré Alito. « Comment conciliez-vous votre position avec l'intention expresse du Congrès de protéger les codes informatiques ? »

La tâche la plus importante de Goldstein ici (et tout au long de l'argumentation de mercredi) était de convaincre les juges qu'il y avait une différence importante entre les API et d'autres codes et que cette différence avait des implications juridiques.

« Il a fait un travail épouvantable », a commenté après les échanges James Grimmelmann, un juriste de l'Université Cornell. « Au niveau de la nuance dans laquelle il était prêt à entrer, son cas les donnait pour perdants. La seule façon de faire tenir cette argumentation est d'être nuancé sur ce que signifie déclarer du code. »


Des difficultés pour Google

La distinction entre un programme et une API a un sens intuitif pour les développeurs qui utilisent régulièrement des API (et écrivent des programmes) dans leur travail quotidien. Mais c'est loin d'être évident pour les juges de la Cour suprême, qui sont tous des avocats de plus de 50 ans.

Cela aurait peut-être aidé Goldstein d’utiliser des analogies ou des exemples concrets de l'industrie du logiciel pour aider les juges à comprendre la distinction, mais il en a très peu fait. Au lieu de cela, il a répété encore et encore une poignée d'arguments juridiques abstraits. Goldstein n'a jamais semblé trouver une explication du caractère unique des API que les juges ont trouvé convaincante.

Lorsque le tour du juge Brett Kavanaugh est venu de poser des questions à Goldstein, il était clair que sa pensée n'avait pas été changée par les réponses précédentes de Goldstein. Les avocats d'Oracle, a noté Kavanaugh, « disent que la déclaration de code n'est une méthode de fonctionnement que dans le même sens que les programmes informatiques dans leur ensemble sont des méthodes de fonctionnement, et que par conséquent, votre argument de méthode de fonctionnement engloutirait la protection des programmes informatiques ».

« Vous n'êtes pas autorisé à copier une chanson simplement parce que c'est la seule façon de copier une chanson », a déclaré Kavanaugh, en prélude de sa question suivante à Goldstein. « Pourquoi ce principe ne s’applique pas ici? »

En somme, Kavanaugh ne semblait absolument pas convaincu qu'il y avait quelque chose de distinctif dans les API qui justifierait un traitement différent en vertu de la loi sur le droit d'auteur.


Brett Kavanaugh, juge à la Cour suprême

Le juge Clarence Thomas semblait tout aussi impassible. À un moment donné, il a comparé les actions de Google à une équipe de football prenant le livre de jeu d'un rival. Le juge Neil Gorsuch a noté que « d'autres concurrents ont été en mesure de proposer des téléphones qui fonctionnent très bien sans se livrer à ce type de copie ».

Il y avait donc au moins quatre juges (Kavanaugh, Alito, Thomas et Gorsuch) qui semblaient sceptiques quant à la position de Google selon laquelle les API ne peuvent pas être protégées par le droit d'auteur. Si les quatre votaient pour Oracle, le meilleur que Google puisse espérer est une égalité. Une égalité serait toujours une perte pour Google, car elle laisserait en place la victoire d'Oracle au niveau de l'appel, mais ne créerait pas de précédent à l'échelle nationale. Si Google perd une décision de justice supplémentaire, cela créerait un précédent national en faveur des droits d'auteur des API.

Une entreprise qui n'était pas entièrement antipathique à la Cour ?

Google n'était pas entièrement sans défenseurs sur le terrain. En fait, quelques juges ont fait un meilleur travail en exprimant la position de Google que son propre avocat.

« C'est comme le clavier QWERTY », a déclaré Breyer dans une question à l'avocat d'Oracle. « Vous n'aviez pas besoin d'un clavier QWERTY sur les machines à écrire au début. Mais mon Dieu, si vous laissez quelqu'un avoir un droit d'auteur là-dessus maintenant, il contrôlerait toutes les machines à écrire, ce qui n'a vraiment rien à voir avec le droit d'auteur. »

Tout comme un droit d'auteur QWERTY bloquerait les dactylographes sur l’utilisation des machines à écrire d'une entreprise particulière, a suggéré Breyer, un droit d'auteur sur les API Java bloquerait les développeurs qui ont appris Java sur des implémentations Java sous licence Oracle.


Sonia Sotomayor, juge à la Cour suprême

Dans une autre question adressée à l'avocat d'Oracle, la juge Sonia Sotomayor a offert l'explication la plus claire sur les enjeux de l'affaire. Voici l'un de ses commentaires :

« Dans votre déclaration de départ, vous aviez dit que le ciel vous tomberait sur la tête si nous nous prononcions en faveur de Google. Le problème avec cet argument pour moi, c'est qu'il semble que depuis 1992, [les tribunaux ont dit que] l'interface de programmation d'application, dont le code de déclaration fait partie, n'est pas protégée par le droit d'auteur. Par contre, les codes de mise en œuvre le sont.

« Sur cette base, les industries se sont construites sur des applications en sachant qu'elles ne peuvent copier que ce qui est nécessaire pour s'exécuter sur l'application, mais qu’elles doivent changer tout le reste. C'est ce que Google a fait ici. C'est pourquoi ils ont pris moins de 1 % du code Java...

« Tout le monde sait que les API, déclarant des codes, ne sont pas protégées par le droit d'auteur. Les codes de mise en œuvre le sont. Alors s'il vous plaît, expliquez-moi pourquoi nous devrions maintenant revoir ce que l'industrie a considéré comme les éléments protégés par le droit d'auteur, déclarant que certaines sont des méthodes de fonctionnement et d'autres sont des expressions ? »

L'avocat d'Oracle Joshua Rosenkranz a contesté la prémisse de la question de Sotomayor. « Dans aucun cas, vous ne verrez dire que vous pouvez copier cette grande quantité de code sur une plateforme concurrente pour l'utiliser dans le même but », a-t-il déclaré à Sotomayor. « Personne n'a fait cette distinction entre l'implémentation du code et la déclaration du code. Vous ne trouverez pas un seul cas qui fasse cela ».

C'était l'une des choses les plus frappantes dans les arguments de mercredi: Oracle et Google ont chacun affirmé que la position de l'autre partie bouleverserait les attentes établies dans l'industrie du logiciel. Selon Grimmelmann, à ce niveau Google avait le meilleur argument ici. Il existe peu de précédents qui se concentrent spécifiquement sur le statut de copyright de la déclaration de code. Mais un certain nombre de cours d'appel ont statué que les interfaces logicielles ne peuvent pas être protégées par le droit d'auteur. Et un grand nombre de projets logiciels ont été construits sur la base de cette compréhension.

En plus de Breyer et Sotomayor, la juge Elena Kagan a posé quelques questions indiquant qu'elle pourrait être sensible à la position de Google. Mais même si ces trois juges se rangeaient du côté de Google, la société aurait encore besoin de deux votes supplémentaires pour annuler la décision du tribunal inférieur en faveur des droits d'auteur des API.

Source : plaidoyers des deux entreprises (vidéo dans le texte)

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 10/10/2020 à 20:46
Pour l'analogie, breveter une API reviendrait dans le monde réelle à breveter un langage, puisque c'est la façon dont nous pouvons communiquer.
Est-ce que la façon de communiquer peut être breveter ? Drôle de question à mon avis.
Alors, oui, la communication est une invention géniale, maintenant si seul 1 ou 2 personnes peuvent l'utiliser, ça me parait perdre pas mal de son intérêt premier .

Globalement, si les idées de la cour suprême ce démocratise sur ce sujet, on aura plus de possibilités d'interconnexion de systèmes hétérogène, puisque tous les environnement devront devenir propriétaire pour exister.
Et je ne crois pas que ce soit une bonne nouvelle pour qui que ce soit, Oracle compris.
8  0 
Avatar de floyer
Membre habitué https://www.developpez.com
Le 22/10/2020 à 16:16
Citation Envoyé par 23JFK Voir le message
Oracle n'est pas l'inventeur de java, il n'a fait que racheter l'entreprise SUN Microsystems et changer la nature de la licence Java.

Cela pourrait, par ailleurs, aussi valoir des problèmes aux systèmes Linux FreeBSD, OsX et iOs qui ont largement pompé leur base de code sur UNIX.
Pour BSD, le procès a déjà eu lieu et à part quelques fichiers qui ont été refait, le procès à donné gain de cause à Berkeley. Ainsi, les systèmes cités ne reprennent pas du code (au sens implémentations), mais uniquement l’API POSIX, ce qui pourrait poser problème si ce procès faisait jurisprudence.
2  0 
Avatar de floyer
Membre habitué https://www.developpez.com
Le 22/10/2020 à 20:11
Citation Envoyé par Battant Voir le message
Bonjour,

Pour être plus clair les API ont toujours pu être payante car ça pourrait être assimilé à des logiciels destinés aux développeurs J’en veux pour preuve que qt. Par exemple est payant à des fins commerciales alors que c’est une API.

Lorsque tu achètes Qt, tu achètes aussi une implémentation. La question analogue serait : que craindrait-on en proposant une réimplémentation de Qt ?

Rappelons nous l’API de Motif qui a été copiée par Lesstif, celle de UNIX (d’AT&T) par BSD puis Linux, .Net par Mono, Windows par Wine...

Avec le précédent en question, Qt pourrait faire valoir la Jurisprudence. Et les exemples que j’ai cités poseraient problème.

D’après la page Wikipedia, le problème retenu par le tribunal est le droit d’auteur (copyright), et non les brevets. Du coup, inutile de breveter une API pour la considérer protégée.
2  0 
Avatar de Axel Mattauch
Membre régulier https://www.developpez.com
Le 09/10/2020 à 20:53
Citation Envoyé par archqt Voir le message
C'est délicat comme situation. C'est comme un fabricant de robinet, on est bien obligé de le copier si on veut que les tuyaux prévus s'y adaptent.
Je suis d'accord pour l'adjectif "délicat". Si c'était trivial, les juges n'auraient aucune raison d'intervenir.
En l'espèce, je trouve que l'exemple "hardware" proposé s'applique mal à la situation, d'autant que le tuyau a certainement précédé le robinet dans la création: le robinet permet d'interrompre ou pas le passage du fluide dans le tuyau.
  • Si le raccordement entre tuyau et le robinet se fait avec un dispositif plus ou moins innovant (filetage, baïonnette, raccord rapide...) il peut s'agir d'une invention, et la protection des droits de précédence se fait par un dépôt de brevet (contestable ou pas).
  • Si le raccordement se fait par un dispositif classique il s'agit de l'état de l'art, et personne en peut se prévaloir du fait que le diamètre du robinet soit x ou y; si un concurrent utilise le même diamètre, c'est le bon sens. Et s'il est plus efficace dans son industrialisation ou son marketing, tant mieux pour lui.
  • Le cas qui pourrait peut être relever du droit d'auteur (selon ma perception du moins) serait que ledit concepteur du robinet ait défini tout ce qui peut se raccorder au robinet (tuyaux, buses, dispositif de sécurité, détendeur...) pour que l'agencement de ces éléments se fasse harmonieusement. De ce point de vue il aura fait preuve de créativité (au même titre qu'un auteur aura écrit un roman, pas donné une liste de personnages, ou qu'un compositeur aura créé une œuvre, pas listé des accords d'accompagnement ).


Citation Envoyé par archqt Voir le message

Moi je dis que ce n'est pas évident. Dans le cas d'Oracle je me sentirais spolié.
Ce n'est donc pas évident. Si effectivement Oracle prouve qu'il a effectivement défini de façon particulièrement pertinente les API et les fonctions assurées, on peut envisager une certaine créativité.
Mais a défaut, les API ne sont que comme les personnages du roman, ou un accord de guitare. Les accords sont réutilisables à l'envi.
Ce qui me navre c'est que le débat semble porter sur le fait que les API, par ailleurs publics comme un accord de E#, puissent être envisagés soumis à droit d'auteur. Je n'ai vu nulle part mention d'une quelconque revendication de propriété sur l'articulation des API java. Cette confusion peut conduire aux aberrations juridiques évoquées par plusieurs intervenants.
1  0 
Avatar de 23JFK
Membre chevronné https://www.developpez.com
Le 10/10/2020 à 15:02
Oracle n'est pas l'inventeur de java, il n'a fait que racheter l'entreprise SUN Microsystems et changer la nature de la licence Java.

Cela pourrait, par ailleurs, aussi valoir des problèmes aux systèmes Linux FreeBSD, OsX et iOs qui ont largement pompé leur base de code sur UNIX.
1  0 
Avatar de patrick72
Membre régulier https://www.developpez.com
Le 16/10/2020 à 9:38
La cours suprême des état unis : Des magistrats élus à vie par une personne unique en fonction de leur convergence politique....

Je pense que tout est dit sur la valeur de leur décisions !
2  1 
Avatar de CaptainDangeax
Membre éprouvé https://www.developpez.com
Le 22/10/2020 à 10:35
On se dirige vers une belle balkanisation en fonction des décisions de la cour suprême. Si les API deviennent brevetables, chaque grand éditeur utilisera son propre langage forcément incompatible avec le voisin. Java chez Orable mais plus personne chez eux à cause du risque de procès, Go chez Google, Rust chez Firefox, C# chez Microsoft...
Après on aura des mappings de clavier différents en fonction du fabricant, la fin du standard ASCII/UTF-8, comme dans les années 60 où chaque fabricant d'ordinateur était 100% incompatible avec le voisin. C'est la grande époque chez les DSI du "Pour être sûr de ne pas être critiqué sur son choix, IBM".
1  0 
Avatar de CaptainDangeax
Membre éprouvé https://www.developpez.com
Le 22/10/2020 à 10:49
Citation Envoyé par floyer Voir le message
Si les interfaces sont protégées par droit d’auteur, j’imagine qu’IBM pourrait faire valoir la paternité sur l’interface de ses premiers PC (BIOS) et demander des comptes aux fournisseurs de PC compatibles !

Microsoft pourrait aussi attaquer c’est qui proposent des émulations (Wine, FreeDOS...)
IBM avait breveté le CODE de son BIOS, pas les API. D'autre part, l'IBM PC a été pensé pour être modulable et facile à construire, c'est pourquoi il n'utilise aucun composant spécifique. Du coup, Compaq, puis après les chinois, ont pu créer des clones avec des composants électroniques librement accessibles sur les marchés et en recréant un BIOS présentant la même API. D'ailleurs, dans les années 80, le grand test c'était la compatibilité avec un IBM PC. L'Amstrad PC1512 n'était pas 100% compatible, certaines applications ne tournaient pas dessus. Tandy avait une grande expérience dans la micro et proposait des PC plus performants avec des chips spécifiques (16 couleurs au lieu de 4 en CGA, meilleur son que le pc speaker...)
1  0 
Avatar de floyer
Membre habitué https://www.developpez.com
Le 22/10/2020 à 20:20
Citation Envoyé par CaptainDangeax Voir le message
IBM avait breveté le CODE de son BIOS, pas les API. D'autre part, l'IBM PC a été pensé pour être modulable et facile à construire, c'est pourquoi il n'utilise aucun composant spécifique.
Le procès en court est - selon la page Wikipedia - plus au sujet du copyright que des brevets. Donc une interface même non brevetée peut être protégée et pour plus longtemps encore que la protection par brevet.

Ceci-dit, il y a une différence : le BIOS est une collection d’interruption logicielle (Int10...) avec des conventions d’appels, mais il n’y a pas de sources impliqué dans l’interface.

Avec Java, il y a une édition dynamique des liens, et du texte commun est nécessaire entre l’implémentation d’origine et la copie... ce qui risque plus de poser problème comme on le voit.
1  0 
Avatar de floyer
Membre habitué https://www.developpez.com
Le 28/10/2020 à 19:11
Citation Envoyé par ddoumeche Voir le message
Non, une affaire ne peut pas être jugée deux fois
Donc OK pour BSD, mais RedHat n’a pas eu son procès. SCO a tenté un procès contre IBM supposant une inclusion de code protégé dans Linux... mais ici, le sujet est différent, il est question de l’API (POSIX) et non de l’implémentation.
1  0