comment protéger un logiciel (brevet, droit dauteur) paul van den bulck avocat associé du cabinet...

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

Paul Van den BulckAvocat associé du Cabinet ULYS

Chargé d’enseignement à l’Université Robert Schuman (Strasbourg)

paul.vandenbulck@ulys.net

WWW.ULYS.NET

I. Quand un logiciel est-il protégé par le droit d’auteur  ?

A. Dualité de régime

Loi du 30.06.94 LPO Loi du 30.06.94 LDA Programme d’ordinateur/le reste (cahier des charges,

documentation, mode d’emploi,etc…)

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 ?

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

É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

II. Quels actes ne constituent pas des contrefaçons  ?

A. L’exception pour utilisation

B. L’exception de la copie de sauvegarde

C. L’exception pour observation, étude et test

D. L’exception pour décompilation

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

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

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

§ 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.”

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é

.

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)

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)

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 ?

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

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 ?

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 ?

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

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

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

V. Faut-il révéler le code source ?

Grande diversité des cas de figure

Question d’espèce/de stratégie

&Paul Van den Bulck (paul.vandenbulck@ulys.net)• Avocats associés au Cabinet ULYS (http://www.ulys.net)• Chargés de cours à l’université Robert Schuman (Strasbourg)

Questions

Réponses