{"partition": "head_middle", "source_domain": "www.framablog.org", "digest": "sha1:CP2EBYOCM3NJTJMKPYV2CKRL7PWKBN2A", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2014-15/000_00001.parquet"}
AccueilArchivesBest ofFramalangMentions légalesContact
Le danger des brevets logiciels par Richard Stallman
Logiciel Libre
Brevets,
Informatique,
RezoTIC,
Stallman,
Derniers commentaires Incontinentia Buttocks
Ya Eugène Polley qui est mort. Je ne dirais pas que c'est spécialement triste, il a vécu longtemps et il a fait ce que toute vie doit faire au service
Ah, que ça fait du bien de lire un texte long et précis sur un sujet où l'on est très ignorant: celà permet l'apprentissage et la compréhension,
@gerard: LOOOOOOOL ! Si tu as été à ce point lobotomisé par twitter et le web 2.0, je ne saurais que te conseiller de débrancher ton pc et d'ouvrir un
Derniers billets Prototypo : vos polices sur mesure
En marge de la préparation d’un événement organisé sur Lyon par la communauté Mozilla (dont on vous reparlera bientôt), nous avons eu le plaisir de
| Commentaires :
Si vous avez raté le début : Mozilla Webmaker est un ensemble d’outils ludo-éducatifs qui permettent à chacun de comprendre et de modeler le Web. Dans
Framasoft présente : Vosges Opération Libre, le 17 et 18 mai à Gérardmer
Le samedi 17 mai et le dimanche 18 mai à Gérardmer se déroulera un événement inédit dans la région Grand Est : Vosges Opération Libre. Il est ouvert
Tous les billets
Parmi les nombreux front où est engagé le Libre il y a celui complexe, épineux et crucial des brevets logiciels (dossier suivi notamment chez nous par l’April).
Voici la position de Richard Stallman[1], donnée lors d’une conférence en Nouvelle-Zélande.
Le danger des brevets logiciels
URL d’origine du document (GNU.org)
Richard Stallman - version du 24 avril 2012 - Gnu.org - Creative Commons By-Nd
(Traduction : Mathieu Adoutte en collaboration avec Framalang)
Retranscription de la conférence donnée par Richard M. Stallman le 8 octobre 2009 à l’Université Victoria de Wellington
SF : Je m’appelle Susy Frankel, et je tiens à vous souhaiter la bienvenue, en mon nom et en celui de Meredith Kolsky Lewis, à cette conférence organisée par le Centre de droit international des affaires de Nouvelle-Zélande. C’est à Brenda Chawner, membre de l’École de gestion de l’information de l’Université de Wellington (plutôt que du Centre que je viens de nommer, qui fait partie de la Faculté de droit) que revient le mérite d’avoir fait revenir Richard Stallman en Nouvelle-Zélande et d’avoir organisé son programme, notamment son étape de ce soir, ici à Wellington. Malheureusement, retenue par ses activités d’enseignement universitaire, elle n’a pu se joindre à nous.
C’est donc à moi que revient le plaisir de vous accueillir à cette conférence sur « Le danger des brevets logiciels ». Richard Stallman propose une série d’interventions sur différents sujets, et si nous avons choisi celui-ci, avec Brenda, c’est parce que pour la première fois dans l’histoire de la Nouvelle-Zélande, nous avons un débat qui tire un peu en longueur, mais qui est important, sur la réforme du droit des brevets, et vous êtes nombreux dans la salle à y participer. Cela nous a donc semblé particulièrement de circonstance. Merci, Richard, de nous avoir fait cette proposition.
On ne présente plus Richard Stallman. Néanmoins, pour ceux d’entre vous qui n’ont jamais entendu parler de lui, il a lancé le développement du système d’exploitation GNU. Je ne savais pas comment prononcer GNU, alors je suis allé sur Youtube (que ferions-nous sans Youtube)…
RMS : Oh, vous ne devriez pas promouvoir YouTube, ils diffusent leurs vidéos dans un format breveté.
SF : C’est vrai. Je l’évoquais seulement pour aborder ce point : doit-on prononcer G N U ou GNU ?
RMS : C’est sur Wikipedia. (GNU se prononce comme « gnou » en français)
SF : Oui, mais sur YouTube j’ai pu vous entendre le prononcer en direct. Le plus important néanmoins, c’est qu’il n’est pas propriétaire. Mais ce qui nous intéresse le plus, c’est que Richard a reçu de nombreuses distinctions pour son travail. Celle que je préfère, et par conséquent la seule que je mentionnerai, est le prix Takeda pour le progrès social et économique, et j’imagine que c’est bien de cela que nous allons parler ce soir. Je vous demande donc de vous joindre à moi pour accueillir Richard.
RMS : Avant tout, je voudrais préciser que l’une des raisons qui me poussent à boire ceci (une canette ou une bouteille de cola qui n’est pas du Coca-Cola) est qu’il y a un boycott mondial de la société Coca-Cola pour avoir assassiné des représentants syndicaux en Colombie. Consultez le site killercoke.org. Il ne s’agit pas des conséquences de la consommation du produit ; après tout, il en va de même pour beaucoup d’autres produits. Il s’agit de meurtre pur et simple. C’est pourquoi, avant d’acheter une boisson, lisez le texte en petits caractères pour vérifier si elle est fabriquée par Coca-Cola.
Je suis connu avant tout pour avoir initié le mouvement du logiciel libre et dirigé le développement du système d’exploitation GNU – bien que la plupart des personnes qui utilisent ce système croient à tort qu’il s’agit de Linux et pensent qu’il a été inventé par quelqu’un d’autre dix ans plus tard. Mais ce n’est pas de cela que je vais parler aujourd’hui. Je suis ici pour vous parler d’une menace juridique qui plane sur tous les développeurs, les utilisateurs et les éditeurs de logiciels : la menace des brevets – sur des idées informatiques, ou des techniques informatiques, c’est-à-dire des idées portant sur quelque chose de réalisable par un ordinateur.
Pour comprendre le problème, il faut tout d’abord prendre conscience du fait que le droit des brevets n’a rien à voir avec le copyright ; ce sont deux champs complètement différents. Vous pouvez être sûr que rien de ce que vous savez sur l’un ne s’applique à l’autre.
Par exemple, chaque fois que quelqu’un utilise le terme « propriété intellectuelle », il renforce la confusion, car ce terme mélange non seulement ces deux branches du droit, mais également une douzaine d’autres. Ces branches sont toutes différentes, et il en résulte que tout énoncé qui porte sur la « propriété intellectuelle » est parfaitement confus – soit parce que l’auteur de l’énoncé est lui-même confus, soit parce qu’il souhaite embrouiller les autres. Mais au final, que ce soit accidentel ou malveillant, cela accroît la confusion.
Vous pouvez échapper à cette confusion en refusant toute affirmation qui utilise ce terme. Pour porter le moindre jugement utile sur ces lois, il faut commencer par bien les distinguer, et les aborder séparément afin de comprendre quels sont réellement les effets de chacune, puis d’en tirer des conclusions. Je vais donc parler de brevets logiciels, et de ce qui se passe dans les pays qui ont autorisé le droit des brevets à restreindre les logiciels.
A quoi sert un brevet ? Un brevet est un monopole explicite sur l’utilisation d’une idée, attribué par un État. Tout brevet contient une partie intitulée les revendications, qui décrit précisément ce que vous n’avez pas le droit de faire (bien qu’elles soient généralement rédigées en des termes que vous ne pouvez probablement pas comprendre). Il faut lutter pour trouver ce que signifient exactement ces interdictions, et il peut y en avoir plusieurs pages en petits caractères.
Un brevet dure habituellement 20 ans, ce qui représente une durée relativement longue dans notre domaine. Il y a 20 ans, le World Wide Web n’existait pas – le secteur qui concentre aujourd’hui l’essentiel des usages de l’ordinateur n’existait pas il y a 20 ans. Et évidemment, si l’on compare avec l’informatique d’il y a 20 ans, tout ce que les gens y font est nouveau, au moins partiellement. Si des brevets avaient été déposés à l’époque, nous n’aurions pas le droit de faire toutes ces choses que nous faisons aujourd’hui ; elles pourraient toutes nous être interdites, dans les pays qui ont été suffisamment stupides pour mettre en place ce système.
La plupart du temps, ceux qui décrivent le fonctionnement du système de brevet sont aussi ceux qui en tirent profit. Qu’il s’agisse d’avocats spécialisés dans le droit des brevets, ou de personnes travaillant pour l’Office des brevets ou pour une mégacorporation, ils veulent vous convaincre que ce système est bon.
The Economist a un jour décrit le système de brevet comme « une loterie chronophage ». Si vous avez déjà vu une publicité pour une loterie, vous comprenez comment ça marche : ils s’attardent sur les infimes chances de gain, et ils passent sous silence l’immense probabilité de perdre. De cette manière, ils donnent systématiquement une représentation faussée de la réalité, sans pour autant mentir explicitement.
Il en va de même pour le discours sur le système des brevets : on vous parle de ce qui se passe lorsque vous avez un brevet dans la poche, et que de temps en temps vous pouvez le mettre sous le nez de quelqu’un en lui disant : « File-moi ton argent. »
Pour rectifier cette distorsion, je vais vous décrire l’envers du décor, le point de vue de la victime – ce qui se passe pour ceux qui veulent développer ou publier ou utiliser un logiciel. Vous vivez dans la crainte qu’un jour quelqu’un vienne et brandisse un brevet en vous disant : « File-moi ton argent. »
Si vous voulez développer des logiciels dans un pays qui reconnaît les brevets logiciels, et que vous souhaitez respecter le droit des brevets, que devez-vous faire ?
Vous pourriez tenter de faire une liste de toutes les idées qu’on peut trouver dans le programme que vous allez écrire. Mais évidemment, lorsque vous commencez juste à écrire le programme, vous n’avez aucune idée de ce qui va y figurer. Et même après avoir terminé le programme, vous seriez bien incapable de dresser une telle liste.
Cela tient au fait que vous avez conçu le programme avec une approche bien spécifique. Votre approche est déterminée par votre structure mentale, et de ce fait vous n’êtes pas capable de percevoir les structures mentales qui permettraient à d’autres personnes de comprendre le même programme ; il vous manque un œil neuf. Vous avez conçu le programme avec une structure spécifique à l’esprit ; quelqu’un d’autre qui découvre le programme pourrait l’aborder avec une structure différente, reposant sur d’autres idées, et vous n’êtes pas en mesure de dire quelles pourraient être ces idées. Il n’en reste pas moins que ces idées sont mises en œuvre dans votre programme, et que si l’une d’entre elles est brevetée, votre programme peut être interdit.
Imaginons par exemple qu’il existe des brevets sur les idées graphiques, et que vous vouliez dessiner un carré. Il est facile de comprendre que s’il existe un brevet sur les traits horizontaux, vous ne pouvez pas dessiner un carré. Le trait horizontal fait partie des idées mises en œuvre dans votre dessin. Mais vous n’avez peut-être pas pensé au fait que quelqu’un avec un brevet sur les coins pointant vers le bas peut aussi vous poursuivre, parce qu’il peut prendre votre dessin, et le tourner de 45 degrés. Et maintenant, votre carré a un coin vers le bas.
Vous ne pourrez donc jamais faire une liste de toutes les idées qui, si elles étaient brevetées, vous empêcheraient de réaliser votre programme.
Ce que vous pouvez faire, c’est tenter de lister toutes les idées déjà brevetées qui pourraient figurer dans votre programme. En fait non, vous ne pouvez pas, car les demandes de brevet sont gardées secrètes pendant au moins 18 mois, il est donc possible qu’un brevet ait été déposé à l’Office des brevets sans que personne n’en sache rien. Et il ne s’agit pas d’une hypothèse théorique.
Par exemple, en 1984 a été écrit compress, un programme permettant de compresser des fichiers en utilisant l’algorithme de compression de données LZW. À l’époque, il n’y avait pas de brevet sur cet algorithme de compression. L’auteur du programme avait récupéré l’algorithme dans un article de revue. C’était l’époque où nous pensions encore que les revues de recherche informatique servaient à publier des algorithmes pour que tout le monde puisse les utiliser.
Il a écrit ce programme, l’a publié, et en 1985 un brevet a été accordé pour cet algorithme. Le titulaire du brevet a été malin, il n’est pas allé tout de suite voir les gens pour leur dire de cesser d’utiliser le brevet. Il s’est dit : « Laissons-les creuser leur tombe un peu plus. » Quelques années plus tard, il a commencé à menacer les gens. Il est devenu évident que nous ne pouvions plus utiliser compress, j’ai donc demandé à tout le monde de proposer d’autres algorithmes que nous pourrions utiliser pour compresser des fichiers.
Quelqu’un m’a écrit pour me dire : « J’ai conçu un autre algorithme de compression qui marche encore mieux, j’ai écrit un programme, j’aimerais t’en faire cadeau. » Une semaine avant de le publier, je tombe sur la rubrique « brevets » du New-York Times, que je consulte rarement – je ne la regarde pas plus de deux fois par an – et je peux y lire que quelqu’un a obtenu un brevet pour une « nouvelle méthode de compression des données ». Je me suis donc dit qu’il valait mieux vérifier, et en effet le brevet prohibait le programme que nous nous apprêtions à publier. Mais cela aurait pu être pire : le brevet aurait pu être accordé un an plus tard, ou deux, ou trois, ou cinq.
Toujours est-il que quelqu’un a fini par trouver un algorithme de compression encore meilleur, qui a servi pour le programme gzip, et tous ceux qui avaient besoin de compresser des fichiers sont passés à gzip. Ça pourrait ressembler à un happy end, mais comme je vous l’expliquerai tout à l’heure, tout n’est pas si parfait.
Il n’est donc pas possible de savoir quels sont les brevets en cours d’examen, même si l’un d’eux peut entraîner l’interdiction de votre travail lorsqu’il sera publié. Mais il est toutefois possible de connaître les brevets déjà attribués. Ils sont tous publiés par l’Office des brevets. Le seul problème, c’est que vous ne pourrez jamais les lire tous, il y en a beaucoup trop.
Il doit y avoir des centaines de milliers de brevets logiciels aux États-Unis, les suivre tous constituerait une tâche écrasante. Vous allez donc devoir vous restreindre aux brevets pertinents. Et vous allez sans doute trouver de très nombreux brevets pertinents. Mais rien ne dit que vous allez les trouver tous.
Par exemple, dans les années 80 et 90, il existait un brevet sur le « recalcul dans l’ordre naturel » dans les tableurs. Quelqu’un m’en a demandé une copie un jour, j’ai donc regardé dans notre fichier qui liste les numéros de brevets. Puis j’ai ouvert le tiroir correspondant, j’ai récupéré la version papier du brevet, et je l’ai photocopiée pour la lui envoyer. Quand il l’a reçue, il m’a dit : « Je pense que tu t’es trompé de brevet, tu m’as envoyé un truc concernant les compilateurs. » Je me suis dit que peut-être le numéro de brevet était faux. J’ai vérifié, et de manière surprenante il faisait référence à une « méthode pour compiler des formules en code objet ». J’ai commencé à lire, pour voir s’il s’agissait du bon brevet. J’ai lu les revendications, et il s’agissait bien du brevet sur le recalcul dans l’ordre naturel, mais il n’utilisait jamais ce terme. Il n’utilisait jamais le mot « tableur ». En fait, ce que le brevet interdisait, c’était une douzaine de manières différentes d’implémenter un tri topologique – toutes les manières auxquelles ils avaient pu penser. Mais le terme « tri topologique » n’était pas utilisé.
Donc, si vous étiez par exemple en train de développer un tableur, et que vous ayez recherché les brevets pertinents, vous en auriez sans doute trouvé un certain nombre, mais pas celui-ci. Jusqu’à ce qu’un jour, au cours d’une conversation, vous disiez « Oh, je travaille sur un tableur », et que la personne vous réponde « Ah bon ? Tu es au courant que plusieurs autres entreprises qui font des tableurs sont en procès ? » C’est à ce moment-là que vous l’auriez découvert.
Certes, il est impossible de trouver tous les brevets en cherchant, mais on peut en trouver un bon nombre. Encore faut-il comprendre ce qu’ils veulent dire, ce qui n’a rien d’évident, car les brevets sont écrits dans un langage obscur dont il est difficile de saisir le véritable sens. Il va donc falloir passer beaucoup de temps à discuter avec un avocat hors de prix, à expliquer ce que vous voulez faire, afin que l’avocat puisse vous dire si vous avez le droit ou non.
Les détenteurs de brevets eux-mêmes sont bien souvent incapables de savoir ce que recouvrent leurs brevets. Par exemple, un certain Paul Heckel a conçu un programme pour afficher beaucoup de données sur un petit écran, et en s’appuyant sur une paire d’idées utilisées dans ce programme, il a obtenu deux brevets.
J’ai essayé un jour de trouver une manière simple d’exprimer ce que recouvrait la revendication numéro 1 de l’un de ces brevets. Je me suis rendu compte que je ne pouvais trouver d’autre formulation que celle du brevet lui-même. Or, j’avais beau tenter, il m’était impossible de me mettre cette formulation entièrement en tête.
Heckel non plus n’arrivait pas à suivre. Lorsqu’il a découvert HyperCard, il n’y a vu qu’un programme très différent du sien. Il ne s’est pas rendu compte que la formulation utilisée dans son propre brevet pouvait lui permettre d’interdire HyperCard. Mais ça n’a pas échappé à son avocat. Il a donc menacé Apple de poursuites. Puis il a menacé les clients d’Apple. Et finalement, Apple a conclu un arrangement avec lui, et comme cet arrangement est secret, il nous est impossible de savoir qui a vraiment gagné. Et ceci est juste un exemple parmi d’autres de la difficulté à comprendre ce qu’un brevet interdit ou non.
Lors d’une de mes précédentes conférences sur ce sujet, il se trouve qu’Heckel était présent dans le public. Arrivé à ce point de la conférence, il a bondi en s’écriant : « Tout ceci est faux ! C’est juste que j’ignorais l’étendue de ma protection. » Ce à quoi j’ai répondu : « Oui, c’est exactement ce que j’ai dit. » Il s’est rassis, mais si j’avais répondu non il aurait sans doute trouvé moyen de continuer la dispute.
Toujours est-il que si vous consultez un avocat, à l’issue d’une longue et coûteuse conversation il vous répondra sans doute quelque chose du genre :
Si vous faites quelque chose dans ce domaine-ci, vous êtes presque certain de perdre un procès, si vous faites quelque chose dans ce domaine-là, il y a une chance considérable de perdre un procès, et si vous voulez vraiment vous mettre à l’abri, ne touchez pas à tel et tel domaine. Ceci dit, en cas de procès, l’issue est largement aléatoire.
Alors, maintenant que vous avez des règles claires et prévisibles pour conduire vos affaires, que pouvez-vous vraiment faire ? En définitive, face à un brevet, il n’y a que trois actions possibles : soit vous l’évitez, soit vous obtenez une licence, soit vous le faites annuler. Je vais aborder ces points un par un.
Tout d’abord, il y a la possibilité d’éviter le brevet, ce qui signifie en clair : ne pas mettre en œuvre ce qu’il interdit. Bien sûr, comme il est difficile de dire ce qu’il interdit, il sera presque impossible de déterminer ce qu’il faut faire pour l’éviter.
Il y a quelques années, Kodak a poursuivi Sun pour infraction à l’un de ses brevets relatifs à la programmation orientée objet, et Sun contestait cette infraction. Le tribunal a fini par trancher qu’il y avait bel et bien infraction. Mais lorsqu’on examine le brevet, il est totalement impossible de dire si cette décision est fondée ou non. Personne ne peut vraiment dire ce que le brevet recouvre, mais Sun a quand même dû payer des centaines de millions de dollars pour avoir enfreint une règle complètement incompréhensible.
Parfois, cependant, il est possible de déterminer ce qui est interdit. Et il peut d’agir d’un algorithme.
J’ai ainsi vu un brevet sur quelque chose ressemblant à la « transformée de Fourier rapide », mais deux fois plus rapide. Si la TFR classique est suffisamment rapide pour vos besoins, vous pouvez facilement vous passer de ce brevet. La plupart du temps il n’y aura donc pas de problème. Mais il se peut qu’à l’occasion, vous souhaitiez faire un programme qui utilise constamment des TFR, et qui ne peut fonctionner qu’en utilisant l’algorithme le plus rapide. Là, vous ne pouvez pas l’éviter, ou alors vous pourriez attendre quelques années que les ordinateurs soient plus puissants. Mais bon, l’hypothèse reste exceptionnelle. La plupart du temps il est facile d’esquiver ce type de brevet.
Parfois, en revanche, il est impossible de contourner un brevet sur un algorithme. Prenez par exemple l’algorithme de compression de données LZW. Comme je vous l’ai dit, nous avons fini par trouver un meilleur algorithme de compression, et tous ceux qui veulent compresser des fichiers se sont mis à utiliser le programme gzip qui repose sur ce meilleur algorithme. Si vous voulez juste compresser un fichier et le décompresser plus tard, vous pouvez indiquer aux gens qu’ils doivent utiliser tel ou tel programme pour le décompresser ; au final vous pouvez utiliser n’importe quel programme basé sur n’importe quel algorithme, la seule chose qui vous importe c’est qu’il soit efficace
Mais LZW sert aussi à d’autres choses. Par exemple, le langage PostScript fait appel à des opérateurs de compression et de décompression LZW. Il serait inutile de faire appel à un autre algorithme, même plus efficace, car le format de données ne serait plus le même. Ces algorithmes ne sont pas interopérables. Si vous compressez avec l’algorithme utilisé dans gzip, vous ne pouvez pas décompresser avec LZW. En définitive, quel que soit votre algorithme et quelle que soit son efficacité, si ce n’est pas LZW, vous ne pourrez pas implémenter PostScript conformément aux spécifications.
Mais j’ai remarqué que les utilisateurs demandent rarement à leur imprimante de compresser des choses. En général, ils veulent seulement que leur imprimante soit capable de décompresser. Et j’ai aussi remarqué que les deux brevets sur l’algorithme LZW sont écrits de telle manière que si votre système ne fait que décompresser, alors ce n’est pas interdit. Ces brevets ont été formulés de manière à couvrir la compression, et ils contiennent des revendications portant sur la compression et la décompression, mais aucune revendication ne couvre la seule décompression. Je me suis donc rendu compte que si nous implémentions juste la décompression LZW, nous serions à l’abri. Et, bien que cela ne corresponde pas aux spécifications, cela répondrait largement aux besoins des utilisateurs. C’est ainsi que nous nous sommes faufilés entre les deux brevets.
Il y a aussi le format GIF, pour les images. Il fait également appel à l’algorithme LZW. Il n’a pas fallu longtemps pour que les gens élaborent un autre format de fichier, du nom de PNG, ce qui signifie « PNG N’est pas GIF ». Je crois qu’il utilise l’algorithme gzip. Et nous avons commencé à dire à tout le monde : « N’utilisez pas le format GIF, c’est dangereux. Passez à PNG. » Et les utilisateurs nous ont dit : « D’accord, on y pensera, mais pour l’instant les navigateurs ne l’implémentent pas. » Ce à quoi les développeurs de navigateurs ont répondu : « On l’implémentera un jour, mais pour l’instant il n’y a pas de demande forte de la part des utilisateurs. »
Il est facile de comprendre ce qui s’était passé : GIF était devenu un standard de fait. En pratique, demander aux gens d’abandonner leur standard de fait en faveur d’un autre format revient à demander à tout le monde en Nouvelle-Zélande de parler hongrois. Les gens vont vous dire : « Pas de problème, je m’y mets dès que tout le monde le parle. » Et au final nous ne sommes jamais parvenus à convaincre les gens d’arrêter d’utiliser GIF, en dépit du fait que l’un des détenteurs de brevets passe son temps à faire le tour des administrateurs de sites web en les menaçant de poursuites s’ils ne peuvent prouver que tous les GIF du site ont été réalisés avec un programme sous licence.
GIF était donc un piège dangereux menaçant une large part de notre communauté. Nous pensions avoir trouvé une alternative au format GIF, à savoir JPEG, mais quelqu’un – je crois qu’il s’agissait d’une personne ayant tout juste acheté des brevets dans le but d’exercer des menaces – nous a dit : « En regardant mon portefeuille de brevets, j’en ai trouvé un qui couvre le format JPEG. »
JPEG n’était pas un standard de fait. Il s’agissait d’un standard officiel, élaboré par un organisme de standardisation. Et cet organisme avait lui aussi un avocat, qui a dit qu’il ne pensait pas que le brevet couvre le format JPEG.
Alors, qui a raison ? Eh bien, le titulaire du brevet a poursuivi un groupe de sociétés, et s’il y avait eu une décision, on aurait pu savoir ce qu’il en était. Mais je n’ai jamais entendu parler de décision, et je ne suis pas sûr qu’il y en ait jamais eu. Je pense qu’ils ont conclu un règlement amiable, et ce règlement est probablement secret, ce qui signifie que nous ne saurons jamais qui avait raison.
Les cas dont j’ai parlé ici sont relativement modestes : un seul brevet en ce qui concerne JPEG, deux pour l’algorithme LZW utilisé pour GIF. Vous vous demandez peut-être pourquoi il y avait deux brevets sur le même algorithme. Normalement, cela n’est pas possible, pourtant c’est arrivé. Cela tient au fait que les personnes examinant les brevets n’ont pas le temps d’étudier et de comparer tout ce qui devrait l’être, parce que les délais sont très courts. Et comme les algorithmes ne sont au final que des mathématiques, il est impossible de limiter le choix de brevets et de demandes de brevets à comparer.
Vous voyez, dans le domaine industriel, ils peuvent se référer à ce qui se passe réellement dans le monde physique pour circonscrire les choses. Par exemple dans le domaine de l’ingénierie chimique, on peut se demander : « Quelles sont les substances utilisées ? Quelles sont les produits obtenus ? » Si deux demandes de brevet diffèrent sur ce point, il s’agit donc de deux inventions différentes, et il n’y a pas de problème. Mais en mathématiques, des choses identiques peuvent être présentées de manière très différentes, et à moins de les comparer en détail vous ne vous rendrez jamais compte qu’il s’agit d’une seule et même chose. Et, de ce fait, il n’est pas rare de voir la même chose être brevetée à plusieurs reprises dans le domaine du logiciel.
Vous vous souvenez de l’histoire de ce programme qui a été tué par un brevet avant même que nous ne l’ayons publié ? Eh bien, cet algorithme était également breveté deux fois. Donc, dans un domaine extrêmement réduit, nous avons déjà vu ce phénomène se produire à plusieurs reprises. Je pense vous avoir expliqué pourquoi.
Mais un ou deux brevets constituent une situation plutôt simple. Prenons MPEG-2, le format vidéo. J’ai vu une liste de plus de 70 brevets couvrant ce format, et les négociations pour permettre à quelqu’un d’obtenir une licence ont pris plus de temps que le développement du standard lui-même. Le comité JPEG voulait développer un nouveau standard plus moderne, ils ont fini par abandonner. Ce n’est pas faisable, ont-ils dit. Il y a trop de brevets.
Parfois, c’est carrément une fonctionnalité qui est brevetée, et la seule façon d’éviter le brevet consiste à ne pas implémenter cette fonctionnalité. Ainsi, les utilisateurs du logiciel de traitement de texte XyWrite ont une fois reçu par la poste une mise à jour supprimant une fonctionnalité. Il s’agissait de la possibilité de définir une liste d’abréviations. Par exemple, si vous définissiez qu’« exp » était l’abréviation d’« expérience », il suffisait de taper « exp-espace », ou « exp-virgule », pour qu’« exp » soit automatiquement remplacé par « expérience ».
Mais quelqu’un disposant d’un brevet sur cette fonctionnalité les a menacés, et ils ont conclu que la seule solution consistait à retirer cette fonctionnalité. Et ils ont envoyé à tous les utilisateurs une mise à jour la retirant.
Mais ils m’ont également contacté, car mon éditeur de texte Emacs proposait ce type de fonctionnalité depuis la fin des années 70. Et comme elle était décrite dans le manuel d’Emacs, ils espéraient que je pourrais les aider à faire tomber ce brevet. Je suis heureux de savoir que j’ai eu au moins une fois dans ma vie une idée qui soit brevetable, je regrette juste que ce soit quelqu’un d’autre qui l’ait brevetée.
Par chance, ce brevet fut finalement invalidé, en partie grâce au fait que j’avais publiquement annoncé un usage antérieur de cette fonctionnalité. Mais en attendant, ils ont dû retirer la fonctionnalité.
Retirer une ou deux fonctionnalités, ce n’est pas une catastrophe. Mais quand il s’agit de 50 fonctionnalités, les gens vont finir par dire : « Ce programme n’est pas bon, il lui manque toutes les fonctionnalités qui m’intéressent. » Ce n’est donc pas une solution viable. Et parfois un brevet est si général qu’il balaie un champ entier, comme par exemple le brevet sur le chiffrement par clé publique, qui interdit de fait tout chiffrement par clé publique pendant 10 ans.
Voilà pour la possibilité d’esquiver un brevet. C’est souvent possible, mais pas toujours, et il y a une limite au nombre de brevets qu’il est possible d’éviter.
Qu’en est-il de la deuxième solution, obtenir une licence pour le brevet ?
Le titulaire du brevet n’est pas tenu de vous accorder une licence. Cela ne dépend que de lui. Il peut très bien dire : « Je veux juste vous couler. » Une fois, j’ai reçu une lettre de quelqu’un dont l’entreprise familiale avait pour activité la création de jeux de casino, qui étaient bien sûr informatisés, et il avait été menacé par un titulaire de brevet qui voulait lui faire mettre la clé sous la porte. Il m’a envoyé le brevet. La revendication numéro 1 ressemblait à quelque chose du genre « un réseau de plusieurs ordinateurs contenant chacun plusieurs jeux et qui permet plusieurs parties simultanément ».
Je suis à peu près sûr que dans les années 80, il existait une université avec des stations de travail en réseau, dotées d’un quelconque système de fenêtrage. Il aurait suffi qu’ils installent plusieurs jeux pour qu’il soit possible d’afficher plusieurs parties simultanément. Il s’agit de quelque chose de tellement trivial et d’inintéressant que jamais personne ne se serait donné la peine d’écrire un article à ce sujet. Ce n’était pas assez intéressant pour constituer un article, mais ça l’était suffisamment pour constituer un brevet. Si vous avez compris que vous pouvez obtenir un monopole sur cette opération triviale, vous pouvez faire fermer vos concurrents.
Mais pourquoi est-ce que l’Office des brevets accorde tant de brevets qui nous semblent absurdes et triviaux ?
Ce n’est pas parce que les examinateurs de brevets sont stupides. C’est parce qu’ils suivent un processus, que ce processus est régi par des règles, et que ces règles aboutissent à ce résultat.
Vous voyez, si quelqu’un a construit une machine qui fait quelque chose une seule fois, et que quelqu’un d’autre construit une machine qui fait la même chose, mais N fois, pour nous il s’agit juste d’une boucle for, mais pour l’Office des brevets il s’agit d’une invention. S’il y a des machines qui peuvent faire A, et des machines qui peuvent faire