Eh non, la classification de Nice n’est pas ce qui compte en évaluant la confusion entre deux marques de commerce

Je tombais récemment sur une décision qui m’avait échappé l’an dernier : Obsidian Group Inc. c. Canada (Procureur général) (2020 CF 586) laquelle vient notamment confirmer qu’en matière de marques de commerce, au Canada, la classification de Nice (de produits et services) ne s’avère pas déterminante dans l’analyse de la confusion entre deux marques en présence. Eh oui, la classe dans laquelle ont été placés les produits ou services en association avec telle ou telle marque n’est tout simplement pas ce qui importe, du moins au moment d’évaluer le risque de confusion.

Comme on s’en souviendra, le Canada exige dorénavant que les demandes d’enregistrement de marques de commerce, au Canada, placent chacun des types de produits/services visés dans l’une des 45 classes de la classification créée par l’Arrangement de Nice, un traité auquel le Canada adhérait il y a deux ans. Depuis, toutes les nouvelles demandes doivent utiliser cette classification, les enregistrements existants étant en phase d’être aussi modifiés afin de l’utiliser. Cela dit, la jurisprudence vient s’harmoniser à celle de nombreux États étrangers, en minimisant l’importance réelle qu’a cette fameuse classification.

À ce sujet, ce qu’il faut comprendre, c’est que le paragraphe 6(2) de la Loi sur les marques de commerce prévoit qu’afin d’établir l’existence de confusion possible, la règle est la suivante:

L’emploi d’une marque de commerce crée de la confusion avec une autre marque de commerce lorsque l’emploi des deux marques de commerce dans la même région serait susceptible de faire conclure que les produits liés à ces marques de commerce sont fabriqués, vendus, donnés à bail ou loués, ou que les services liés à ces marques sont loués ou exécutés, par la même personne, que ces produits ou services soient ou non de la même catégorie générale ou figurent ou non dans la même classe de la classification de Nice.

Ainsi, bien qu’on puisse être tenté de ramener l’analyse de confusion à un exercice purement mécanique (de comparaison des classes de produits et services en présence), la Cour fédérale vient clairement rappeler dans cette décision que, comme c’est habituellement le cas à l’étranger, ce n’est pas la classe qui prime, du moins quand vient le temps de déterminer si deux marques portent à confusion l’une avec l’autre. Comme cela a toujours été le cas, c’est bien sur la liste des produits et services qu’il faut tabler, plutôt que de tenter d’accorder trop d’importance à la classe de Nice dans laquelle ils peuvent être insérés. Pour la Cour fédérale: « (…) ces classifications de Nice ne constituent pas des éléments fiables ou probants qui permettent d’établir l’existence d’une similitude ou de différences entre les produits et les services, et ce, même si elle en tenait compte.»

Ainsi, bien que la classification puisse s’avérer utile à certaines fins, le raisonnement du Bureau des marques, de la Commission des oppositions ou d’un tribunal ne devrait pas généralement se limiter à conclure qu’il existe ou n’existe pas de risque de confusion en se basant simplement sur les classes couvertes par les enregistrements de marques en présence.

L’important, c’est la liste des produits et services spécifiques qu’on couvre, pas le chiffre de la classe. Par exemple, bien que tous deux soient placés dans la classe 35, on peut aisément comprendre que des services de recrutement de personnel, d’une part, et des services de vente au détail de vêtements, d’autre part, ne se prêteraient pas aisément à de la confusion entre deux marques.

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.

Eh oui, la LCAP prohibant les pourriels au Canada s’avère bien constitutionnelle

La Cour suprême du Canada refusait officiellement cette semaine de réexaminer la décision de 2020 de la Cour d’appel fédérale (la «CAF») au sujet de la validité constitutionnelle de la loi canadienne anti-pourriel (surnommée la «LCAP», ou «CASL» en anglais). Ce faisant, la décision de la CAF se voit confirmée, à savoir que la loi en question n’excédait pas les compétences du gouvernement fédéral et s’avère donc bien valable, juridiquement.

Après s’être fait pincée pour violation de la LCAP, la société CompuFinder en avait appelé d’une décision du CRTC appliquant la loi en question, en réfutant du revers de la main la prétention de la défenderesse à l’effet que la loi visée s’avérait invalide. Plusieurs appels plus tard, nous avons désormais la confirmation que la LCAP se voulait un exercice valable des pouvoirs du Législateur fédéral canadien, en matière de commerce. Eh oui, la LCAP est bien là pour rester -désolé polluposteurs de tous acabits!

Comme on s’en souviendra, la LCAP interdit généralement à toute entreprise d’expédier des messages électroniques (tels des courriels ou des textos) à des destinataires n’y ayant pas consentit. Cette loi interdit aussi d’installer des composantes logicielles néfastes sur les appareils de tiers.

Je vous dirais que, bien que le refus de la Cour suprême d’intervenir ne s’avère pas une énorme surprise, au moins le spectre d’une invalidation de cette loi a désormais été écarté. Pas une mauvaise chose!