[Traduit de l'anglais]

Solutions du problème des brevets logiciels

Conférence donnée au Locatelli Center, Université de Santa Clara, en novembre 2012  (vidéo,  métadonnées)


Andrew Chen : Merci, Eric.

Je m'appelle Andrew Chen. J'enseigne le droit des brevets à l'Université de Caroline du Nord et dans une vie antérieure j'étais professeur d'informatique théorique.

J'ai le rôle le plus facile aujourd'hui : présenter deux personnes qui n'ont pas besoin de l'être. Richard Stallman, on le sait, est le fondateur du mouvement du logiciel libre, le cofondateur de la League for Programming Freedom (Ligue pour la liberté de programmer), l'architecte logiciel en chef du projet GNU et l'auteur d'Emacs, qu'il a défini comme un éditeur de texte mais aussi comme un mode de vie. Ce dont je conviens volontiers puisque j'ai écrit ma thèse en utilisant son programme.

Dr Stallman a decidé de ne pas participer au streaming en direct aujourdhui. Il explique que l'utilisation du streaming en ligne requiert l'utilisation du plugin Silverlight de Microsoft, ce qui oblige les gens à utiliser un logiciel privateur. Dr Stallman considère qu'inciter les gens à faire ça n'est pas bien. Il voudrait que vous sachiez qu'il a l'intention, plus tard, de rendre disponible un enregistrement de sa présentation au format Ogg Theora ou WebM.

Dr Stallman.

[applaudissements]

Richard Stallman : S'il vous plaît, est-ce que les techniciens peuvent confirmer que la diffusion est coupée ?

OK, je pense que c'est une confirmation.

Pourquoi les brevets logiciels sont-ils mauvais ? Ou plutôt les « brevets sur des idées informatiques », comme à mon avis nous devrions vraiment les appeler. La plupart des gens, quand vous dites « brevets logiciels », pensent qu'il est question de breveter un programme spécifique. Vous savez tous, j'en suis sûr, que ce n'est pas ce que font ces brevets, mais la plupart des gens ne le savent pas. Donc, pour essayer d'éviter les malentendus, je les appelle « brevets sur des idées informatiques ».

Quoi qu'il en soit, la raison pour laquelle ils sont mauvais est qu'ils privent les gens de la liberté d'utiliser leurs ordinateurs comme ils l'entendent et d'effectuer leurs tâches informatiques comme ils le souhaitent, liberté que chacun doit posséder. Ces brevets sont un danger pour tous les développeurs de logiciel comme pour leurs utilisateurs et nous n'avons aucune raison de le tolérer. Aussi devons-nous protéger le logiciel contre les brevets. Le logiciel a certes besoin d'être protégé, mais c'est contre les brevets.

Cependant la plupart des gens n'en savent pas assez sur les effets des brevets pour comprendre pourquoi les brevets qui restreignent les logiciels sont nocifs. La plupart des gens pensent que les brevets sont comme les copyrights, ce qui n'est pas vrai du tout. Tout ce qu'ils ont en commun tient dans une phrase de la Constitution et cette similarité est si ténue et si abstraite qu'elle n'a rien à voir avec leurs conséquences pratiques.

Donc, la dernière des choses à faire est d'utiliser le terme « propriété intellectuelle », qui confond non seulement ces deux lois, mais un tas d'autres lois disparates et non apparentées qui n'ont même pas en commun une seule phrase de la Constitution avec les deux premières. Ce terme est source de confusion chaque fois qu'il est utilisé et il y a huit ans j'ai décidé que je ne devais plus l'employer ; je ne l'ai jamais utilisé depuis. Son usage est étonnamment facile à éviter, car en général on l'utilise pour la seule raison que c'est chic. Et une fois que vous avez appris à résister à ça, c'est facile comme bonjour ; vous vous contentez de parler d'une loi en particulier, vous l'appelez par son nom et vous faites une phrase cohérente et claire.

Je dois expliquer aux gens les effets des brevets et leur montrer que ce ne sont pas du tout les mêmes que ceux des copyrights. Un bon moyen est de procéder par analogie. Qu'est-ce qu'on peut dire des programmes ? Eh bien, que ce sont des œuvres de grande envergure, avec un grand nombre d'éléments qui doivent tous interagir pour donner le résultat désiré. De quoi peut-on aussi dire ça ? D'un roman, d'une symphonie. Imaginez que les gouvernements européens du 18e siècle aient eu l'idée farfelue de promouvoir le progrès de la musique symphonique par un système de « brevets sur les idées musicales ». Toute idée musicale exprimable par des mots aurait ainsi pu être brevetée. Un motif mélodique aurait pu être breveté, ou bien une série d'accords, un schéma rythmique, un schéma de répétitions dans un mouvement, l'utilisation de certains instruments alors que le reste de l'orchestre ne joue pas et un tas d'autre idées musicales qui ne me viennent pas à l'esprit, mais qui viendraient peut-être à celui d'un compositeur.

Imaginez maintenant qu'on est en 1800, que vous êtes Beethoven et que vous voulez écrire une symphonie. Vous vous rendez compte qu'il est plus difficile d'écrire une symphonie en ne risquant pas un procès que d'écrire une bonne symphonie. Vous vous en seriez sans doute plaint et les détenteurs des brevets auraient dit « Oh, Beethoven, tu es simplement jaloux parce que nous avons eu ces idées avant toi. Tu n'as qu'à chercher quelques idées bien à toi. » Beethoven est bien sûr considéré comme un grand compositeur parce qu'il a eu beaucoup d'idées nouvelles. Mais pas seulement ; il savait aussi les mettre en œuvre de manière effective, c'est-à-dire en les combinant avec beaucoup d'idées connues, de sorte que ses morceaux ne choquaient qu'au début mais qu'ensuite on s'y habituait. Ils n'étaient pas étranges et incompréhensibles au point de susciter le rejet. Ils choquaient le public pendant quelque temps, puis celui-ci s'y habituait et maintenant nous n'y voyons plus rien de choquant parce que nous sommes habitués à ces idées. Cela prouve qu'il les a bien utilisées.

Donc l'idée que n'importe qui pourrait, ou devrait, réinventer la musique à partir de zéro est absurde. Même Beethoven ne pourrait le faire et il serait idiot de demander à quelqu'un d'essayer. C'est pareil en informatique. C'est comme une symphonie qui met en œuvre beaucoup d'idées musicales à la fois. Mais la difficulté n'est pas de choisir un tas d'idées, c'est de les mettre en œuvre toutes ensemble en utilisant des notes. C'est pareil avec le logiciel. Un grand programme va mettre en œuvre des milliers d'idées à la fois. Mais ce qui est difficile, ce n'est pas de choisir quelques idées, c'est de toutes les combiner et que ça fonctionne correctement.

Les « brevets sur les idées informatiques » font obstacle à cette lourde et difficile tâche en promouvant des ressources que nous avons à profusion de toute manière. C'est donc un système mal conçu, qui prétend nous fournir une aide dont nous ne voulons pas, au prix d'énormes problèmes.

Ce dont nous avons besoin est de nous débarrasser du problème. Quel est ce problème ? C'est que les brevets constituent une menace pour les développeurs et les utilisateurs. Ils les mettent en danger. Comment l'empêcher ? Eh bien, l'un des moyens est de ne pas délivrer de brevets portant sur les logiciels. Cela fonctionne si c'est appliqué dès le début. Si un pays n'a jamais délivré de tels brevets, son système de brevets ne menace pas le logiciel. OK, c'est une bonne solution. Mais elle n'est pas applicable si le pays a déjà délivré des centaines de milliers de brevets logiciels.

J'ai proposé que les constitutions disposent explicitement que les privilèges des brevets puissent être réduits aussi bien qu'augmentés ; qu'ils ne soient en aucune façon la propriété de quelqu'un, mais des privilèges octroyés par le gouvernement et pouvant être modifiés à volonté. Après tout, si la loi permet au gouvernement de les augmenter, il est absurde d'en faire un cliquet à sens unique. Mais cela ne figure pas dans la Constitution des États-Unis.

Alors, qu'est-ce qu'on peut faire ? On peut demander aux tribunaux de décider que tout brevet restreignant le logiciel était invalide depuis l'origine et l'a toujours été ; cela les élimine tous. Cependant, on ne peut pas faire du lobbying pour ça. On ne peut pas dire aux fonctionnaires « Faites ceci parce que nous voulons que vous le fassiez. »

Si nous voulons une solution que nous puissions faire appliquer, qu'est-ce qu'il nous reste ? Eh bien, le seul moyen, à mon avis, est que le logiciel soit reconnu par la loi comme une « sphère de sécurité ». Si c'est du logiciel, on est en sécurité. Des circuits effectuant le même calcul seraient couverts par un brevet, mais si c'est du logiciel, alors on est en sécurité. Mais qu'est-ce que cela signifie « être du logiciel » ? Eh bien, c'est ce qui fonctionne sur une machine polyvalente, universelle. Donc on fait d'abord une machine universelle et ensuite on y insère le programme pour qu'il lui dise quoi faire. Si la seule fonction de la machine est d'être universelle, alors toute idée spécifique, brevetée, est implémentée par le programme.

C'est à ça que je veux arriver et j'essaie de distinguer ce cas d'une affaire comme Diamond v. Diehr où il y avait un brevet pour un système, une méthode de vulcanisation. Son application nécessitait un ordinateur, mais également du matériel à usage spécifique, pas une machine polyvalente, universelle, et ce matériel à usage spécifique était essentiel à la mise en œuvre de la technique brevetée. En fait, ce n'était pas une technique logicielle. Et j'ai lu un article de Pamela Samuelson dont l'argument était que la CAFC1 avait détourné cette décision ; en gros, qu'elle s'était trompée dans l'ordre des quantificateurs.2 La Cour suprême avait dit « le fait qu'il y a un ordinateur là-dedans ne le rend pas automatiquement non brevetable », et la CAFC avait déformé la phrase en « l'ordinateur le rend brevetable ».

Quoi qu'il en soit, on pourrait peut-être fonder quelque espoir sur les tribunaux, mais je propose une méthode qui distinguera d'une part les cas que nous devons protéger, et d'autre part les brevets sur des idées non informatiques affectant des systèmes qui pourraient être mis en œuvre au moyen d'un ordinateur quelque part à l'intérieur. Quels mots précis utiliser ? Eh bien, ce que j'ai pu trouver de mieux était : « logiciel fonctionnant sur du matériel informatique d'usage général ». Nous voulons certainement que cela couvre des choses comme les smartphones ; nous ne voulons rien exclure qui contienne un quelconque matériel à usage spécifique. Le téléphone portable contient évidemment du matériel spécialisé permettant de parler au réseau téléphonique, mais cela ne doit pas signifier automatiquement que tout ce qui fonctionne sur un téléphone portable est vulnérable aux brevets, parce que le téléphone est un ordinateur polyvalent que les gens utilisent pour toutes sortes de choses. Mais ma formulation « matériel informatique d'usage général » n'est peut-être pas la meilleure. Cela à mon avis demande à être étudié, parce que nous devons examiner chaque formulation possible et voir quels cas seraient protégés contre les brevets et lesquels seraient exposés, pour arriver à la bonne méthode.

Chaque fois que je suggère une méthode pour résoudre ce problème, la première chose que les gens essaient de chercher, c'est plutôt comment le résoudre à moitié. L'idée de résoudre le problème une fois pour toutes les choque parce qu'elle leur apparaît comme radicale. Ils pensent « Je ne peux pas militer pour quelque chose d'aussi radical qu'une solution vraiment complète de ce problème. Il faut que je cherche une solution partielle qui protégera seulement certains développeurs de logiciel. » Eh bien, c'est une erreur. C'est une erreur a) parce que cela ne ferait pas le travail complètement et b) parce que ce serait plus difficile à faire passer. Il y a beaucoup de développeurs de logiciel et ils sont tous menacés. Si nous proposons de les protéger tous, ils auront tous une raison de donner leur appui. Mais si nous proposons d'en protéger seulement quelques-uns, les autres diront « Cela ne me sert à rien, pourquoi m'y intéresser ? »

Donc proposons une vraie solution. D'autant plus que les solutions partielles tendent à être vulnérables au problème que Boldrin et Levine ont très bien décrit, à savoir qu'il est facile aux groupes de pression favorables aux brevets de repousser la limite si vous leur donnez une limite quelconque à repousser. Ceci, incidemment, est un avantage supplémentaire en faveur d'un changement dans les procédures judiciaires contre les gens plutôt que dans ce qui est brevetable. Parce que là, le critère est seulement « Quel genre de situation a-t-on ici ? » C'est plus difficile d'élargir ce critère, et s'ils essayaient, ce serait toujours dans un litige contre quelqu'un qui se battra pour ne pas l'élargir. Il est ainsi moins vulnérable à une distorsion qui le ferait passer de la restriction de substance qui était visée à l'origine à une exigence de fait portant sur la forme des demandes de brevets, ce qui tend à se produire quel que soit le type d'exigence concernant ce qui doit figurer dans ces demandes.

Bon, voilà.

[applaudissements]

Andrew Chen : Merci, Dr Stallman.


Notes de traduction
  1.   Cour d'appel pour le circuit fédéral.
  2.   Voir le calcul des prédicats.