Discussion :

[archqt]

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é.

[Axel Mattauch]

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 ).

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.

[PhilippeGibault]

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.

[darklinux]

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é !

[walfrat]

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.

[foxzoolm]

j'ai l'impression qu'Oracle n'a pas retenue la lecon/fessé d'openJDK...

du coup... on continue a dev en java ou pas ?

[Uther]

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.

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.

[Stéphane le calme]

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 de la Cour suprême semblent prêts à autoriser les droits d'auteur sur les API

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)

[23JFK]

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.

[CaptainDangeax]

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.

Oh, il était discret mais je l'ai vu. Pas une seule ligne du code Unix d'origine dans Linux, tous ceux qui ont tenté un procès l'ont perdu et en sont mort, comme SCO par exemple. FreeBSD est reparti du code d'origine BSD parce qu'ils ont les droits dessus, et pour OSx/iOs, le code BSD est libre et autorise cette utilisation. Tu me feras 50 pompes

[CaptainDangeax]

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".

[floyer]

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.

[ddoumeche]

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.

Oracle n'a rien changé à la nature de la licence Java, et créer une machine virtuelle compatible Java à toujours nécessiter de prendre une licence. Google était d'ailleurs en négociation sur ce principe a l'époque mais ils ont décidé de passer outre, espérant sans doute que la crise liquide Sun.
je me permet de rappeler que le créateur du langage Jamas Gosling et l'architecte d'android eux même estiment que Google aurai du faire ainsi et payer des royalties, et ne l'ayant pas fait, Sun a fait faillite. Une histoire classique de piratage à échelle internationale.

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

Sco Unix a bien tenté la manœuvre il y a 15 ans, mais les droits appartiennent en réalité à Novell donc à IBM si ma mémoire est bonne.

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.

Non, une affaire ne peut pas être jugée deux fois

[Battant]

Sun a fait faillite. Une histoire classique de piratage à échelle internationale.

C’est quoi cette histoire de pirate de sun ?

Merci pour le renseignement

Salutations

Battant

[floyer]

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.

[darklinux]

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.

Oui , SCO revendiquai des droits qui n ' était pas les siens , financé en sous mains par Microsoft

[Uther]

Oracle n'a rien changé à la nature de la licence Java, et créer une machine virtuelle compatible Java à toujours nécessiter de prendre une licence.

Il y a une petite erreur qui fait toute le différence : prendre une licence Java donne le droit d'utiliser tout le code de l'implémentation de Sun comme base pour sa JVM, pas seulement les API. De plus cela donne accès au TCK qui sert a valider la conformité de la JVM, ce qui donne le droit d'utiliser le nom déposé Java.
Harmony qui a servi de base a Google a refait toute l'implémentation de la JVM de zéro et Google n'a jamais utilisé directement la marque déposée Java pour son SDK Android.

[defZero]

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.

[la.lune]

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.

Le language de programmation définit une manière de communiquer et des mots clés mais ne formule pas pour toi une ligne réutilisable et copiable. Est-ce que tu peux copier le français ou l'anglais ? Non. Mais tu peux copier n'importe quelle phrase écrite en français.

Une deuxième chose pour réfuter l'argument selon lequel la méthode Math.max est une méthode de fonctionnement, c'est comme passer son temps à comparer un objet Java avec un objet du monde réel qui partagent seulement le nom. D'autre part l y a une différence entre l'idée du fonctionnement de la méthode max qui prend pour argument deux entier pour retourner un des deux entiers et la classe java.lang.Math.

Code Java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
java.lang.Math;
 
public final class Math extends Object {
//....... 
public static int max(int a, int b) {
} 
//.... 
}

Ceci est du code qui sera compilé, une signature intégrale qui ne pourra jamais se formuler différemment sur le Java d'adroid, et une partie intégrante qui ne se séparera jamais du programme final. Alors en quoi ce programme ne pourra pas être protégé ? Est ce juste une méthode de fonctionnement ou une idée.
Il ne faut pas mélanger les idées de bon sens sur l'utilisation et l'intérêt de l'industrie du logiciel avec le fait que le code intergral est original.

[didoux]

Comme d'aucun le relevait en janvier, serait-ce la mort des émulations ?
Du moins, toutes celles pour lesquelles le truc émulé n'admet pas explicitement l'émulation, par sa licence.
Wine, Qemu, etc - potentiellement, même les futurs LibreOffice ne pourraient plus voir le jour. Du moins aux USA.

C'est les chinois qui vont se marrer - déjà que les brevets, ils s'en fichent pas mal; si en plus les USA s'ajoutent des contraintes de type droits d'auteur sur des API. Je doute par contre qu'en Europe on puisse en profiter (suffit de se souvenir du petchi avec le brevet sur le LZW - et c'était un brevet, durée de vie 20 ans, contrairement au droit d'auteur).

La cause n'est pas encore jugée, mais c'est piquant de voir qu'au même moment, le congrès s'offusque des pratiques anti-concurrentielles de ces géants.