Oracle c. Google : finalement, pas de contrefaçon par les emprunts aux API de Java par ceux d’Android




On rapporte cette semaine que la Cour suprême des États-Unis vient de rendre une décision mettant un clou final dans le cercueil de la fameuse poursuite-fleuve relative à l’usage de composantes liées à Java dans la plateforme Android. Dix ans plus tard, ce litige est finalement parvenu à une conclusion donnant raison à la société Google.

Comme on s’en souviendra, en développant Android et ses API, Google avait imbriqué dans ceux-ci ce qu’elle avait préalablement vu dans les API de Java (aujourd’hui propriété d’Oracle), incluant la structure, la séquence et l’organisation du code de ces composantes logicielles, etc. Le but était alors de créer des applications capables d’interagir avec le langage de programmation Java, ce que Google était parvenu à faire en créant des milliers de lignes de code largement inspirées («copiés», de dire plus tard Oracle) des API liés à Java.

La décision en question vient infirmer la décision de première instance quant à la question de savoir si l’usage de code de la composante logicielle en question (l’API) s’avérait acceptable en vertu de la doctrine de «fair use». C’est maintenant confirmé, rien n’empêchait (juridiquement) Google d’utiliser comme elle l’a fait des éléments de l’interface de programmation (en anglais «API») de Java, en construisant son système d’exploitation Android.

Pour le tribunal, un AP I s’avère être une créature un peu particulière dans laquelle le code est en quelques sortes fusionné à des idées. Pour lui, ici le but de Google en utilisant l’API était de permettre à des programmeurs Java de développer des applications destinées à être exécutées sous Android, sans copier plus que requis pour y arriver. En somme, l’exercice ne dépassait pas ce qui s’avère acceptable en droit, bien qu’il implique une part de reproduction.

Selon la Cour suprême américaine, l’ensemble des quatre facteurs indiquant qu’un usage s’avérerait acceptable parce qu’équitable donne raison à Google dans cette affaire. Ce faisant, on élargit le facteur impliquant les cas où l’usage a transformé l’œuvre («transformative use») en acceptant que l’usage de l’API en question sur la plateforme destinée aux appareils mobiles (Android) nous permette de conclure être ici en présence d’une transformation issue de ce changement du contexte d’utilisation de l’œuvre en question.

Au final, on adopte donc la position que même en présumant que le code de déclarationdeclaring code», en anglais) de l’API en question est protégé par des droits d’auteur (pas quelque chose d’évident, selon plusieurs), le fait d’utiliser ce code sans permission du détenteur des droits, par rapport à Android, ne dépassait pas les bornes.

Plusieurs s’entendent pour dire que la décision rate une bonne occasion de clarifier le traitement juridique à donner aux critères d’évaluation de ce qui constitue de la contrefaçon de composantes logicielles, particulièrement quand la copie implique une copie non littérale, notamment quant à celles qui sont purement fonctionnelles.

À tout événement, l’affaire est désormais bien close, après trois procès différents et deux appels, sans parler d’un coût de quelques dizaines de millions de dollars.

Indication de sources, marques et logiciels: quand une visite à votre boutique d’applis préférée devient un jeu de roulette russe

Le site LifeHacker demeure l’un de mes classiques en fait de vie numérique et des mille trucs qu’on peut toujours trouver pour mieux faire, plus vite, etc. J’y tombais hier sur un article recommandant d’éviter les magasins d’applis ou d’ajouts logiciels pour fureteur (comme le Chrome Web Store), lorsqu’on peut. Bien que ces répertoires de composantes logicielles soient parfois inévitables, le fait est qu’il s’avère souvent dangereux d’y télécharger des outils logiciels à moins de faire preuve de vigilance, notamment parce qu’il est si facile pour les escrocs d’y placer des maliciels déguisés en de véritables produits utiles et désirables.

La société AdGuard rapportait récemment que près de 300 ajouts logiciels distribués par l’entremise du magasin d’ajouts destinés à suppléer aux fonctionnalités du fureteur Chrome auraient été installés par des dizaines de millions d’internautes insouciants ou incapables de les distinguer des véritables composantes qu’ils cherchaient à installer. La statistique démontre l’existence d’un problème bien réel.

Le problème vient notamment du fait que les sociétés hébergeant les boutiques d’applis (par ex. Google et Apple) ont souvent un travail difficile de filtrage à faire quand on les contacte pour placer un produit logiciel sur leur plateforme. Au-delà de l’analyse technique, on a souvent un travail ardu à faire quant au nom de l’appli, puisque l’habitude est souvent de donner à des applis similaires des noms qui se ressemblent, souvent liés à la fonction du produit. L’article de LifeHacker donne l’exemple d’une recherche récente sur le Chrome Web Store quant à un ajout («add-on») précis, un produit réel nommé «Adblock», copié par d’autres maliciels déguisés récemment retirés par Google:

  • Ad-block for YouTube,
  • A-blocker,
  • UBlocker,
  • AdBlock — Stop Ad on every Site,
  • Adblocker-X,
  • StopAds, etc.

En pratique, si un internaute a un souvenir imparfait du nom (ou du logo) de la composante qu’il cherche, il pourra très bien éprouver des difficultés à discerner le vrai du faux au moment de cliquer pour l’installer. Facile à comprendre à quel point l’usager moyen (pressé et peu sophistiqué) a toutes les chances de se tromper au moment d’autoriser une composante sur son appareil ou son fureteur. Le problème est bien réel, pas de doute, et il ne s’agit pas non plus du genre de problème susceptible d’être enrayé à court terme.

Il est drôle de constater à quel point le droit des marques semble absent ici, lui qui doit régler ce genre de problème dans le vrai monde. Quand on ne peut plus se fier à une marque comme indicateur de source, on sait qu’on est en territoire similaire à celui du Far West, pas de doute.

En pratique, on nous recommande donc de toujours demeurer sur nos gardes au moment de trouver ou d’installer des applis et des ajouts logiciels, en vérifiant chaque fois si ce qu’on trouve correspond à 100% à ce qu’on cherchait, sans trop se fier à la marque, au nom ou au logo affiché dans la boutique. On recommande aussi d’éviter de se fier à la description du produit, qui sera habituellement falsifiée de toute façon si la composante est piégée. Au final, il est préférable d’obtenir toute composante directement du producteur de celle-ci, sans intermédiaire; on évitera ainsi d’être berné au passage alors qu’on se trouve en boutique. D’ailleurs, rappelons que les critiques affichées et provenant supposément des usagers sont aussi une mauvaise source d’information, puisqu’elles sont si faciles à trafiquer pour les fraudeurs.

Google en est à tester une fonctionnalité de logos vérifiés afin de valider l’identité des entreprises expéditrices de courriels à des comptes Gmail

Le site engadget révèle que Gmail comprendrait bientôt une fonctionnalité de logos vérifiée pour les entreprises qui désirent afficher leur logo «officiel» dans leurs communications légitimes expédiées à des comptes Gmail. On espère ainsi rendre la vie plus difficile aux faussaires de tous genres expédiant de faux messages prétendant provenir d’entreprises légitimes. (Forbes avait aussi un bon article à ce sujet récemment.) L’initiative ressemble au concept utilisé sur certains réseaux sociaux, par lequel on donne un indicateur visuel du fait qu’un compte duquel provient du contenu soit associé à un émetteur dont on a validé l’identité ou la légitimité. Le but de ce genre de dispositif s’avère notamment de réduire la possibilité de tentatives de fraude ou de faux messages, tels que ceux qui sont, par exemple, expédiés lors de tentatives d’hameçonnage. Comme l’explique l’article d’engadget, une fois le système en place, les entreprises légitimes pourront obtenir la validation (l’authentification) de leur logo officiel par Google, dont le système Gmail sera dès lors configuré (grâce au système d’authentification des expéditeurs DMARC) pour n’afficher cette version officielle que dans des courriels provenant réellement de l’entreprise en question. Le système réduirait ainsi les faux messages en permettant aux internautes de plus facilement identifier les courriels provenant effectivement de telle ou telle organisation, d’une façon conviviale et sans analyse technique. On comprend que, si le test pilote s’avère concluant et que le système est effectivement enclenché, le système fonctionnera grâce au contrôle qu’a Google sur le mode de livraison des courriels à ses usagers Gmail, permettant d’appliquer à tous les messages un filtre de validation avant de les livrer ou afficher à ses usagers. On comprend que, si le test pilote s’avère concluant et que le système est effectivement enclenché, le système fonctionnera grâce au contrôle qu’a Google sur le mode de livraison des courriels à ses usagers GMail, permettant d’appliquer à tous les messages un filtre de validation avant de les livrer ou afficher à ses usagers.