La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Comment protéger un logiciel (brevet, droit dauteur) Paul Van den Bulck Avocat associé du Cabinet ULYS Chargé denseignement à lUniversité Robert Schuman.

Présentations similaires


Présentation au sujet: "Comment protéger un logiciel (brevet, droit dauteur) Paul Van den Bulck Avocat associé du Cabinet ULYS Chargé denseignement à lUniversité Robert Schuman."— Transcription de la présentation:

1 Comment protéger un logiciel (brevet, droit dauteur) Paul Van den Bulck Avocat associé du Cabinet ULYS Chargé denseignement à lUniversité Robert Schuman (Strasbourg)

2 I.Quand un logiciel est-il protégé par le droit dauteur ? A. Dualité de régime Loi du LPO Loi du LDA Programme dordinateur/le reste (cahier des charges, documentation, mode demploi,etc…)

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

4 Idées ? - Droit dauteur protège la forme pas lidé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 lefficacité ? - doctrine de la fusion entre lidée et lexpression - il ny a quune seule façon dexprimer 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) dun système informatique et (2) avec lusager ». - protection si original dans lexpression

6 II. Quels actes ne constituent pas des contrefaçons ? A. Lexception pour utilisation B. Lexception de la copie de sauvegarde C. Lexception pour observation, étude et test D. Lexception pour décompilation

7 A. Lexception pour utilisation « En labsence de dispositions contractuelles particulières, ne sont pas soumis à lautorisation du titulaire les actes visés à larticle 5, a) et b), lorsque ces actes sont nécessaires pour permettre à la personne ayant le droit dutiliser le programme dordinateur, de lutiliser dune manière conforme à sa destination, en ce compris la correction derreurs. » Décompilation pour correction derreur serait comprise : quid en pratique ? B. Lexception de la copie de sauvegarde « la personne ayant le droit dutiliser le programme dordinateur ne peut sen voir interdire la reproduction sous la forme dune copie de sauvegarde pour autant que cette copie soit nécessaire à lutilisation du programme » Pas dexception contractuelle possible

8 C. Lexception pour observation, étude et test « La personne ayant le droit dutiliser le programme dordinateur peut, sans lautorisation 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 dun élément du programme lorsquelle effectue une opération de chargement, daffichage, de passage, de transmission ou de stockage du programme dordinateur quelle est en droit deffectuer.» « Il est permis de regarder ce quil est permis de voir ! »

9 D. Lexception 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 linteropérabilité.

12 Conditions spécifiques : seuls les actes indispensables afin de se procurer les informations nécessaires à linteropérabilité sont exemptés ; seule la personne ayant le droit dutiliser une copie du programme (ou quelquun agissant pour son compte) peut accomplir des actes de décompilation ; la décompilation nest autorisée que si les informations nécessaires à linteropérabilité ne sont pas facilement et rapidement accessibles (observations, tests, etc…); ces actes doivent être limités aux parties du programme dorigine nécessaires à linteropérabilité, ce qui exclut au moins la décompilation de lintégralité du programme ; les informations obtenues ne peuvent être utilisées à dautres fins que linteropérabilité du programme créé de façon indépendante; les informations découvertes ne peuvent être communiquées à des tiers, sauf lorsque cela simpose en vue de réaliser linteropé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 ?» 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 : –Lhostilité 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 dinformation contenue dans un logiciel ? Le problème : Que signifie la notion de « technique » ? Ce qui est fonctionnel nest pas forcément technique…. un programme est-il nécessairement « technique » par sa forme ?

17 2. Invention et Programme Linvention 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 dun enchaînement détapes mais pas lécriture en tant que tel … –Que va réserver exactement ce type de brevet ? –Labsence 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 linformation, 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 dinnovations

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 lactivité inventive et la nouveauté en matière de brevet ? –Absence de culture de lantériorité en matière de logiciel –Comment apprécier lactivité inventive ? –Difficile de savoir qui à fait quoi et à quelle date en matière informatique … Comment régler les problèmes liés à la coexistence dun droit dauteur et dun brevet sur un même logiciel. –Les deux instruments renvoient à des règles différentes ( champ dapplication, 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 dantériorité et lexistence dune contrefaçon relèvent de lexpertise de spécialistes des brevets. –Adaptation pour les petites entreprises ? –Risque de blocage de la circulation de linformation 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 despèce/de stratégie

22 & Paul Van den Bulck Avocats associés au Cabinet ULYS (http://www.ulys.net)http://www.ulys.net Chargés de cours à luniversité Robert Schuman (Strasbourg) Q uestions R éponses


Télécharger ppt "Comment protéger un logiciel (brevet, droit dauteur) Paul Van den Bulck Avocat associé du Cabinet ULYS Chargé denseignement à lUniversité Robert Schuman."

Présentations similaires


Annonces Google