Comments for Breveter les logiciels, une (fausse) bonne idée?

Bonjour,

Je rejoins assez l’avis des commentateurs précédents. Je ne vais donc pas vanter les mérites des brevets en tant qu’incitant à l’innovation ni reprendre en détail les critiques émises à l’encontre du brevet de logiciel.
Les créateurs de logiciels désirent avoir la possibilité de protéger leur création par le biais d’un droit de la propriété intellectuelle. Bien. Pourquoi pas. Cela ne me pose en effet pas de problème qu’un concepteur de logiciel ait le choix d’opter pour un logiciel libre, à la disposition tous ou désire protéger son travail et s’assurer d’un retour financier.
Aux Etats-Unis, c’est le brevet qui protège les logiciels. Hélas, comme mentionné et argumenté ci-dessous, cela ne me semble pas être la protection la plus adéquate.
Dès lors, en tenant compte des critiques émises sur le brevet de logiciel, essayons de dégager une solution (partant du postulat que le droit d’auteur est insuffisant).
L’idée serait donc de créer un droit sui generis propre au logiciel. Mais quel serait son contenu ?

Selon moi, il faudrait tout d’abord prévoir une protection plus courte que celle prévue pour les brevets. En effet, la protection d’un maximum de 20 ans propre au brevet ne se révèle pas très tactique dans le milieu informatique où tous les jours, des progrès considérables sont réalisés. Je pense donc qu’une protection de 3 ans maximum serait suffisante afin de rencontrer, d’une part, les impératifs de rentabilité qu’attend le concepteur du logiciel, et, d’autre part, les progrès techniques qui pourraient rendre obsolète le brevet. Quant au risque de monopole, conservons cet élément du brevet et permettons au concepteur de le céder, le vendre,…

Un autre problème de taille, si pas le plus important, concerne l’appréciation du critère de nouveauté nécessaire pour l’obtention d’un brevet. En effet, contrairement à d’autres domaines, en matière de logiciel, aucune base de données n’existe. Il est donc extrêmement complexe voire impossible qu’un expert ou une même commission d’experts puisse, à ce jour, se targuer de posséder des connaissances à ce point poussées en matière de logiciels qu’il leur serait aisé d’analyser ce caractère nouveau.
A partir de là, comment parvenir à protéger un logiciel, si la complexité de ce dernier ne nous permet pas de pouvoir le décortiquer afin d’en avoir une vue détaillée et d’en apprécier les composantes nouvelles ? C’est, pour moi, l’argument principal pour lequel le brevet ne peut pas fonctionner pour les logiciels. Il nous faut, par conséquent, trouver un nouveau critère qui permettrait de conférer un droit au concepteur du logiciel en ne se basant pas sur la nouveauté, concept trop difficile voire impossible à appréhender dans notre cas.

Dès lors, pourquoi ne pas réfléchir en s’inspirant de la protection offerte par les dessins-modèles, la matière étant également assez technique et évoluant très rapidement. Les conditions à remplir pour obtenir cette protection sont la nouveauté et le caractère propre. Si cette première condition n’est pas transposable en matière de logiciel, cela serait peut-être possible pour la seconde. Un « observateur averti » (je reprends ici la notion qui se trouve dans le droit des dessins-modèles que j’adapte dans le domaine des logiciels mais m’interroge sur les compétences de ce dernier, à savoir doit-il s’agir d’un expert ou d’une personne lambda qui posséderait des connaissances poussées en la matière et serait capable d’émettre un avis objectif ?) qui serait donc chargé d’apprécier si l’impression technique d’ensemble (et non plus visuelle comme pour les dessins-modèles) diffère de tout logiciel divulgué avant la date de dépôt de demande d’enregistrement. De cette manière, le logiciel bénéficierait d’une protection spécifique, adaptée à ses caractéristiques.

Ajoutons à cela un élément non négligeable, qui me semble assez intéressant et qui existe pour les dessins-modèles, à savoir la possibilité d’enregistrer ou non. Transposons-la en matière de logiciels. Si le concepteur ne fait pas enregistrer son logiciel, celui-ci aurait alors un droit d’interdire la copie de ce dernier pour une durée mettons de 2 ans au vu de la rapide évolution de la matière. Endéans la première année, il lui serait néanmoins loisible de faire enregistrer son logiciel obtenant de la sorte une protection plus grande, à savoir que le droit d’exclusif de l’utiliser, et d’interdire à tout tiers la fabrication, l’offre, la mise sur le marché, l’importation, l’exportation,… Les avantages du non-enregistrement relevés par le Conseil européen en matière de dessins-modèles constatant que « cette forme de protection peut être utile dans des secteurs qui produisent d’importantes quantités de dessins ou de modèles destinés à des produits qui ont souvent une vie économique courte » sont en effet parfaitement transposables dans le domaine des logiciels. Cela serait peut-être une solution à creuser.

Ce ne sont là que des pistes de réflexion, mes compétences en matière de logiciel étant limitées, je n’appréhende certainement pas tous les tenants et aboutissants de cette matière techniquement complexe. Je tiens seulement à signaler que penser la protection des logiciels au départ du brevet ne me semble peut-être pas l’angle le plus adapté et qu’il serait peut-être intéressant d’aller voir du côté des dessins-modèles qui concernent, eux aussi, une matière très technique et évoluant extrêmement rapidement.

Après les très nombreux et intéressants commentaires juridiques sur le sujet, je souhaiterais prendre les choses sous un autre angle. Un angle différent de l’étudiant en droit qui regarde le sujet au travers du seul prisme juridique.

Etant moi-même programmeur amateur, quand on me parle de breveter des logiciels j’ai l’impression de tenir une discussion sortie d’une œuvre de Ionesco. Je m’explique.

Au niveau des fondements, des sources les plus profondes, programmer c’est d’une certaine façon parler à une machine dans un langage qu’elle comprend. On lui dit de réaliser telle opération quand on lui donne telle information et de moduler sa réaction opérative si l’information qui lui est donnée comporte telles ou telles caractéristiques. Ainsi, tout comme de véritables langues, la programmation a son vocabulaire, sa syntaxe, ses « règles grammaticales ». Toujours dans le même ordre d’idée, tout comme le langage humain, on a développé différentes langues dans le monde : Pascal, Cobol, C, SQL, Oz, Prolog. Ces langages utilisent se caractérisent par un mode comme dans notre propre langage : impératif, déclaratif, etc.

Dès lors, quand on me parle de breveter un logiciel, j’ai l’impression qu’on me demande si oui ou non on devrait breveter Le Père Godot de Balzac ou Les Identités Meurtrières de Malouf.
A mon sens, les programmes ne sont que l’expression des idées et de la volonté d’un programmeur ou d’un ensemble de programmeurs. Cela peut être une expression artistique (jeux vidéo), utilitaire (bureautique), haineuse (virus)… Des expressions littéraires humaines ou nécessaires pour mieux mener notre vie personnelle, professionnelle, sociale (par exemple Facebook est d’une certaine façon tellement complexe qu’on devrait le considérer comme un programme on-line).
Dès lors, de la même façon que l’on ne peut concevoir de breveter l’utilisation d’une langue humaine, on ne devrait pas concevoir de breveter un logiciel qui n’est que l’expression d’idées d’un programmeur dans un langage peu conventionnel pour le commun des mortels qu’est un langage de programmation.
De surcroît, comment pouvoir affirmer que tel logiciel est brevetable, si comme le souligne à juste titre monsieur Tancré dans les commentaires infra un logiciel est une construction dont chaque strate est le fruit du travail des autres ? Tout programmeur dans le monde entier a commencé par ce qu’on appelle dans le milieu un « Hello World ». Il s’agit du premier code que tous programmeur a tapé au moins une fois dans sa vie :
#include
void main(void)
{
printf(“Hello world !!\n”);
}

Ce sont là les jalons d’un langage appelé minimalement « C » qui sont exposés dans ces quelques lignes. De là, va découler tout le développement du langage et l’apprentissage du programmeur pour réaliser des choses aussi variées qu’un traitement de texte ou un logiciel de calcul de trajectoires balistiques, tout comme notre professeur de primaire nous a appris l’alphabet, la conjugaison, la grammaire et quelques mots de vocabulaire.

A partir de là, on reprend régulièrement des scripts ou des morceaux de code qu’on a trouvé intéressants dans un logiciel ou dans un autre, un peu comme des citations. On emprunte des figures de styles, on emprunte des mots, des idées… Tout comme le font les auteurs, que ce soient des auteurs de romans ou de discours politiques ; tout comme nous le faisons en tant qu’êtres humains dans la vie… car tout ce que nous faisons comme êtres humains dans notre vie de tous les jours n’est que la répétition de choses que nous avons apprises, vues, entendues, senties… Ainsi, peut-on parler d’invention quand on sait que Microsoft Word 2010 a pris énormément de Word 2007 qui lui-même prend des versions antérieures de Word, qui elles-mêmes ont pris la logique du logiciel Wordperfect de la compagnie Corel, qui elle-même prend ses sources dans la machine de traitement de texte Wang de 1977 ??? Je ne le pense pas. Il y a de l’innovation dans les idées, mais fondamentalement cela ne reste que l’expression « d’un auteur » qui parle un drôle de langage…

Dès lors comment l’article 2 et suivant de la loi sur les brevets du 28 mars 1984 pourrait trouver un écho dans ces œuvres que sont les logiciels ? A vrai dire la seule vraie invention dans le monde logiciel, c’est l’invention de la programmation elle-même ! Or, qui peut se dire propriétaire de la programmation ? De la même façon, qui pourrait se dire propriétaire de la langue française ? La langue n’est finalement qu’un objet vivant, qui se maintient et se développe au travers de chaque personne qui l’utilise… ce constat vaut également pour la programmation selon mon opinion… S’il fallait octroyer un brevet, il faudrait l’octroyer à l’ensemble des programmeurs qui par l’exercice de leur art ont maintenu et développé les langages de programmation et alors, de ce fait même, ce brevet n’aurait plus aucun intérêt.

Ceci est un commentaire qui tient plus de la philosophie juridique que du droit intellectuel, mais que serait le droit sans réflexions sur l’essence de ce qu’on essaye de protéger ? 😉

La propriété intellectuelle est un pilier fondamental du monde industriel ainsi que de l’innovation technologique. De nos jours, une nouvelle forme d’industrie gagne du terrain sur le marché, plus précisément l’industrie informatique. Le monde informatique, caractérisé par l’exploitation de nombreux logiciels, comporte également de grandes inventions ainsi qu’un désir perpétuel d’innover. Par conséquent, dans la logique de la tradition industrielle il est donc naturel de breveter les logiciels pour gratifier le travail de l’inventeur, obtenir un contrôle juridique et commercial sur l’invention et en tirer un profit optimal. Ceci semble être le raisonnement classique que tout éditeur de logiciel sera tenté d’appliquer, toutefois, une grande controverse existe au sujet de la brevetabilité des logiciels.

Les Etats-Unis de même que le Japon, ont suivi ce raisonnement et brevettent leurs logiciels depuis plus de 10 ans. Néanmoins, au bout de quelques années, il s’est avéré que ce brevetage a engendré des effets contraires aux effets recherchés dans le système de brevets, citons ; la réduction de la diffusion des connaissances, ainsi que la diminution de l’innovation et par conséquent de la concurrence. Analysons de plus près, les effets de breveter ou de ne pas breveter un logiciel.

L’algorithme ainsi que le code source sont les éléments clefs dans le domaine de la brevetabilité des logiciels. Le code source, comme l’indique Mr. Brahy dans son article, est déjà automatiquement protégé par le droit d’auteur, mais ceci ne freine pas la possibilité d’une protection plus accrue par un brevet. Un éditeur qui choisit donc de ne pas breveter son logiciel dispose dès lors de deux choix, soit il garde son code source secret, soit il le rend public.

L’éditeur d’un logiciel qui ne brevette pas ce dernier et qui opte pour le secret de son code source, est généralement un petit éditeur ne sachant pas se permettre l’obtention d’un brevet, mais souhaitant malgré tout ne pas divulguer son ‘know-how’ aux concurrents sans acquérir de contrepartie. Car sans ce code source, personne n’est apte à analyser le logiciel sans devoir repasser impérativement par toutes les étapes cognitives que l’éditeur a surmontées.
Ne pas répandre son code source, permet également à l’éditeur du logiciel d’échapper à des contrefaçons potentielles dans le domaine du droit d’auteur ainsi que de voiler d’éventuelles reproductions qu’il aurait commis dans la création de son logiciel. Ceci protège efficacement les éditeurs, mais n’est pas favorable pour les consommateurs.

Dans l’intérêt des consommateurs, il faut un éditeur qui ne brevette pas son logiciel et qui choisit en plus de révéler son code source. Ceci permet dès lors à ces consommateurs, s’il leur semble nécessaire, de corriger ou de faire corriger par un tiers les défauts avérés du logiciel. Pour les petits éditeurs ceci leur procure également la possibilité d’offrir à leurs utilisateurs une plus grande sécurité ainsi que de leur garantir une certaine continuité du système logiciel. Le dévoilement du code source prône également l’émergence de standards, qui sont nécessaires comme base sur lequel appuyer son innovation. Allant encore plus loin, sont les logiciels libres, qui poussent vivement leurs clients à participer à l’amélioration du logiciel à travers un processus collectif.

On peut ainsi déduire que, dans un contexte sans brevet logiciel, l’éditeur choisit soit de favoriser son savoir-faire au- delà de son envie de contenter les consommateurs, et par conséquent de ne pas dévoiler son code source, soit il préfère plaire à ses consommateurs et contribuer au développement de standards et communique de ce fait son code source.

De l’autre côté de l’image, on a les logiciels qui sont munis d’un brevet. Les éditeurs bénéficiant d’un logiciel breveté peuvent donc publier leurs codes sources sans devoir craindre une imitation de leurs connaissances techniques ou informatiques, incorporées dans leurs logiciels, puisque celles-ci sont entièrement protégées par le brevet y rattaché.
Néanmoins, si on creuse plus profondément dans le raisonnement, on constate toutefois que l’application de brevet au logiciel, renforce la volonté de garder secret sa connaissance, car un éditeur qui rend public son code source, ouvre les portes à d’éventuelles contrefaçons. Un éditeur A, qui révèle son code source sera désavantagé par rapport à un éditeur B, qui ne publie pas son code source, lorsque ce deuxième l’attaque en contrefaçon concernant certains principes de fonctionnement de son logiciel, car le premier n’aura pas les moyens d’obtenir légalement le code source de B puisqu’il le garde secret.

C’est un cercle vicieux qui n’incite donc pas vraiment les éditeurs à breveter leurs logiciels et surtout pas les petits éditeurs qui n’ont pas les moyens financiers de libérer de grandes sommes pour les consacrer à des procédures judiciaires, contrairement aux grands éditeurs qui détiennent d’amples brevets et surtout d’excellentes équipes de juristes spécialisés, ce qui augmente d’autant plus leurs chances de contrer la plupart des contentieux en contrefaçon de brevets.

Les grandes entreprises se contentent dès lors de breveter les procédés de base nécessaires pour établir un logiciel informatique plus complexe et multiplient ainsi leurs possibilités de poursuivre un concurrent en contrefaçon. Dès lors ne détourne-t-on pas complètement le but initial du brevet, qui est de prôner l’innovation et non de la ralentir par de nombreuses procédures judiciaires ?

Il existe donc indiscutablement une controverse concernant la brevetabilité des logiciels. Selon qu’on est un petit éditeur, un développeur indépendant ou un grand éditeur, ou selon qu’on est consommateur on non, notre opinion sur la brevetabilité diffère fortement. Comme l’affirme Mr. Brahy dans son article, il revient dorénavant à l’Office européen des brevets de prendre une décision définitive concernant la validité de ces brevets logiciels pour mettre fin à cette insécurité juridique.

Sources:

JUNG, A. ( 2006), La brevetabilité des logiciels, Centre d’Etudes Internationales de la Propriété Industrielle, Strasbourg.

SMETS, J.P. (2000), Stimuler la concurrence et l’innovation dans la société de l’information.
Brevet ou droit sui generis : quelle protection convient-il d’envisager pour les logiciels et les autres inventions immatérielles ?, Foundation for a Free Information Infrastructure. Disponible à : http://ladoc.ffii.fr/brevet.pdf (Consulté le 15/04/2012)

VOLLE, M. (2005). « Faut-il breveter les logiciels ». Disponible à : http://www.volle.com/opinion/brevet.htm (Consulté le 15/04/2012).
Cncpi , « Le brevetabilité des logiciels ». Disponible à : http://www.cncpi.fr/iaa145-45-brevetabilite-logiciels-brevet-logiciel-innovation-licence.htm?level=(Consulté le 15/04/2012).