Comment protéger un logiciel (brevet, droit d’auteur)

Présentation au sujet: "Comment protéger un logiciel (brevet, droit d’auteur)"— Transcription de la présentation:

1 Comment protéger un logiciel (brevet, droit d’auteur)
Paul Van den Bulck Avocat associé du Cabinet ULYS Chargé d’enseignement à l’Université Robert Schuman (Strasbourg)

2 Quand un logiciel est-il protégé par le droit d’auteur ?
Dualité de régime Loi du LPO Loi du LDA Programme d’ordinateur/le reste (cahier des charges, documentation, mode d’emploi,etc…)

3 B. Avantage de la protection par le droit d’auteur
Aucune formalité requise Durée de protection extrêmement longue C. Étendue de la protection Idées ? Éléments dictés par l’efficacité ? Éléments dictés par des facteurs externes ? Interfaces ?

4 - Droit d’auteur protège la forme pas l’idée :
Idées ? - Droit d’auteur protège la forme pas l’idée : “considérant que, en accord avec ce principe du droit d'auteur, les idées et principes qui sont à la base de la logique, des algorithmes et des langages de programmation ne sont pas protégés en vertu de la présente directive” - Algorithme : formule mathématique Interprétation du considérant 14 de la directive Mot/phrase

5 Éléments dictés par l’efficacité ?
- doctrine de la fusion entre l’idée et l’expression - il n’y a qu’une seule façon d’exprimer une idée Éléments dictés par des facteurs externes ? - doctrines « des scènes à faire » (techniques standardisées de programmation largement partagées) Interfaces ? - « éléments de tout programme destinés à autoriser la communication de celui-ci avec les autres éléments (1) d’un système informatique et (2) avec l’usager ». - protection si original dans l’expression

6 II. Quels actes ne constituent pas des contrefaçons ?
L’exception pour utilisation L’exception de la copie de sauvegarde L’exception pour observation, étude et test L’exception pour décompilation

7 A. L’exception pour utilisation
« En l’absence de dispositions contractuelles particulières, ne sont pas soumis à l’autorisation du titulaire les actes visés à l’article 5, a) et b), lorsque ces actes sont nécessaires pour permettre à la personne ayant le droit d’utiliser le programme d’ordinateur, de l’utiliser d’une manière conforme à sa destination, en ce compris la correction d’erreurs. » Décompilation pour correction d’erreur serait comprise : quid en pratique ? B. L’exception de la copie de sauvegarde « la personne ayant le droit d’utiliser le programme d’ordinateur ne peut s’en voir interdire la reproduction sous la forme d’une copie de sauvegarde pour autant que cette copie soit nécessaire à l’utilisation du programme » Pas d’exception contractuelle possible

8 C. L’exception pour observation, étude et test
« La personne ayant le droit d’utiliser le programme d’ordinateur peut, sans l’autorisation du titulaire du droit, observer, étudier ou tester le fonctionnement de ce programme afin de déterminer les idées et les principes qui sont à la base d’un élément du programme lorsqu’elle effectue une opération de chargement, d’affichage, de passage, de transmission ou de stockage du programme d’ordinateur qu’elle est en droit d’effectuer.» « Il est permis de regarder ce qu’il est permis de voir ! »

9 D. L’exception pour décompilation
Art. 7 § 1 « L'autorisation du titulaire des droits n'est pas requise lorsque la reproduction du code ou la traduction de la forme de ce code au sens de l'article 5 a) et b) est indispensable pour obtenir les informations nécessaires à l'interopérabilité d'un programme d'ordinateur créé de façon indépendante avec d'autres programmes et sous réserve que les conditions suivantes soient réunies: a) les actes de reproduction et de traduction sont accomplis par une autre personne jouissant du droit d'utiliser une copie d'un programme, ou, pour son compte, par une personne habilitée à cette fin; b) les informations nécessaires à l'interopérabilité ne lui sont pas déjà facilement et rapidement accessibles; c) les actes de reproduction et de traduction sont limités aux parties du programme d'origine nécessaires à cette interopérabilité.

10 § 2. Les dispositions du paragraphe précédent ne peuvent justifier que les informations obtenues en vertu de son application: a) soient utilisées à des fins autres que la réalisation de l'interopérabilité du programme d'ordinateur créé de façon indépendante; b) soient communiquées à des tiers, sauf si cela s'avère nécessaire à l'interopérabilité du programme d'ordinateur créé de façon indépendante; c) ou soient utilisées pour la mise au point, la production ou la commercialisation d'un programme d'ordinateur dont l'expression est fondamentalement similaire ou pour tout autre acte portant atteinte au droit d'auteur. §3 Le présent article ne peut recevoir une application qui cause un préjudice injustifié aux intérêts légitimes du titulaire du droit ou porte atteinte à l'exploitation normale du programme d'ordinateur.”

11 Disposition sans doute la plus complexe de la directive/loi
Processus : code objet vers code source Si pas accès au code source impossible de pratiquer l’interopérabilité .

12 Conditions spécifiques :
seuls les actes indispensables afin de se procurer les informations nécessaires à l’interopérabilité sont exemptés ; seule la personne ayant le droit d’utiliser une copie du programme (ou quelqu’un agissant pour son compte) peut accomplir des actes de décompilation ; la décompilation n’est autorisée que si les informations nécessaires à l’interopérabilité ne sont pas facilement et rapidement accessibles  (observations, tests, etc…); ces actes doivent être limités aux parties du programme d’origine nécessaires à l’interopérabilité, ce qui exclut au moins la décompilation de l’intégralité du programme ; les informations obtenues ne peuvent être utilisées à d’autres fins que l’interopérabilité du programme créé de façon indépendante; les informations découvertes ne peuvent être communiquées à des tiers, sauf lorsque cela s’impose en vue de réaliser l’interopérabilité; les informations collectées ne peuvent être employées pour concevoir un programme ‘fondamentalement similaire’ (sinon contrefaçon)

13 III. Brevet : une « légitime
III. Brevet : une « légitime ?» défiance vis-à-vis du brevet de logiciel « en tant que tel » Processus législatif européen (A) Le débat au fond (B)

14 A. Le processus législatif européen
Le Lancement des travaux sur la directive (février 2002) Un texte favorable au brevet de logiciel « en tant que tel » Les suites des travaux européens : L’hostilité du Parlement européen (septembre 2002) Le Conseil favorable au brevet de logiciel (mai 2004) - Une négociation était normalement prévue avec le Parlement Changement de majorité au conseil/demande du parlement de recommencer tous le processus/position « commune » du conseil 7 mars 2005 ! Réaction du parlement ?

15 B. Le débat sur le fond Le brevet de logiciel renvoie à une série de questions : juridiques théoriques et pratiques et surtout économiques et politiques

16 1. Invention et Information
Traditionnellement : invention = solution technique à un problème technique Est-ce conciliable avec la notion d’information contenue dans un logiciel ? Le problème : Que signifie la notion de « technique » ? Ce qui est fonctionnel n’est pas forcément technique…. un programme est-il nécessairement « technique » par sa forme ?

17 2. Invention et Programme
L’invention de produit ne pose pas de problème : association machine + logiciel = brevet classique Invention de procédé = brevet de logiciel « en tant que tel » Ce brevet pose encore plus problème : Réservation d’un enchaînement d’étapes mais pas l’écriture en tant que tel … Que va réserver exactement ce type de brevet ? L’absence de jurisprudence sur la contrefaçon de brevet de logiciel « en tant que tel » : un signe de la faiblesse de ce type de brevet ?

18 3. Des objections liées à la difficulté de la rédaction du brevet de logiciel « en tant que tel » 
Le logiciel est de l’information, il ne se décrit pas comme un dispositif matériel. Le brevet classique contient des revendications visant un processus matériel. Dans la pratique, on remarque des revendications  : Trop nombreuses : les brevets de logiciels sont volumineux. Trop extensives : les brevets de logiciels ferment des secteurs complets d’innovations

19 4. Les autres objections Le droit des brevets répond à des exigences précises sur le fond et sur la forme. Comment apprécier l’activité inventive et la nouveauté en matière de brevet ? Absence de culture de l’antériorité en matière de logiciel Comment apprécier l’activité inventive ? Difficile de savoir qui à fait quoi et à quelle date en matière informatique … Comment régler les problèmes liés à la coexistence d’un droit d’auteur et d’un brevet sur un même logiciel. Les deux instruments renvoient à des règles différentes ( champ d’application, titularité –cessions- et rémunération, contrat, durée, contrefaçon…)

20 5. De la fonction incitative du brevet en matière de logiciel ?
Un choix politique contreproductif ? Un instrument juridique complexe et cher ? : Nécessité de faire appel à un Conseil en P.Ind. Les recherches d’antériorité et l’existence d’une contrefaçon relèvent de l’expertise de spécialistes des brevets. Adaptation pour les petites entreprises ? Risque de blocage de la circulation de l’information relative aux logiciels  Un autre modèle de développement : le logiciel libre

21 V. Faut-il révéler le code source ?
Grande diversité des cas de figure Question d’espèce/de stratégie

22 & Questions Réponses Paul Van den Bulck (paul.vandenbulck@ulys.net)
Avocats associés au Cabinet ULYS ( Chargés de cours à l’université Robert Schuman (Strasbourg)