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 : Google et Oracle seront entendus à la Cour suprême ce 7 octobre 2020
Dans l'épisode final d'une affaire qui pourrait avoir de lourdes conséquences sur l'industrie du développement logiciel

Le , par Stéphane le calme

16PARTAGES

16  0 
Mercredi le 7 octobre 2020, la Cour suprême entendra des plaidoiries dans l'une des décisions les plus importantes de la décennie en matière de droits d'auteur sur les logiciels : trancher sur les conclusions de 2018 d'une cour d'appel selon lesquelles Google a violé les droits d'auteur d'Oracle lorsque Google a créé une implémentation indépendante du langage de programmation Java. Plus largement, l'affaire pourrait décider du statut de copyright des interfaces de programmation d'application, avec d'énormes implications pour l'industrie du logiciel.

Une interface de programmation d'application est le ciment qui unit les systèmes logiciels complexes. Jusqu'en 2014, il était largement admis que personne ne pouvait utiliser la loi sur le droit d'auteur pour restreindre l'utilisation des API : une perspective qui a favorisé l'interopérabilité des logiciels.

Puis, en 2014, le Federal Circuit Appeals Court a rendu une décision explosive en décidant le contraire. Pour le contexte, Oracle avait poursuivi Google, arguant que Google avait violé les droits d'auteur d'Oracle en ré-implémentant des API à partir du langage de programmation Java. Depuis, l'affaire fait son chemin devant les tribunaux, le Federal Circuit Appeals Court étant parvenu à une deuxième décision controversée en 2018.

« L'approche du Federal Circuit va bouleverser l'attente de longue date des développeurs de logiciels selon laquelle ils sont libres d'utiliser les interfaces logicielles existantes pour créer de nouveaux programmes informatiques », a écrit Google dans sa pétition de 2019 demandant à la Cour suprême d'entendre l'affaire.

James Grimmelmann, spécialiste du droit d'auteur à l'Université Cornell et ancien développeur de logiciels, est d'accord avec cela. « La décision du Circuit fédéral menace la vitalité continue de l'innovation logicielle », a-t-il déclaré en 2019.

Si les API peuvent être restreintes par le droit d'auteur, alors chaque programme informatique important pourrait être un véritable champ de mines prêtes à exploser devant les tribunaux. Grimmelmann prévient que les droits d'auteur d'API pourraient facilement donner lieu à des trolls d'API : les entreprises qui acquièrent les droits d'auteur d'anciens logiciels, puis poursuivent les entreprises qui ont construit leur logiciel en utilisant ce qu'elles supposaient être des normes ouvertes. Les droits d'auteur des API pourraient également entraver l'interopérabilité entre les plateformes logicielles, car les entreprises seront obligées de créer leurs logiciels en utilisant des normes délibérément incompatibles pour éviter des tracasseries juridiques.

Les éditeurs de logiciels et les groupes de droits numériques ont présenté ces arguments au Federal Circuit à deux reprises (une fois en 2014 et de nouveau en 2018) sans succès. Aujourd’hui, les avocats de Google auront l'occasion de persuader la Cour suprême que le Federal Circuit s'est trompé. Les enjeux sont importants, à la fois pour Google et Oracle en particulier, mais également pour l'industrie du logiciel au sens large.


Google évoque un cas des années 1990 concernant les menus de feuilles de calcul

Le Federal Circuit a rendu deux décisions majeures dans la bataille juridique de Google avec Oracle, et il s'est rangé du côté d'Oracle à deux reprises. Dans la première décision, le Federal Circuit a annulé une décision de jugement selon laquelle les API ne pouvaient pas être protégées par le droit d'auteur. L'affaire a ensuite été renvoyée au tribunal de première instance pour décider si l'utilisation de l'API par Google était autorisée par un usage loyal.

Le tribunal de première instance (sous la direction du même juge averti en technologie qui avait précédemment statué que les API ne devraient pas du tout être protégées par des droits d'auteur) a décidé que l'utilisation de Google était équitable. Oracle a fait appel et, en 2018, le Federal Circuit s'est de nouveau rangé du côté d'Oracle, décidant que l'utilisation de Google n'était pas juste.

Un principe fondamental de la législation sur le droit d’auteur est que la protection des œuvres de création ne s’étend à aucune « idée, procédure, processus, système, méthode de fonctionnement » contenu dans l’œuvre. C'est la raison, par exemple, pour laquelle les agences de presse sont libres de se rapporter mutuellement. Pour être plus précis, le texte d'un article de presse est protégé par le droit d'auteur, mais n'importe qui est libre de décrire l'information contenue dans un article de presse dans ses propres mots.

Cette ligne entre une idée et son expression est particulièrement cruciale pour les logiciels. L'un des cas les plus importants en l'espèce était Lotus c. Borland. Au début des années 1990, Lotus a poursuivi Borland, accusant la société d'avoir déchiré la structure des menus du logiciel de feuille de calcul Lotus 1-2-3 dans le propre tableur Quattro de Borland.


Transition vers Quattro

Pour aider les utilisateurs expérimentés de Lotus 1-2-3 à faire la transition vers Quattro, Borland avait inclus une interface d'émulation Lotus (une version du logiciel qui dupliquait précisément la structure de menu de Lotus 1-2-3). Lotus a soutenu que cette copie servile violait ses droits d'auteur, et le tribunal de première instance a rendu un verdict en sa faveur.

Mais la Cour d'appel du premier circuit n'était pas d'accord. Dans une décision historique de 1995, la cour d'appel s'est rangée du côté de Borland, jugeant que la structure des menus Lotus était une « méthode de fonctionnement » (et donc en dehors de la protection du droit d'auteur).

« Nous pensons que le "mode de fonctionnement" fait référence aux moyens par lesquels une personne fait fonctionner quelque chose, que ce soit une voiture, un robot culinaire ou un ordinateur », a estimé le tribunal. « La hiérarchie des commandes de menu Lotus fournit les moyens par lesquels les utilisateurs contrôlent et utilisent Lotus 1-2-3 ».

Notamment, la hiérarchie des menus n'était pas seulement l'interface utilisateur de Lotus 1-2-3; c'était une API primitive à part entière. Lotus 1-2-3 permettait aux fonctions de menu d'être appelées à l'aide des raccourcis clavier de ses menus. Une séquence de touches peut être enregistrée sous forme de macro, essentiellement un simple programme informatique. La duplication de la hiérarchie des menus Lotus 1-2-3 permettait aux utilisateurs d'utiliser leurs anciennes macros Lotus 1-2-3 sur Quattro sans modification.

Google fait valoir que la logique de la décision Lotus de la Cour d'appel du premier circuit peut être appliquée directement à son différend avec Oracle. Selon Google, les appels d'API Java sont des « méthodes de fonctionnement » pour la plateforme Java exactement de la même manière que les éléments de menu de Lotus 1-2-3 étaient des méthodes de fonctionnement pour le logiciel de tableur.

Le problème pour Google est que toutes les cours d'appel n'ont pas suivi l'approche du premier circuit dans l’affaire Lotus. La Cour suprême a en fait accepté d'entendre un appel de la décision Lotus dans les années 1990, mais, avec un juge absent de l'affaire, l’affaire a été bloquée en Haute Cour (quatre juges penchaient en faveur de Lotus et quatre juges penchaient en la faveur de Quatro). Un résultat qui a permis de faire prévaloir la décision de la cour inférieure, mais qui n’était pas suffisant pour rendre la décision contraignante pour les autres cours d'appel. Depuis lors, d'autres cours d'appel ont développé des approches différentes qui ne sont pas forcément bien alignées avec le précédent Lotus.


Les API protégées par des droits d'auteur pourraient provoquer le chaos dans l'industrie du logiciel

Bien que les tribunaux n'aient pas été unanimes sur la meilleure façon d'appliquer la loi sur le droit d'auteur aux API (et ne l’étaient d’ailleurs pas avant les premières décisions dans l’affaire opposant Oracle à Google), les pratiques de l'industrie du logiciel étaient assez bien établies avant que le Federal Circuit ne soit impliqué. Cela signifie que les enjeux de cette affaire sont assez élevés. Si le raisonnement du Federal Circuit est maintenu, il pourrait forcer des changements dramatiques dans la façon dont l'industrie du logiciel est organisée.

Il est courant que les développeurs de logiciels clonent les fonctionnalités des plateformes et des normes logicielles établies afin de s'assurer que leurs nouveaux produits sont compatibles avec ce qui existe déjà. Parfois, ce logiciel compatible est ensuite emballé dans des bibliothèques open source qui deviennent libres d'utilisation par d'autres, et il peut être combiné avec d'autres programmes pour produire des progiciels plus volumineux. Parce qu'il a été largement admis que les API ne peuvent pas être protégées par des droits d'auteur (ou du moins que les droits d'auteur ne sont pas susceptibles d'être appliqués) les entreprises ne se soucient pas d'utiliser des bibliothèques qui tirent parti d'API tierces qui pourraient appartenir à quelqu'un d'autre .

Les décisions Oracle du Federal Circuit signifient qu'il peut y avoir beaucoup de logiciels qui sont soudainement vulnérables aux réclamations pour violation de droits d'auteur parce qu'ils implémentent des API produites par des tiers.

Grimmelmann note que cela pourrait être un problème particulièrement grave dans le monde du cloud computing. « Si vous avez construit un service cloud, que dles gens ont écrit des clients et qu’un individu déclare 'nous détenons un droit d'auteur sur le rassemblement des arguments de cette fonction de cette façon', vous êtes foutu », a-t-il déclaré en 2019. « Vous ne pouvez pas changer cette API sans perdre de clients. Les possibilités de hold-up sont immenses ».

À long terme, soumettre les API à des restrictions de droits d'auteur pourrait également conduire à une balkanisation des normes logicielles. Méfiant à adopter des API appartenant à des rivaux, les entreprises seront plus susceptibles de développer leurs propres versions incompatibles de normes clés. Un amicus curiae déposé devant la Cour en 2018 par trois groupes de l'industrie du logiciel (Engine, App Alliance et GitHub) souligne que cela pourrait être particulièrement préjudiciable aux petits éditeurs de logiciels qui n'ont pas les ressources pour réimplémenter leurs produits en utilisant plusieurs normes incompatibles.

Et l'amicus curiae de 2018 de la Computer and Communications Industry Association souligne que cela pourrait également devenir un fardeau important pour la profession du développement de logiciels. Maîtriser un langage tel que Java nécessite beaucoup de temps et d'efforts. CCIA souligne qu'en essayant d'empêcher les implémentations indépendantes de Java, Oracle limite essentiellement les opportunités pour les développeurs Java. « Il est difficile de voir pourquoi les développeurs qui ont appris les API Java devraient rester captifs d'Oracle en raison d'un investissement dans l'apprentissage effectué par les développeurs et non par Oracle », a écrit CCIA.

Supreme court of the United States : Google v. Oracle America


Source : Cour suprême, Google

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 Axel Mattauch
Membre du Club https://www.developpez.com
Le 07/10/2020 à 14:37
Citation Envoyé par Stéphane le calme Voir le message
API Java : Google et Oracle seront entendus à la Cour suprême ce mercredi 7 octobre 2020,

Si les API peuvent être restreintes par le droit d'auteur, alors chaque programme informatique important pourrait être un véritable champ de mines prêtes à exploser devant les tribunaux. Grimmelmann prévient que les droits d'auteur d'API pourraient facilement donner lieu à des trolls d'API : les entreprises qui acquièrent les droits d'auteur d'anciens logiciels, puis poursuivent les entreprises qui ont construit leur logiciel en utilisant ce qu'elles supposaient être des normes ouvertes. Les droits d'auteur des API pourraient également entraver l'interopérabilité entre les plateformes logicielles, car les entreprises seront obligées de créer leurs logiciels en utilisant des normes délibérément incompatibles pour éviter des tracasseries juridiques.
Je crois urgent de breveter l'utilisation de l'eau comme solvant.

Selon ORACLE et le Federal Circuit, je comprends que les droits sur des API appartiendraient aux premiers qui ont dégainé.
Par suite, Java fourmille de plagiats.
Un seul exemple:
Code : Sélectionner tout
1
2
3
4
5
6
public class Nom_du_programme {
   public static void main (String args[]){
   	System.out.println("Hello World");
 
   }
}
  • utilisation de parenthèses pour passer des arguments
  • de virgules pour séparer les arguments
  • de guillemets pour définir une string
  • utilisation de points pour décliner une hiérarchie
  • de crochets, de points virgules ...


tout ça odieusement volé à des langages prédécesseurs .

Le grand malheur avec les juridictions US est le critère n°1 est le $, pas le bon sens.
5  1 
Avatar de PhilippeGibault
Membre actif https://www.developpez.com
Le 08/10/2020 à 17:51
Le problème de Oracle, ce n'est pas Google, c'est leur politique qui consiste à presser le citron client au détriment de l'innovation.

Leur cœur de métier, c'est la BDD, c'est même Oracle qui a inventé la BDD.

Seulement, la BDD oracle est la plus chère. Pire, quand on prend une licence Oracle, il faut prévoir les futurs frais d'avocats, car ils ont une tendance à être malhonnête sur les options.
Et ça peut vite finir en procès.

Et pendant qu'ils sont occupés à presser le citron client, les concurrents sont moins chers et meilleurs sur le cœur de métier.
https://blog.developpez.com/sqlpro/p...-la-difference

La différence entre Larry Ellison et Dieu, c'est que Dieu ne se prend pas pour Larry Ellinson.
4  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 09/10/2020 à 10:37
Citation Envoyé par darklinux Voir le message
Et puis Java commence à lassé , surtout avec des technologies équivalentes comme Python et javascript qui font peu ou prou les mèmes chose en open source , mème C++ a bougé !
Java est open-source et n'est pas vraiment équivalent a JavaScript ou Python notamment à cause de son typage bien plus strict.

Citation Envoyé par foxzoolm Voir le message
j'ai l'impression qu'Oracle n'a pas retenue la lecon/fessé d'openJDK...
Quelle fessée ? L'OpenJDK marché plutôt bien et reste un produit contrôlé par Oracle.
2  0 
Avatar de walfrat
Membre éprouvé https://www.developpez.com
Le 09/10/2020 à 10:55
Citation Envoyé par darklinux Voir le message
Et puis Java commence à lassé , surtout avec des technologies équivalentes comme Python et javascript qui font peu ou prou les mèmes chose en open source , mème C++ a bougé !
Heu, Java et tout l'écosystème autour est l'exemple même de la réussite de l'open source.

Et quand on veut faire des trucs qui marchent, on prend pas des trucs "fun et pas lassant", on prend même l'opposé, des trucs qui sont là depuis assez longtemps pour avoir été éprouvé et avoir suffisamment d'expérience dessus.

@archiqt : +1 sur la remarque, j'ajouterais cependant que les tailles de tuyauteries sont standardisés ils me semblent, du fait ces tailles n'appartiennent à personnes.
2  0 
Avatar de Axel Mattauch
Membre du Club 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 archqt
Membre éprouvé https://www.developpez.com
Le 07/10/2020 à 17:36
Balkanisation, eh ben l'ancien maire de lavallois-perret a encore de beaux jours devant lui. J'espère qu'il ne va pas encore s'en tirer
0  0 
Avatar de archqt
Membre éprouvé https://www.developpez.com
Le 08/10/2020 à 17:21
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.

Doit on payer le créateur du robinet ? pour pouvoir faire l'embout du tuyau qui pourra s'adapter dessus.
Et ensuite ? celui qui fait le robinet ne vendra peut être plus d'embout car les miens sont moins chers...Et au final celui qui a créé le produit se retrouve avec des copies qui seront moins chères.

Moi je dis que ce n'est pas évident. Dans le cas d'Oracle je me sentirais spolié.
1  1