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 !

API Java : l'EFF intervient en tant qu'amicus curiae et demande à la Cour Suprême des USA d'annuler le verdict rendu en faveur d'Oracle
Car les API ne sont pas soumises au droit d'auteur

Le , par Bill Fassinou

46PARTAGES

23  0 
L’Electronic Frontier Foundation (EFF) a adressé une lettre à la Cour Suprême des États-Unis cette semaine lui demandant d’annuler le verdict rendu par une cour selon lequel Google a violé les droits d’auteur d’Oracle sur les API Java lorsqu’il a développé son système d’exploitation Android. Selon l’EFF, cela a des répercussions profondes sur l'innovation en matière de développement de logiciels, de concurrence et d'interopérabilité. Dans sa requête, l’EFF espère que la Cour Suprême comprendra l’enjeu et pourra remettre la loi sur le droit d'auteur informatique sur les rails.

L’affaire ne date pas d’aujourd’hui. Elle a commencé en 2010 après le rachat de Sun Microsystems par Oracle. Ce dernier a intenté un procès à Google alléguant que le géant de la recherche a piétiné les brevets et les droits d’auteur relatifs au langage Java. Une première décision de justice a été rendue en faveur de Google, mais Oracle a fait appel de cette décision. Un nouveau verdict a été rendu, mais cette fois en faveur d’Oracle, statuant que l’usage de Google des API Java ne relève pas d’un usage loyal (fair use). La Cour a déclaré que Google les a utilisées dans un but commercial.

Toutefois, les API peuvent-elles être protégées par le droit d’auteur ? L’EFF considère que non et a adressé sa requête à la Cour Suprême du pays en soutien à Google, qui a également déposé un nouveau recours. « Dans un mémoire déposé aujourd'hui, l'EFF soutient que le Circuit fédéral, en statuant que les API étaient protégeables par le droit d'auteur, a ignoré un aspect clair et spécifique dans la loi sur le droit d'auteur qui exclut la protection du droit d'auteur pour les procédures, les processus et les méthodes de fonctionnement », a écrit l’EFF sur son site Web.


En effet, Google a toujours rejeté toute infraction dans l’affaire. Selon lui, les API ne devraient pas être protégées par le droit d’auteur parce qu’elles sont nécessaires pour écrire des programmes compatibles. Il estime d'ailleurs que si les premières entreprises de technologie avaient revendiqué de tels droits, le développement de nombreuses technologies dont nous disposons aujourd’hui aurait certainement été bloqué. Google a porté l'affaire à la Cour Suprême en janvier 2019. Cela a poussé Oracle encore une fois à ressortir ses vieux arguments.

L’EFF pense que les décisions en faveur d’Oracle sont dangereuses et erronées. Ainsi, l'organisation pense que si elles sont maintenues, elles continueront à mettre en danger la capacité des développeurs à créer tranquillement et librement des logiciels innovants qui bénéficient au public parce qu'ils peuvent être utilisés sur toutes les plateformes et dans tous les services. Selon Michael Barclay, le conseiller spécial de l'EFF, le fait de traiter les API Java comme des logiciels protégés par le droit d'auteur donne à Oracle un contrôle sans précédent sur le développement de programmes compatibles Java.

D’après Barclay, cette stratégie devrait permettre à Oracle de s’en mettre plein les poches. Pour lui, la loi sur le droit d'auteur vise à stimuler la créativité pour le bien public, et non à enfermer les développeurs dans un système de licence pour les aspects fonctionnels des logiciels. Il a aussi souligné que le Circuit fédéral n’a pas bien fait les choses, faisant une mauvaise interprétation de la loi. « Nous demandons instamment à la Cour Suprême d'appliquer correctement la loi sur le copyright dans ce cas, et de réparer ce que le Circuit fédéral a fait de mal », a-t-il déclaré.

D’un autre côté, Corynne McSherry, la directrice juridique de l’EFF a déclaré qu’au lieu de suivre la loi, le Circuit fédéral a décidé de la réécrire afin d'éliminer presque toutes les exclusions de la protection du droit d'auteur que le Congrès a inscrites dans la loi. « Les API ne sont pas soumises au droit d'auteur. La décision du Circuit fédéral a créé un dangereux précédent qui encouragera d'autres poursuites et rendra le développement de logiciels innovants d'un coût prohibitif. Heureusement, la Cour suprême peut et doit réparer ce gâchis », a-t-elle conclu.

Source : Electronic Frontier Foundation

Et vous ?

Quel est votre avis sur le sujet ?
Selon vous, les API devraient-elles être soumises au droit d'auteur ? Pourquoi ?
Si oui, quelles en seront les conséquences sur le développement logiciel ?

Voir aussi

API Java : Oracle déclare que l'infraction de Google a détruit ses espoirs sur le marché des smartphones et demande le rejet de l'appel de Google

API Java et Android : Google demande à la Cour suprême de définir les limites du droit d'auteur dans le code. À quel moment peut-il être protégé ?

Procès sur les API Java : Google envisage de porter l'affaire à la Cour Suprême à la suite au rejet de son appel par le Circuit Fédéral

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

Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 15/01/2020 à 14:05
Citation Envoyé par gabriel21 Voir le message
Si la cour suprême confirme la condamnation, ce sera un sacré bronx aux USA et par ricocher dans le monde.
Et l'on pourra sans doute prédire la fin rapide de Java. Car il est fort probable que s'appuyant sur cette décision, Oracle fera du chantage aux entreprises utilisant Java sans support, pour qu'ils payent. Ce qui poussera de nombreux éditeurs à recoder dans un autre langage leurs applications métiers pour éviter de nouveaux procès.
Dans ce cas, reste à savoir quel langage sera le grand gagnant de cette lutte aux dividendes...
Encore une fois, ça n'a rien a voir : le procès de Google concerne uniquement la réimplémentation compmlète de la bibliothèque Java, pas son utilisation.
L'utilisation du langage Java ou même une implémentation de Java basée sur l'OpenJDK sont complètement libres et garanties.

Citation Envoyé par TidiusFF Voir le message
Oracle traite déja Java comme un boulet mort depuis des années.
C'est un peu l'inverse Oracle a mis des moyens pour relancer Java, là ou Sun n'avait pas réussi. Par contre il a pris beaucoup de retard par rapport à la concurrence.
8  0 
Avatar de gabriel21
Membre habitué https://www.developpez.com
Le 15/01/2020 à 14:43
Citation Envoyé par Uther Voir le message
Encore une fois, ça n'a rien a voir : le procès de Google concerne uniquement la réimplémentation complète de la bibliothèque Java, pas son utilisation.
L'utilisation du langage Java ou même une implémentation de Java basée sur l'OpenJDK sont complètement libres et garanties.
Il semblerait qu'une partie des juristes de mon client ne soit pas tout à fait d'accord avec cette affirmation. Et ce serait la raison, pour ce que je comprends, du support des principales sociétés informatiques de Google. Dont certaines sont des concurrents.
Oracle pourrait du jour au lendemain faire fermer OpenJDK sur la même base que Google, vu que la communauté propose une ré-implémentation de la bibliothèque Java. Même si pour l'instant l'accord entre la communauté et Sun qui ne semble pas avoir été dénoncé par Oracle.
De plus si l'utilisation de java est effectivement pour l'instant gratuite, elle nécessite forcément l'utilisation d'une machine virtuelle Java. Or, le fond du problème est là, Oracle veut une licence valide et payante de la JVM (motifs de la plainte : droit d'auteur et brevet logiciel), incluant celle de Google. Et même à raison de quelques centimes par périphérique embarquant la JVM, vu le nombre de machine embarquant Java, la somme serait importante. Et je ne parle pas de la version entreprise...
3  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 16/01/2020 à 10:16
Citation Envoyé par gabriel21 Voir le message
Bien justement, il semblerait que si. Du moins, ce n'est pas clair.
Modifier la licence rétroactivement c'est impossible et c'est tout a fait clair.

Citation Envoyé par gabriel21 Voir le message
Rien n’empêche Oracle de refermer le code et d'interdire toute ré-implémentation des nouvelles spécifications, ce qui entraînerait de facto deux java l'un open source et l'autre breveté logiciel.
Ça, en effet, ça pourrait théoriquement arriver si on reconnait que l'interface d'une bibliothèque est affectée par les droits d'auteur.
Cependant :
  • ça pourrait arriver à tous les langages, pas uniquement à Java.
  • dans la pratique, Oracle ne s'y risquerait pas. L'OpenJDK est aujourd'hui une alternative complètement crédible au JDK d'Oracle, JakartaEE est contrôlé par la fondation Eclipse. S'ils font ça, c'est quasiment garanti que personne ne fera la transition vers les nouvelles versions Oracle du JDK.


Citation Envoyé par gabriel21 Voir le message
Et encore, si Google est condamné pour atteinte aux brevets logiciels et droits d'auteur, les cours pourraient considérer que la communauté open source est toute aussi condamnable.
Pour les droits d'auteurs, non, vu que la licence GPL de l'OpenJDK fait que Oracle fournit un droit irrévocable d'utiliser et de modifier le code publié sous cette licence. Le procès de Google a lieu parce que Java n'était pas open-source à l'époque du projet Harmony (qui a servi de base au SDK d'Android).
Pour les brevets c'est un problème différent qui a toujours existé sur tous les langages et dont l'issue de ce procès ne changera rien.

Citation Envoyé par gabriel21 Voir le message
Après, je ne suis pas spécialiste du droit, mais vu les moyens déployés par les GAFA et autres géants technologiques dans cette affaire, c'est que la réponse risque de modifier durablement le développement logiciel en cas de victoire finale d'Oracle.
Que l'issue du procès puisse modifier ce qui est faisable en développement logiciel, et que par conséquent ça inquiète dans le monde du développement, c'est clair. Le fait de ne pas pouvoir faire une implémentation tierce d'une bibliothèque sous la licence que l'on souhaite, est un vrai problème.
Par contre, ça ne posera pas de problème spécifique aux l’utilisateurs de Java.
3  0 
Avatar de floyer
Membre régulier https://www.developpez.com
Le 19/01/2020 à 20:39
Citation Envoyé par Steinvikel Voir le message
Si cette instance établie un précédent mettant les API sous droit d'auteur, alors toutes les futures implémentation le seront. Si c'est rétro-actif, toutes les précédentes implémentations le seront également. Ce qui est donc lourd de conséquences. ^^'
Mais tu m'as répondu d'aux USA, il n'y a pas de rétroactivité sur la législation, jurisprudence... =)
Si un tribunal juge les API protégés cela signifie qu’elle estime que la loi déjà applicable s’interprète de façon restrictive.

On ne peut pas vraiment parler de rétroactivité même si cela y ressemble s’il est question d’API postérieures à la loi. Le tribunal ne fait qu’interpréter la loi sous un certain angle et la jurisprudence implique que d’autres tribunaux devront prendre le même angle.
2  0 
Avatar de Steinvikel
Membre chevronné https://www.developpez.com
Le 19/01/2020 à 21:14
Citation Envoyé par gabriel21 Voir le message
Bien justement, il semblerait que si. Du moins, ce n'est pas clair. Rien n’empêche Oracle de refermer le code et d'interdire toute ré-implémentation des nouvelles spécifications, ce qui entraînerait de facto deux java l'un open source et l'autre breveté logiciel.
Il n'est pas permis dans le système actuel, de changer la licence d'un produit déjà publié, à moins de présenter une violation de licence, elle est alors révisée pour s'y conformer.
Exemple du 13 novembre 2009, avec Windows USB/DVD Download Tool : ..à l’entrée du week-end, la firme de Redmond a bien confirmé que du code protégé par la licence GPLv2 avait été utilisé dans son application. À ce niveau-là, Microsoft n’avait guère d’option : soit retirer définitivement le logiciel, soit le publier à nouveau, mais sous licence GPLv2 cette fois. Microsoft a choisi finalement la deuxième solution.
Si un éditeur décide de refermer son code, cela ne peut concerner que les futures versions. Dans l'exemple cité, c'est l'inverse qui s'est produit (son ouverture)... en fait, c'est souvent dans ce sens là que ça arrive.
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 15/01/2020 à 10:08
Citation Envoyé par Steinvikel Voir le message
Une question anodine :
En France, une décision de justice, ainsi qu'une loi (ratification, amendement, etc.), n'est pas rétro-actif ...est-ce le cas également aux USA ? ^^'
On dit qu'une loi n'est pas rétroactive dans le sens ou une décision de justice ne peut pas s'appliquer à des fait antérieurs à la ratification de la loi. C'est également le cas aux USA
Mais pour le coup je vois pas le rapport avec le sujet.
1  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 15/01/2020 à 17:02
Citation Envoyé par gabriel21 Voir le message
Il semblerait qu'une partie des juristes de mon client ne soit pas tout à fait d'accord avec cette affirmation. Et ce serait la raison, pour ce que je comprends, du support des principales sociétés informatiques de Google. Dont certaines sont des concurrents.
Le problème légal posé par ce procès, c'est de savoir si on a le droit de faire un implémentation tierce d'une bibliothèque en utilisant la même API. Si la cour suprême valide que l'interface d'une bibliothèque est couverte par le copyright, ça aurait en effet des conséquences néfastes comme je l'ai expliqué précédemment. Mais en ce qui concerne le cas de l'utilisation de Java pour développer des logiciels, il n'y aura pas d'impact.

Citation Envoyé par gabriel21 Voir le message
Oracle pourrait du jour au lendemain faire fermer OpenJDK sur la même base que Google, vu que la communauté propose une ré-implémentation de la bibliothèque Java. Même si pour l'instant l'accord entre la communauté et Sun qui ne semble pas avoir été dénoncé par Oracle.
Il n'y a jamais eu d'accord entre la communauté et Sun. L'OpenJDK a toujours appartenu à Sun / Oracle. Par contre il est publié sous licence GPL donc Oracle garantit un droit irrévocable d'utiliser le code des version publiés de l'OpenJDK comme bon nous semble.

Citation Envoyé par gabriel21 Voir le message
De plus si l'utilisation de java est effectivement pour l'instant gratuite, elle nécessite forcément l'utilisation d'une machine virtuelle Java. Or, le fond du problème est là, Oracle veut une licence valide et payante de la JVM (motifs de la plainte : droit d'auteur et brevet logiciel), incluant celle de Google. Et même à raison de quelques centimes par périphérique embarquant la JVM, vu le nombre de machine embarquant Java, la somme serait importante. Et je ne parle pas de la version entreprise...
Oracle veux faire payer Google qui avait une implémentation tierce de Java. Mais il ne peuvent pas modifier rétroactivement les licences des JDK et OpenJDK qu'il ont accordées.
1  0 
Avatar de bouye
Rédacteur/Modérateur https://www.developpez.com
Le 16/01/2020 à 12:56
Hum, pas sur les produits passés mais sur les produits futurs oui. Il me semble que RoboVM l'a fait après son rachat par Xamarin et avant que Microsoft ne termine le produit.
1  0 
Avatar de Steinvikel
Membre chevronné https://www.developpez.com
Le 15/01/2020 à 6:12
Une question anodine :
En France, une décision de justice, ainsi qu'une loi (ratification, amendement, etc.), n'est pas rétro-actif ...est-ce le cas également aux USA ? ^^'
0  0 
Avatar de frfancha
Membre éclairé https://www.developpez.com
Le 15/01/2020 à 7:26
Citation Envoyé par Axel Mattauch Voir le message
Prenons un exemple simple qui ne relève pas domaine du code et de la distinction code/ API.
Ben l'exemple de l'interface des machines à café à capsules bien connues...
Elle est protégée
0  0