TOOLinux

Le journal du Libre

Microprogrammes ou le droit d’auteur sur les logiciels à l’épreuve de l’infiniment petit

lundi 2 septembre 2013

Les applications de ces logiciels sont pléthoriques. Par exemple, les logiciels internes des téléphones GSM, des agendas électroniques de poche, des lecteurs DVD, des distributeurs automatiques de billets et les terminaux de paiement électronique sont des logiciels embarqués. On peut encore les trouver dans les systèmes de guidage des aéronefs, dans les systèmes automatisés de surveillance, de contrôles d’accès, dans les robots et machines-outils.

Parmi ceux-ci, les microprogrammes forment une catégorie particulière.

Les microprogrammes sont des logiciels internes à des composants matériels, qui permettent le contrôle logique de ceux-ci. Exemple typique : le système d’injection de carburant dans le secteur automobile.

Les microprogrammes peuvent parfois jouer le rôle d’interface entre la partie purement logicielle et la partie matérielle d’un système électronique – par exemple, les drivers ou pilotes de périphériques.

Ces micrologiciels continuent d’être conçus et développés pour s’installer et s’exécuter sous des contraintes liées aux équipements dont ils sont censés régir le fonctionnement, lesquelles sont souvent particulièrement exigeantes.

Or, ces contraintes de développement soulèvent des questions importantes sur la protection de ces microprogrammes par le droit d’auteur en tant qu’œuvres logicielles.

  1. Les dernières évolutions jurisprudentielles de la protection de l’œuvre logicielle

Pour rappel, la protection du logiciel par le droit d’auteur est régie par les deux conditions de formalisation et d’originalité.

Une fois que l’œuvre est matérialisée, la condition déterminante de sa protection par le droit d’auteur est le fait que celle-ci porte « l’empreinte de la personnalité » de son auteur, selon la doctrine. Pour l’article 1 de la Directive 2009/24/CE du 23 avril 2009, pour être protégée, l’œuvre doit être « une création intellectuelle propre à son auteur ».

Ainsi, le code source d’un logiciel est en principe une œuvre protégée par le droit d’auteur, en tant que celui-ci reflète l’apport intellectuel propre, et l’effort personnalisé des développeurs qui l’ont conçu et réalisé.

Telle est la position de principe adoptée par l’arrêt d’assemblée plénière de la Cour de Cassation du 7 mars 1986, qui approuve les juges du fond ayant, pour établir le caractère original du logiciel, relevé que son auteur « avait fait preuve d’un effort personnalisé allant au-delà de la simple mise en œuvre d’une logique automatique et contraignante ».

La 4e chambre de la Cour d’appel de Paris déduit aussi l’originalité d’un programme du fait que celui-ci relève d’un « apport intellectuel important non commandé par les seules contraintes techniques » (CA Paris, 4e ch. 23 novembre 1994).

Après quelques revirements, la 1ère chambre civile de la Cour de cassation semble être revenue à cette position de principe en cassant un arrêt de la Cour d’appel d’Aix-en-Provence en date du 11 mai 2011, au motif que les juges du fond n’avaient pas recherché « en quoi les choix opérés témoignaient d’un apport intellectuel propre et d’un effort personnalisé de celui qui avait élaboré le logiciel litigieux, seuls de nature à lui conférer le caractère d’une œuvre originale protégée, comme telle, par le droit d’auteur » (voir également en ce sens la décision du Tribunal de grande instance de Paris, 19 déc. 2008, 07/01197).

Cette exigence de recherche en quoi les choix opérés par le programmeur témoignent d’un apport intellectuel propre et d’un effort personnalisé de celui-ci a encore été réitérée et confirmée par la première chambre civile de la Cour de cassation le 17 octobre 2012 (Cass. Civ. 1e, 17 octobre 2012, n° 11-21641).

A contrario de ces décisions, un apport intellectuel limité commandé par les seules contraintes techniques ne semblerait pas répondre à la condition d’originalité et par voie de conséquence ne semble pas protégeable par le droit d’auteur.

  1. L’applicabilité aux microprogrammes

Ceci requiert nécessairement de s’interroger sur les modalités selon lesquelles un microprogramme peut porter l’empreinte de la personnalité de son auteur.

En effet, les microprogrammes présentent le plus souvent une taille faible voire très faible pour leur stockage et leur exécution, le plus souvent sans distinction entre RAMs et ROM, associée à une programmation « bas niveau », c’est-à-dire à la fois très proche et très dépendant des caractéristiques techniques de la machine, le tout souvent dans un langage ne disposant que d’un jeu d’instructions restreint.

Dans ces conditions, quelle est la latitude créative d’un développeur de microcode tentant d’obtenir l’exécution d’une fonctionnalité particulière sur un composant matériel donné ?

Compte tenu des contraintes de taille et de puissance de calcul, l’optimisation du code apparaît indispensable, et à raison du caractère restrictif du jeu d’instructions, la programmation des fonctionnalités doit nécessairement se conformer à des règles strictes qui limitent de manière drastique sa liberté de choisir comment exprimer la fonctionnalité voulue dans le langage de programmation qu’il emploie.

Cette limitation très importante du champ de l’exercice de sa créativité par le développeur à raison de l’importance déterminante des contraintes techniques dans le processus de conception du microprogramme et d’écriture du microcode paraît antinomique avec la possibilité pour celui-ci de fournir un apport intellectuel propre reflétant un effort personnalisé.

Le microprogramme ne serait-il alors que la simple traduction technique d’une algorithmique, et en tant que tel non protégeable par le droit d’auteur ?

Historiquement, les premiers microprogrammes étaient codés « en dur », c’est-à-dire que gravés dans le silicium d’une mémoire morte (Read-Only Memory), ils demeuraient non modifiables et indissociables du composant matériel dont ils régissaient le fonctionnement (sauf à manier le fer à souder).

Compte tenu du caractère rudimentaire aussi bien qu’élémentaire de leurs fonctionnalités, il était possible de les assimiler à un simple paramétrage technique du composant matériel, voire à une modalité de fabrication dudit composant.

Or, les microprogrammes sont à présent le plus souvent stockés dans des EEPROM ou des mémoires flash, qui permettent leurs effacement, remplacement, modification et mise à jour. Dans ces conditions, ce sont donc devenus des logiciels indépendants de leur support matériel.

Ainsi, l’utilisateur d’un ordinateur personnel a désormais la possibilité de mettre à jour, modifier ou remplacer (« flasher ») le logiciel interne des cartes de son ordinateur.

Cette scission du matériel et du logiciel, du hard et du soft, plaide en faveur d’une interprétation de la nature du microprogramme comme étant une œuvre immatérielle protégeable indépendamment de son support.

En outre, avec l’évolution de la puissance des microprocesseurs, et l’augmentation de la capacité mémoire des composants, les programmes conçus pour de simples puces sont de plus en plus complexes, souvent plus gros et plus complets que des programmes d’ordinateur des années 80 – or ces derniers sont indiscutablement protégés par le droit d’auteur.

De fait, les fonctionnalités particulières d’une puce interne à un composant électronique sont à présent dépendantes du microprogramme installé sur celle-ci. Il ne s’agit donc pas de la simple transposition d’une algorithmique rudimentaire destinée à mettre en œuvre les fonctions logiques de cette puce.

Dans ces conditions, à partir de quel instant peut-on considérer qu’un microprogramme, malgré les contraintes techniques de sa réalisation, pourrait remplir la condition d’originalité d’une manière suffisante pour que celui-ci soit protégé par le droit d’auteur ?

- Ludovic SCHURR