Richard Stallman
Conférence donnée au Model Engineering College du Gouvernement du Kerala (Inde) en 2001 (enregistrement audio)
Le Professeur Jyothi John, responsable du département d'informatique, présente Stallman :
C'est pour moi un privilège d'accueillir et un devoir de vous présenter l'hôte le plus illustre qui ait jamais rendu visite à ce collège.
M. Richard Matthew Stallman a lancé le développement du système d'exploitation GNU en 1984, dans le but de créer un système d'exploitation de type Unix qui soit complètement libre. L'organisation qui a été fondée en 1985 pour servir cet objectif est la Free Software Foundation.a
Stallman est un visionnaire de l'informatique moderne. C'est le génie qui se cache derrière des programmes comme Emacs, GCC, le débogueur GNU et bien d'autres. Surtout, il est l'auteur de la licence publique générale GNU, licence sous laquelle plus de la moitié du logiciel libre est distribué et développé. L'association de GNU avec le noyau Linux, appelée « système d'exploitation GNU/Linux », a maintenant vingt millions d'utilisateurs dans le monde, selon les estimations.
La manière dont Stallman conçoit le logiciel libre nous parle de liberté, plutôt que de prix.b Ses idées contribuent grandement à garantir le développement de logiciels destinés au bien-être de la société, par des programmeurs travaillant collectivement, sans « verrouiller » leur travail, mais au contraire en le laissant à la disposition des autres pour l'étudier, le modifier et le redistribuer.
Stallman a reçu le prix Grace Hopper de l'Association for Computing Machineryc en 1991, peu après s'être vu attribuer (en 1990) une bourse de la fondation MacArthur – parmi les autres lauréats de cette bourse prestigieuse, on trouve Noam Chomsky et Tim Berners-Lee. En 1996, il a reçu le titre de docteur honoris causa en technologie de l'Institut royal de Suède. En 1998, il a reçu le prix Pioneer de l'Electronic Frontier Foundation en même temps que Linus Torvalds, et en 1999 le prix créé en mémoire de Yuri Rubinski.
Aujourd'hui, Stallman va nous parler du danger des brevets logiciels. De fait, c'est l'un des aspects les plus importants de la liberté de programmer, parce que les brevets logiciels font courir à tous les programmeurs le risque d'enfreindre la loi. Ils pourraient en effet, sans le savoir, être en train de violer quelques-uns des brevets détenus par une autre société.
Après cette introduction, je suis sûr que beaucoup d'entre vous veulent en savoir plus sur le logiciel libre. Mais malheureusement ce n'est pas de cela que je suis censé parler. En fait, la question que je vais aborder, celle des brevets logiciels, n'est pas liée très étroitement à celle du logiciel libre : les brevets logiciels sont un danger pour tous les programmeurs et pour tous les utilisateurs de l'informatique. Naturellement, c'est mon travail sur le logiciel libre qui m'en a fait prendre conscience, car les brevets logiciels sont un danger pour mon projet aussi bien que pour chacun des autres projets de développement logiciel dans le monde.
Il y a une expression très malencontreuse que vous avez probablement déjà entendue : « propriété intellectuelle ». Il y a deux choses qui ne vont pas dans cette expression.
La première : elle préjuge d'une question politique primordiale, à savoir comment traiter telle ou telle catégorie d'idées, de pratiques, d'œuvres, ou de n'importe quoi d'autre. Elle suppose que toutes seront traitées comme une propriété quelconque. Pourtant, c'est une décision de politique publique et l'on doit pouvoir examiner les différentes alternatives pour choisir la meilleure. Ce qui veut dire qu'il ne faut pas désigner l'ensemble de ce sujet, désigner cette question, par un terme qui préjuge de quelle sorte de réponse on va lui donner.
Deuxième problème, encore plus fondamental, cette expression est en réalité un fourre-tout pour des domaines du droit complètement différents comme les copyrights, les brevets, les marques déposées, les secrets de fabrication, etc. Pourtant, ils n'ont en réalité presque rien en commun. Le contenu des lois change totalement quand on passe de l'un à l'autre. Leurs origines sont complètement indépendantes et les questions de politique publique qu'ils soulèvent sont complètement différentes. Aussi, la seule manière intelligente d'y réfléchir est de les examiner une à une ; d'y réfléchir séparément.
La manière intelligente d'en parler est de ne jamais généraliser, mais au contraire de parler d'un domaine spécifique. Vous savez, parler des copyrights, ou bien parler des brevets, ou bien parler des marques déposées, mais ne jamais les mettre dans le même sac sous le nom de « propriété intellectuelle », parce que c'est la meilleure façon d'arriver à des conclusions simplistes. Il est presque impossible de réfléchir intelligemment à la propriété intellectuelle et je refuse de le faire. Je dis seulement aux gens pourquoi je pense que cette expression est erronée, et ensuite, s'ils me demandent mon opinion sur les copyrights ou mon opinion sur les brevets, cela me prendra une heure pour la leur donner. Mais ce sera deux opinions différentes, et mon opinion sur les marques déposées est encore quelque chose de complètement différent.
Donc pour commencer, le plus important pour vous est de ne jamais mélanger le sujet des copyrights avec le sujet des brevets. Ils n'ont rien à faire ensemble. Permettez-moi de vous citer quelques-unes des différences fondamentales entre les copyrights et les brevets :
Il y a encore beaucoup d'autres différences. En fait ils diffèrent dans tous les détails. Aussi la pire chose que vous puissiez jamais faire si vous apprenez quelque chose à propos des copyrights, c'est de supposer que c'est vrai également pour les brevets. Non, il est plus probable que ce n'est pas vrai pour les brevets. Si c'est vrai pour les copyrights, ce n'est pas vrai pour les brevets ; voilà un meilleur principe, si vous ne savez pas.
La plupart du temps, les personnes qui décrivent comment marche le système de brevets sont des personnes qui ont un intérêt personnel dans le système. Et ainsi elles le décrivent du point de vue de quelqu'un qui veut obtenir un brevet, pour ensuite le braquer sur les programmeurs en leur disant : « File-moi ton argent. » C'est naturel, vous savez. Quand on vend des billets de loterie, on parle des gens qui gagnent, pas de ceux qui perdent. Naturellement, la plupart des gens perdent, mais les vendeurs de billets ne veulent pas que vous y pensiez, alors ils parlent des gens qui gagnent. C'est la même chose avec les brevets. Le système de brevets est une loterie très coûteuse pour les participants. Mais naturellement, les personnes qui le gèrent veulent que vous pensiez à la petite chance que vous avez de gagner.
Aussi, pour rétablir l'équilibre, je vais vous expliquer à quoi ressemble le système de brevets du point de vue d'une personne qui pourrait en être victime, c'est-à-dire d'une personne qui veut développer du logiciel. Supposons que vous vouliez développer un programme et que vous soyez dans un pays qui a des brevets logiciels. Comment devez-vous aborder ce système ?
Eh bien, d'abord, vous devez chercher à savoir comment les brevets pourraient éventuellement affecter votre champ d'activité. C'est impossible, car les brevets en cours d'examen par l'office des brevets sont confidentiels. D'accord, dans certains pays ils sont publiés dix-huit mois plus tard, mais cela leur laisse encore un temps appréciable pour rester secrets. Ainsi vous pourriez développer un programme cette année, qui serait parfaitement licite et sans danger, cette année. Et puis l'année prochaine, un brevet pourrait être accordé et tout d'un coup vous pourriez faire l'objet de poursuites. Cela arrive. Ou bien vos utilisateurs pourraient être poursuivis.
Par exemple, en 1984 nous avons développé le programme Compress, et comme c'était un logiciel libre, il a été distribué par beaucoup de sociétés avec les systèmes Unix. Eh bien, en 1985, un brevet a été pris aux États-Unis sur l'algorithme de compression LZW utilisé par Compress, et après quelques années Unisys a commencé à soutirer de l'argent à diverses sociétés.
Comme nous, au projet GNU, avions besoin d'un programme de compression de données et que nous ne pouvions plus utiliser Compress, nous avons commencé à chercher un autre programme de compression. Quelqu'un s'est présenté et a dit : « J'ai travaillé sur cet algorithme pendant un an et maintenant j'ai décidé de vous l'offrir. Voici le code. » Nous étions à une semaine de sortir ce programme quand je suis tombé par hasard sur un exemplaire du New-York Times, ce qui n'arrive pas très souvent. Il se trouve qu'il contenait justement la rubrique hebdomadaire des brevets ; je l'ai remarquée, et donc je l'ai lue. Elle disait que quelqu'un avait obtenu un brevet pour l'invention d'une nouvelle méthode, d'une meilleure méthode de compression. Bon, ce n'était pas vraiment le cas. Quand j'ai vu ça, j'ai pensé que nous ferions mieux de nous procurer une copie de ce brevet pour voir s'il posait problème. Et il se trouve qu'il couvrait exactement l'algorithme que nous étions sur le point de publier. Ainsi ce programme a été tué une semaine avant sa sortie. Et en fait, la méthode que cette personne (le titulaire de ce brevet) avait inventée n'était pas meilleure, parce qu'elle n'était pas nouvelle. Mais cela n'a pas d'importance, il avait un monopole.
Finalement nous avons trouvé un autre algorithme de compression, qui est maintenant utilisé dans le programme connu sous le nom de GZIP. Mais ceci illustre le danger auquel vous êtes confrontés : même si vous aviez des moyens illimités, vous ne pourriez pas découvrir tous les brevets susceptibles de mettre en danger votre projet. Mais vous pouvez vous renseigner sur les brevets existants parce qu'ils sont publiés par l'office des brevets. Donc en principe vous pourriez tous les lire et voir ce qu'ils restreignent, ce qu'ils vous empêchent de faire. En pratique, cependant, à partir du moment où il existe des brevets logiciels, il y en a tant que vous ne pouvez pas soutenir le rythme. Aux États-Unis il y en a plus de cent mille, peut-être deux cent mille à l'heure actuelle. C'est juste une estimation. Je sais qu'il y a dix ans ils en accordaient dix mille par an et je crois que le rythme s'est accéléré depuis. C'est trop pour que vous puissiez vous tenir au courant, à moins que ce ne soit votre travail à plein temps. Cela dit, vous pouvez rechercher ceux qui ont rapport avec ce que vous faites ; cela marche parfois. Si vous faites des recherches avec certains mots-clés ou suivez des liens, vous trouverez des brevets qui se rapportent à ce que vous faites. Mais vous ne les trouverez pas tous.
Il y a quelques années, quelqu'un avait un brevet américain – peut-être a-t-il expiré depuis – sur le « recalculd en ordre naturel » dans les tableurs. Maintenant, qu'est-ce que ça veut dire ? Cela signifie que les tableurs, à l'origine, recalculaient toujours de haut en bas. Ce qui veut dire que si jamais une cellule dépendait d'une autre cellule placée plus bas, elle n'était pas recalculée en une fois ; vous deviez faire un autre recalcul pour l'obtenir. C'est clair qu'il vaut mieux recalculer dans le bon sens, vous savez. Si A dépend de B, alors calculez B d'abord, puis calculez A. De cette façon, un seul recalcul rendra l'ensemble cohérent. Eh bien, c'est cela que le brevet couvrait.
Si vous aviez fait une recherche sur le mot « tableur », vous n'auriez pas trouvé ce brevet parce que ce mot n'y figurait pas. L'expression « recalcul en ordre naturel » n'y figurait pas non plus. Cet algorithme (c'était bien l'algorithme qui était breveté, à peu près tous les moyens imaginables de le coder), cet algorithme est appelé « tri topologique », et cette expression n'apparaissait pas non plus dans le brevet. Il était présenté comme se rapportant à une technique de compilation. Ainsi une recherche raisonnablee ne l'aurait pas trouvé, mais malgré tout il aurait justifié des poursuites contre vous.
En réalité vous ne pouvez pas savoir, même approximativement, ce qu'un brevet logiciel recouvre, à moins de l'étudier soigneusement. C'est différent des autres spécialités, parce que dans les autres spécialités quelque chose de physique se produit et les détails de cette chose physique vous donnent habituellement une sorte de point d'ancrage pour déterminer si le brevet concerne votre projet, ou non. Mais dans le logiciel, il n'y a rien de tel. Ainsi il arrive facilement que deux descriptions totalement différentes recouvrent, en fait, le même calcul. Il faut les étudier en détail pour s'en apercevoir. C'est pourquoi même l'office des brevets s'y perd. Ainsi il n'y a pas un, mais deux brevets sur la compression de données LZW. Le premier a été attribué en 1985 et le second, je pense, en 1989, mais ce dernier avait été demandé encore plus tôt. Un de ces brevets appartient à Unisys et l'autre à IBM.
En réalité, ce type d'erreur n'est pas si rare. Celle-là n'est pas unique. Voyez-vous, les examinateurs des brevets n'ont pas beaucoup de temps à consacrer à chacun d'eux. Aux États-Unis, ils ont en moyenne 17 heures. Ce n'est pas suffisant pour étudier en détail tous les autres brevets de la même spécialité, pour voir si c'est vraiment la même chose. C'est pourquoi ils répéteront cette sorte d'erreur indéfiniment.
Donc vous ne trouverez pas tous les brevets qui pourraient vous menacer, mais vous en trouverez quelques-uns. Alors, qu'est-ce que vous faites ? Vous devez essayer de déterminer précisément ce que ces brevets interdisent. C'est très difficile parce que les brevets sont rédigés dans un langage juridique tortueux qui est très difficile à comprendre pour un ingénieur. Il va vous falloir y travailler avec un avocat.
Dans les années 80, le gouvernement australien a commandité une étude sur le système de brevets – le système de brevets en général, pas seulement les brevets logiciels. Cette étude concluait que l'Australie ferait mieux d'abolir ce système parce qu'il rendait très peu service à la société et causait beaucoup d'ennuis. La seule raison pour laquelle ils ne recommandaient pas de le faire était la pression internationale. Parmi les arguments, il y avait le fait que les brevets, pourtant censés divulguer l'information pour qu'elle ne reste pas secrète, ne servaient pas cet objectif en pratique. Les ingénieurs ne regardaient jamais les brevets pour essayer d'apprendre quoi que ce soit parce qu'ils sont trop difficiles à lire. Par exemple ils citaient un ingénieur qui disait : « Je n'arrive pas reconnaître mes propres inventions dans les brevets. » Et ce n'est pas seulement théorique.
Il y a quelques années aux États-Unis, un ingénieur nommé Paul Heckel a poursuivi Apple. Il avait pris deux brevets à la fin des années 80 pour un logiciel. Puis il a vu HyperCard, et après l'avoir examiné il s'est dit : « Cela ne ressemble pas à mon programme. » Il n'y a plus pensé, mais plus tard son avocat lui a expliqué qu'en lisant son brevet avec attention, on constatait qu'HyperCard tombait dans le domaine interdit. Il a donc poursuivi Apple, supputant que ce serait peut-être l'occasion de gagner un peu d'argent. Eh bien, une fois, alors que je donnais une conférence comme celle-ci, il était dans l'assistance et a dit : « Oh non, ce n'est pas vrai, c'est seulement que je ne connaissais pas l'étendue de ma protection. » Et j'ai répondu : « Oui, c'est ce que je viens de dire. »
Ainsi, vous allez devoir passer beaucoup de temps à travailler avec un avocat, à lui expliquer sur quels projets vous travaillez, pour que l'avocat puisse vous expliquer ce que les brevets impliquent. Cela va coûter cher. Et quand vous aurez fini, l'avocat vous dira à peu près ceci : « Si vous faites quelque chose dans ce domaine-ci, vous êtes presque sûr de perdre un procès. Si vous faites quelque chose dans ce domaine-là, vous êtes considérablement en danger et si vous voulez vraiment être en sécurité vous feriez mieux d'en rester à l'écart. Et naturellement il y a un facteur chance considérable dans le résultat de toute procédure. » Alors, maintenant que vous avez un terrain prévisible pour mener vos affaires, qu'est-ce que vous allez faire ?
Eh bien, vous devez envisager trois possibilités :
Chacune des trois est quelquefois une alternative viable, quelquefois elle ne l'est pas.
Voyons d'abord comment contourner le brevet. Dans certains cas, c'est facile. Unisys, rappelez-vous, menaçait de son brevet les gens qui se servaient de la compression LZW. Eh bien, il nous a suffi de trouver un autre algorithme de compression et nous avons pu contourner ce brevet. Cela a été un peu difficile parce qu'il y avait beaucoup d'autres brevets couvrant un tas d'autres algorithmes de compression de données. Mais finalement nous en avons trouvé un qui n'était pas dans le domaine couvert par les brevets des autres ; finalement nous y sommes arrivés. Puis ce programme a été mis en œuvre. Il donnait en fait de meilleurs résultats de compression, et maintenant nous avons GZIP, que beaucoup de gens utilisent. Ainsi, dans ce cas précis, cela a demandé beaucoup de travail, mais nous avons pu le faire ; nous avons contourné le brevet.
Mais dans les années 80, CompuServe avait défini un format d'image appelé GIF qui utilisait l'algorithme de compression LZW. Naturellement, lorsqu'ils ont eu vent du tumulte entourant ce brevet, des gens ont défini un autre format d'image utilisant un algorithme de compression différent. Ils se sont servi de l'algorithme GZIP. Ce format est appelé PNG, ce qui, je suppose, veut dire PNG is Not GIF (PNG N'est pas GIF).
Mais il y avait un problème : beaucoup de gens avaient déjà commencé à se servir du format GIF et beaucoup de programmes pouvaient afficher le format GIF et produire du format GIF, mais ils ne pouvaient pas afficher le format PNG. Le résultat, c'est que les gens trouvaient trop difficile de changer de format. Vous voyez, quand vous avez un programme de compression utilisé par quelqu'un qui veut comprimer des données, si cette personne peut être poursuivie pour avoir utilisé un programme et que vous lui en donnez un autre, alors elle va migrer ; mais si ce qu'elle veut faire, c'est des images qui puissent être affichées par Netscape, alors elle ne peut pas migrer, à moins que Netscape ne commence à gérer le nouveau format… et ce n'était pas le cas. Il s'est passé des années, je pense, avant que Netscape gère le format PNG. Pour l'essentiel, les gens disaient : « Je ne peux pas changer, il faut que je… » Au final, la société avait tant investi dans ce seul format que l'inertie rendait le changement impossible, alors même qu'un autre format, supérieur, était disponible.
Même quand un brevet couvre un domaine assez étroit, le contourner peut être très difficile. Les spécifications de PostScript incluent la compression LZW que nous ne pouvons pas utiliser dans notre implémentation de PostScript. Nous employons une autre sorte de compression, d'une manière peu orthodoxe bien qu'elle donne un résultat utilisable. Ainsi, même un brevet couvrant un domaine étroit n'est pas toujours possible à contourner en pratique.
Quelquefois, c'est une fonctionnalité qui est brevetée. Dans ce cas, on peut contourner le brevet en enlevant cette fonctionnalité. Vers la fin des années 80, les utilisateurs du logiciel de traitement de texte XyWrite ont reçu par la poste une mise à jour dégradant le programme au lieu de l'améliorer. Ce logiciel avait une fonctionnalité qui permettait de définir un mot court, une suite de quelques lettres, comme abréviation. Quand on tapait ces quelques lettres, puis un espace, on obtenait le mot complet. On pouvait définir cette abréviation comme on voulait. Puis quelqu'un prit un brevet sur cette fonctionnalité et XyWrite décida de traiter le problème en l'enlevant. Ils m'ont contacté parce qu'en fait j'avais mis une fonctionnalité similaire dans la version originale de l'éditeur Emacs, dans les années 70 – de nombreuses années avant ce brevet. Ainsi il y avait une chance que je puisse leur donner des arguments qui leur auraient permis de lutter contre le brevet.
Bon. Au moins, cela m'a montré que j'avais eu au moins une idée brevetable dans ma vie. Je le sais parce que quelqu'un d'autre a pris le brevet. Naturellement, vous pouvez réagir aux brevets qui couvrent des fonctionnalités en enlevant ces dernières. Mais quand plusieurs des fonctions que les utilisateurs recherchent commenceront à manquer dans votre programme, il pourrait ne plus être d'aucune utilité en tant que programme.
Vous avez peut-être entendu parler de Photoshop. Nous avons un programme appelé « le Gimp » qui est plus puissant et d'application plus générale que Photoshop. Mais il y a une fonctionnalité importante dont il est dépourvu, c'est le système Pantone de correspondance des couleurs, très important lorsqu'on veut effectivement imprimer des images sur papier avec des résultats reproductibles. Cette fonctionnalité a été omise parce qu'elle est brevetée. Il s'ensuit que le programme est déficient pour un groupe important d'utilisateurs.
Si vous regardez les programmes actuels, vous verrez que souvent ils ont de nombreuses fonctionnalités ; les utilisateurs les réclament. Si l'une des fonctions importantes manque, eh bien, on peut facilement la laisser de côté, mais les résultats sont parfois très mauvais.
Bien sûr, il arrive qu'un brevet couvre un domaine si étendu qu'il est impossible de le contourner. Le chiffrement à clé publique est essentiel pour préserver la vie privée des utilisateurs de l'informatique. L'ensemble de ce domaine était breveté. Ce brevet a expiré il y a juste quatre ans ; jusque-là, il ne pouvait pas y avoir de logiciel libre aux États-Unis pour le chiffrement à clé publique : plusieurs programmes libres et non libres avaient été anéantis par les titulaires du brevet. Et de fait tout ce domaine de l'informatique a été retardé pendant plus d'une décennie malgré le grand intérêt qu'il suscite.
Voilà donc la possibilité de contourner le brevet. Une autre option quelquefois disponible est d'obtenir une licence d'exploitation. Cependant le titulaire n'est pas obligé de vous offrir une licence. Cela dépend de son caprice ; le titulaire du brevet peut dire : « Je ne donne pas de licence pour ceci, votre boîte est coulée, point final ! »
À la League for Programming Freedomf, nous avons entendu parler au début des années 90 d'une personne dont l'entreprise familiale fabriquait des jeux de casino, informatisés naturellement. Cette personne avait été menacée par quelqu'un qui avait un brevet sur une catégorie très large de jeux de casino sur ordinateur. Le brevet couvrait un réseau dans lequel il y a plus d'une machine, chaque machine permettant de jouer à plus d'un type de jeu et d'afficher le déroulement de plus d'un jeu simultanément.
Maintenant, il y a une chose dont vous devez vous rendre compte : l'office des brevets pense que c'est vraiment génial. Si vous voyez que d'autres ont mis en œuvre une opération et que vous décidez de mettre en œuvre deux opérations ou plus – vous savez, s'ils ont construit un système qui permet de jouer à un jeu et que vous le rendez capable de jouer à plus d'un jeu – c'est une invention. Si le système peut afficher un jeu et que vous faites en sorte d'afficher deux jeux à la fois, c'est une invention. S'il le fait avec un ordinateur et que vous le faites avec un réseau de plusieurs ordinateurs, c'est une invention, de leur point de vue. Ils pensent que ces étapes sont vraiment géniales.
Naturellement nous savons, nous qui sommes dans l'informatique, qu'il y a une règle de base : si l'on fait une opération quelconque une fois, on peut généraliser et la faire plus d'une fois. Il n'y a pas de principe plus évident. Chaque fois que vous écrivez un sous-programme, c'est ce que vous faites. Voilà donc une des raisons récurrentes pour lesquelles le système de brevets produit, puis confirme, des brevets dont nous dirions tous qu'ils sont ridiculement évidents. On ne peut pas partir du principe qu'ils ne tiendraient pas devant un tribunal pour la simple raison qu'ils sont ridiculement évidents. Ils peuvent être valides juridiquement bien que totalement stupides.
Ainsi, cette personne était confrontée à ce brevet, et son titulaire ne lui a même pas donné la possibilité d'acheter une licence. « Ferme boutique ! » Voilà ce qu'a dit le titulaire du brevet, et c'est ce qu'elle a fait en fin de compte. Elle n'avait pas les moyens de se battre.
Cependant, beaucoup de titulaires de brevets vous permettront d'obtenir une licence, mais cela vous coûtera cher. Les propriétaires du brevet sur le recalcul en ordre naturel exigeaient cinq pour cent des ventes brutes de chaque tableur, et l'on m'a dit que c'était le tarif réduit d'avant le procès. Si vous alliez jusqu'à la bataille judiciaire, le tarif augmentait. Vous pourriez, je suppose, acheter une licence comme celle-là pour un brevet, vous pourriez le faire pour deux, vous pourriez le faire pour trois. Mais supposez que votre programme utilise, disons, vingt brevets, et que chaque titulaire de brevet demande cinq pour cent des ventes brutes ? Et s'il y en a vingt-et-un ? Alors vous êtes sacrément dans la mouise. Mais de fait, les chefs d'entreprise me disent que deux ou trois de ces brevets seraient une charge si lourde que pratiquement ils conduiraient la société à la faillite, même si théoriquement elle aurait pu s'en tirer.
Donc, une licence d'exploitation n'est pas nécessairement praticable, et pour nous, développeurs de logiciel libre, c'est encore pire parce que nous ne pouvons même pas compter les exemplaires d'un programme. Comme la plupart des licences exigent une redevance par poste, cela nous est absolument impossible d'utiliser une de ces licences. Vous savez, si une licence coûtait un millionième de roupie par exemplaire, il nous serait impossible de nous y conformer parce que nous ne pouvons pas les compter. Peut-être que j'ai assez d'argent dans ma poche, mais je ne peux pas compter ce que j'achète, donc je ne peux pas le payer. C'est pourquoi c'est particulièrement difficile pour nous par moment.
Pourtant il existe une catégorie d'organisations pour lesquelles les licences de brevets marchent très bien, ce sont les grandes multinationales ; en effet elles possèdent elles-mêmes de nombreux brevets qui leur servent à forcer la négociation de licences croisées. Qu'est-ce que cela veut dire ? Eh bien, la dissuasion est pour ainsi dire la seule défense contre les brevets : vous devez posséder des brevets à vous, ensuite vous espérez que si quelqu'un vous vise avec un brevet, vous pourrez le viser en retour avec un des vôtres en disant : « Ne me fais pas de procès, parce qu'alors je t'en fais un. »
Cependant, la dissuasion ne marche pas aussi bien avec les brevets qu'avec les armes nucléaires, parce que chaque brevet pointe dans une direction fixe. Il interdit certaines activités spécifiques. Le résultat, c'est que la plupart des sociétés qui essaient d'obtenir des brevets pour se défendre n'ont aucune chance d'y arriver. Peut-être qu'elles en obtiendront quelques-uns, vous savez. Elles pourraient obtenir un brevet qui pointe par ici, un qui pointe par là. OK, alors si quelqu'un là-bas menace cette société, que va-t-elle faire ? Elle n'a pas de brevet pointant de ce côté-là, donc elle est sans défense.
Entre-temps, un jour ou l'autre, quelqu'un d'autre va venir se promener dans les parages et le dirigeant de la société va penser : « Ho, ho, nous ne sommes pas aussi profitables que je le souhaiterais, pourquoi ne pas lui soutirer un peu d'argent ? » Donc ils commencent par dire qu'ils prennent ce brevet pour leur défense, mais souvent ils changent d'avis par la suite quand une victime alléchante passe à proximité.
Ceci, incidemment, montre à quel point est fallacieuse la légende que le système de brevets « protège » le « petit inventeur ». Permettez-moi de vous raconter cette légende, celle du génie affamé. Prenez quelqu'un qui a travaillé dans l'isolement pendant des années en crevant de faim, et qui a une idée novatrice brillante pour faire une chose ou l'autre. Alors il crée son entreprise et il a peur qu'une grande société comme IBM lui fasse concurrence. Il prend donc un brevet qui va le « protéger ».
Naturellement, ce n'est pas comme cela que ça se passe dans notre spécialité. Les gens ne font pas ce genre d'innovation dans l'isolement. Ils travaillent avec d'autres, ils parlent avec les autres, d'habitude pour développer un logiciel. Donc ce scénario ne tient pas la route, et de plus, s'il était si bon informaticien, il n'aurait pas eu besoin de crever de faim. Il aurait pu trouver un travail n'importe quand s'il avait voulu.
Mais admettons que cela se soit vraiment produit, et admettons qu'il ait obtenu son brevet et qu'il dise : « IBM, tu ne peux pas me faire concurrence parce que j'ai obtenu ce brevet. » Mais voici ce que répond IBM : « Bon, super, voyons un peu ton produit. Hum, je possède ce brevet-ci, ce brevet-là et encore celui-là, et celui-là, et celui-là, que ton produit est en train de violer. Pourquoi ne ferions-nous pas pas un accord de licences croisées ? » Et le génie affamé répond : « Hum, je n'ai pas assez de nourriture dans l'estomac pour lutter contre ces choses-là, je ferais mieux de céder. » Et donc ils signent un accord de licences croisées. Maintenant, devinez quoi… IBM peut lui faire concurrence. Il n'est pas du tout protégé !
IBM peut faire cela parce qu'elle a un tas de brevets. Elle a des brevets pointant par ici, par là, par là, dans toutes les directions. Ainsi, quiconque attaque IBM, de n'importe où ou presque, s'expose à une confrontation. Une petite société ne peut pas faire cela, mais une grande peut le faire.
IBM a écrit un article. C'était dans la revue Think – c'est la revue interne d'IBM – numéro cinq de 1990 je crois, un article sur son portefeuille de brevets. La société disait qu'elle avait deux manières de tirer profit de ses 9 000 brevets américains en état de validité. La première était de collecter des royalties. Mais la deuxième, la plus rentable, était d'avoir accès à des choses brevetées par d'autres – la permission, par le biais de licences croisées, de ne pas être attaquée par d'autres au moyen de leurs brevets. Et l'article disait que le second profit était supérieur au premier d'un ordre de grandeur. Autrement dit, l'avantage que tire IBM de travailler librement, sans être poursuivie, est dix fois supérieur à ce qu'elle gagne avec tous ses brevets.
Cela dit, le système de brevets ressemble beaucoup à une loterie, dans le sens que ce qu'il advient d'un brevet particulier est essentiellement le fruit du hasard ; la plupart ne rapportent rien à leurs titulaires. Mais IBM est si grande que, sur l'ensemble de cette société, les choses s'équilibrent en moyenne. Donc on peut dire qu'IBM donne une bonne idée de la moyenne. Ce qu'on observe – et ceci est un peu subtil – c'est que l'avantage pour IBM de pouvoir utiliser les idées brevetées par d'autres contrebalance le mal que le système de brevets lui aurait fait s'il n'y avait pas de licences croisées – s'il lui était vraiment interdit d'utiliser les idées brevetées par d'autres.
Autrement dit, les dommages que causerait le système de brevets sont dix fois supérieurs, en moyenne, aux bénéfices qu'il procure. Dans le cas d'IBM, cependant, ces dommages n'existent pas, parce qu'elle possède effectivement 9 000 brevets et ainsi peut forcer des accords de licences croisées pour éviter le problème. Mais si vous êtes petit, alors vous ne pouvez pas éviter le problème de cette façon et vous serez vraiment confronté à dix fois plus d'ennuis que de profits. En tout cas, c'est la raison pour laquelle les grosses multinationales sont en faveur des brevets logiciels et font du lobbying auprès des gouvernements tout autour de la planète pour qu'ils les adoptent, en disant des choses naïves comme : « C'est une nouvelle sorte de monopole pour les développeurs de logiciel et ce doit être bon pour eux, n'est-ce pas ? »
Bon. Aujourd'hui, après avoir écouté ma conférence, j'espère que vous comprenez pourquoi ce n'est pas vrai. Pour voir si les brevets logiciels sont bons ou mauvais, on doit regarder en détail comment ils affectent les développeurs. Mon but est de vous l'expliquer.
Voilà donc la possibilité d'obtenir une licence d'exploitation. La troisième option possible est d'aller au tribunal pour contester la validité du brevet.
Le résultat de cette procédure va dépendre pour une large part de détails techniques, c'est-à-dire essentiellement de données aléatoires, vous savez. Les dés ont été jetés il y a plusieurs années ; vous pouvez chercher à savoir ce que les dés ont décidé, et alors vous découvrirez si vous avez une chance, ou non. Ainsi, c'est essentiellement un accident historique qui détermine si un brevet est valide ; l'accident historique qui détermine si des gens ont publié des choses, ou plus précisément quelles choses ils ont publiées, et quand.
Il y a donc quelquefois une possibilité de faire invalider un brevet. Cependant, même s'il est ridiculement trivial, on a parfois une bonne chance de le faire invalider, parfois non.
On ne peut pas compter sur les tribunaux pour reconnaître qu'un brevet est trivial, parce que leurs standards sont généralement bien inférieurs à ce que nous considérerions comme raisonnable. De fait, c'est une tendance persistante aux États-Unis. J'ai vu une décision de la Cour suprême rendue aux alentours de 1954, qui donnait une longue liste de brevets qu'elle avait invalidés depuis le XIXe siècle. Et ils étaient totalement ridicules, comme de faire des poignées de porte d'une certaine forme en caoutchouc, alors que jusque-là on les avait faites en bois. Cette décision reprochait au système de brevets d'avoir dérivé loin, très loin des standards adéquats. Et ils continuent.
Ainsi vous ne pouvez pas vous attendre à des résultats sensés, mais il existe des situations où, si vous regardez l'historique, vous verrez qu'il y a une chance d'invalider un brevet particulier. Cela vaut la peine d'essayer, au moins de se renseigner. Mais la procédure elle-même risque de coûter extrêmement cher.
Il y a quelques années, un défendeur a perdu son procès et a dû payer 13 millions de dollars qui, en majorité, allèrent aux avocats des deux parties. Je pense que le titulaire du brevet a remporté 5 millions de dollars seulement ; les avocats ont donc empoché 8 millions.
Voilà donc vos options. À ce stade, naturellement, vous devez écrire le programme. Et là, le problème, c'est que vous n'êtes pas confronté à cette situation une seule fois, mais qu'elle se répète, encore et encore, parce que de nos jours les programmes sont compliqués. Regardez un logiciel de traitement de texte ; vous y verrez un tas de fonctionnalités, beaucoup de choses différentes dont chacune peut être brevetée par quelqu'un, ou dont chaque combinaison de deux d'entre elles peut être brevetée par quelqu'un. British Telecom a un brevet aux États-Unis sur la combinaison de deux techniques : suivre des liens hypertexte et permettre à un utilisateur d'appeler le serveur par un accès téléphonique. Ces deux choses sont bien distinctes, mais la combinaison des deux est brevetée.
Cela veut dire que si vous avez cent éléments dans votre programme, il y a, potentiellement, à peu près cinq mille paires d'éléments qui pourraient déjà être brevetées par quelqu'un. Et il n'y a pas non plus de loi interdisant de breveter une combinaison de trois d'entre eux. Il ne s'agit que des fonctionnalités, vous savez. Vous allez vous servir de beaucoup de techniques en écrivant un programme, beaucoup d'algorithmes qui pourrait être brevetés également. Donc il y a des tas et des tas de choses qui pourraient être brevetées. Le résultat, c'est que le développement d'un programme devient comme la traversée d'un champ de mines. Bien sûr, vous n'allez pas marcher sur un brevet à chaque pas, à chaque étape de la conception du programme. Il y a des chances que ce soit sans danger. Mais traverser tout le champ devient dangereux.
La meilleure manière pour un non-programmeur de comprendre à quoi ça ressemble est de comparer l'écriture de ces grands programmes à un autre domaine dans lequel les gens écrivent quelque chose de très grand : les symphonies. Imaginez que les gouvernements européens du XVIIIe siècle aient voulu promouvoir le progrès de la musique symphonique en adoptant un système de brevets musicaux, de sorte que toute idée descriptible par des mots puisse être brevetée si elle semblait nouvelle et originale. Ainsi on aurait pu breveter, disons, un motif mélodique de trois notes, trop court pour être placé sous copyright mais néanmoins brevetable. Ou peut-être on aurait pu breveter une certaine progression d'accords, ou encore une certaine combinaison d'instruments jouant en même temps, ou n'importe quelle autre idée pouvant être décrite par quelqu'un.
Eh bien, vers 1800 il y aurait eu des milliers de ces brevets sur les idées musicales. Et alors imaginez que vous êtes Beethoven et que vous voulez écrire une symphonie. Pour écrire une symphonie complète, vous allez devoir faire un tas de choses différentes, et à n'importe quelle étape vous pourriez être en train d'utiliser une idée brevetée par quelqu'un d'autre. Bien sûr, si vous faites cela, il dira : « Oh ! Tu es juste un voleur, pourquoi ne peux-tu pas écrire quelque chose d'original ? » Beethoven avait plus que sa part d'idées musicales originales, mais il a utilisé beaucoup d'idées existantes dans sa musique. Il fallait qu'il le fasse, car c'était le seul moyen de la rendre reconnaissable. Si l'on ne fait pas ça, les gens refusent d'écouter. Pierre Boulez pensait qu'il allait réinventer complètement le langage musical. Il a essayé, mais les gens ne l'écoutent pas car toutes ces idées qui leur sont familières, il ne les utilise pas.
Donc vous devez utiliser les vieilles idées inventées par d'autres. Personne n'est assez génial pour réinventer complètement le domaine du logiciel, pour faire des choses utiles sans rien apprendre de qui que ce soit. Si ces personnes – les titulaires de brevets et leurs avocats – nous accusent de tricher, c'est en fait parce que nous ne réinventons pas ce domaine complètement à partir de rien. Pour progresser, nous devons construire sur la base des travaux précédents, et c'est exactement ce que le système de brevets nous interdit de faire. Et nous devons fournir aux utilisateurs les fonctionnalités dont ils ont l'habitude et qu'ils peuvent reconnaître, autrement ils trouveront nos logiciels trop difficiles à utiliser, quelle que soit leur qualité.
Les gens me demandent quelquefois pourquoi le logiciel est différent des autres spécialités. Parfois, bien sûr, ils le demandent de manière assez méchante. « Les autres spécialités peuvent composer avec les brevets, pourquoi le logiciel ferait-il exception ? » disent-ils. C'est une manière méchante de poser la question, car elle suppose que c'est mal de vouloir échapper à un problème. J'imagine que je pourrais répondre : « Eh bien, d'autres personnes peuvent avoir un cancer, pourquoi pas vous ? » Il est évident que, si c'est un problème, permettre à une spécialité d'y échapper est une bonne chose, quelle que soit cette spécialité. Mais voici une bonne question, une question importante : est-ce que ces autres spécialités sont dans la même situation que le logiciel ? Est-ce que les brevets les affectent toutes de la même façon ? Est-ce qu'une règle qui est bonne pour le logiciel est bonne également pour les moteurs d'automobiles, ou pour les médicaments, ou pour les procédés chimiques ? Vous savez, c'est une question importante et cela vaut la peine de s'y intéresser.
Quand on l'examine, on se rend compte que la relation entre les brevets et les produits varie suivant les spécialités. À l'un des extrêmes, il y a les médicaments où, typiquement, un brevet couvre une formule chimique complète. Alors, si vous sortez un nouveau médicament, il ne peut pas être breveté par quelqu'un d'autre. À l'autre extrême, il y a le logiciel où, lorsque vous écrivez un nouveau programme, vous combinez des dizaines ou des centaines d'idées dont on ne peut pas attendre qu'elles soient toutes nouvelles. Même un programme innovant, qui comporte quelques idées nouvelles, utilise aussi des tas et des tas d'idées anciennes. Et entre les deux on trouve les autres spécialités. Même dans ces dernières, les brevets peuvent conduire à des impasses.
Quand les États-Unis sont entrés dans la première guerre mondiale, personne aux États-Unis ne pouvait construire d'avion moderne. Les avions modernes utilisaient en effet plusieurs techniques différentes qui étaient brevetées par diverses sociétés dont les propriétaires se détestaient. Ainsi personne ne pouvait obtenir de licence pour utiliser tous ces brevets. Eh bien, le gouvernement américain a décidé que cet état de choses était inacceptable. En gros, il a payé une somme forfaitaire aux titulaires des brevets, puis il a dit : « Nous avons nationalisé ces brevets. Et maintenant, tous tant que vous êtes, allez construire des avions pour nous ! »
Mais le nombre de fois où cela se produit, la fréquence et la gravité de ces impasses, dépendent du nombre d'idées différentes utilisées dans la fabrication d'un produit. Cela dépend du nombre de points de vulnérabilité aux brevets qui existent dans ce produit. Et sous ce rapport, le logiciel est un cas extrême.
Il n'est pas rare de voir quelques personnes écrire en deux ou trois ans un programme contenant des millions de parties, de parties différentes, ce qui représente peut-être, disons 300 000 lignes de code. Concevoir un système physique qui contient des millions de pièces différentes est un projet énorme, c'est très rare. Cela dit, il arrive souvent que des gens fabriquent un objet physique avec des millions de pièces, mais typiquement ce sont de nombreuses copies de la même sous-unité, et la conception en est beaucoup plus facile – il n'y a pas des millions de pièces à concevoir.
Pourquoi est-ce comme cela ? C'est parce que dans les autres spécialités les gens doivent composer avec la perversité de la matière. Quand on conçoit des circuits, des voitures ou des produits chimiques, on est confronté au fait que ces substances physiques feront toujours ce qu'elles font, pas ce qu'elles devraient faire. Dans le logiciel, nous n'avons pas ce problème, ce qui rend les choses immensément plus faciles. Nous concevons une collection de pièces mathématiques idéales qui ont des définitions. Leur comportement est exactement celui qui est prévu par leur définition.
Ainsi, il y a beaucoup de problèmes que nous n'avons pas. Par exemple, si
nous mettons une condition if
à l'intérieur d'une boucle
while
, nous n'avons pas à nous inquiéter de savoir si
if
va recevoir assez d'énergie pour fonctionner à la vitesse
voulue. Nous n'avons pas à craindre que la boucle tourne à une vitesse
pouvant générer des interférences d'ondes radioélectriques qui induiraient
des valeurs erronées dans d'autres parties des données. Nous n'avons pas à
craindre qu'elle tourne à une vitesse susceptible de la faire entrer en
résonance, et que finalement la condition if
vibre contre la
boucle while
au point que l'une d'elles se casse.
Nous n'avons pas à craindre que les produits chimiques de l'environnement
pénètrent dans l'interface entre if
et while
,
causant de la corrosion, puis un mauvais contact. Nous n'avons pas à
craindre que d'autres produits chimiques les contaminent et produisent un
court-circuit. Nous n'avons pas à nous demander si la chaleur dégagée par la
condition if
peut se dissiper à travers la boucle
while
qui l'entoure. Nous n'avons pas à nous demander si la
boucle while
causerait une chute de tension telle que la
condition if
ne fonctionnerait plus correctement. Quand vous
testez la valeur d'une variable, vous n'avez pas à vous demander si vous
avez référencé cette variable de si nombreuses fois que sa limite de
sortance [fan-out] est dépassée. Vous n'avez pas à vous
demander quelle est la capacité électrique d'une certaine variable et
combien de temps il faudra pour l'amener à sa valeur.
Toutes ces choses sont définies, le système est défini pour fonctionner d'une certaine façon et c'est ce qu'il fait toujours. L'ordinateur physique peut être en panne, mais ce n'est pas la faute du programme. Aussi, du fait que nous n'avons pas à traiter tous ces problèmes, notre spécialité est immensément plus facile.
Supposons que l'intelligence des programmeurs soit la même que l'intelligence des ingénieurs mécaniciens, des ingénieurs électriciens, des ingénieurs chimistes, etc. Qu'est ce qui va se passer ? Ceux d'entre nous qui sont dans une spécialité en principe plus facile vont la pousser plus loin. Nous construisons des choses de plus en plus grandes, et finalement cela redevient difficile. Voilà pourquoi nous pouvons développer des systèmes beaucoup plus grands que les gens travaillant dans d'autres spécialités. C'est seulement qu'ils ont en permanence ces problèmes difficiles à traiter. Dans les autres spécialités, il peut être nécessaire de « développer » une idée : on a une idée, mais ensuite il arrive qu'on doive l'essayer de nombreuses manières différentes avant qu'elle ne commence à fonctionner. Dans le logiciel, ce n'est pas comme ça ; on a une idée, puis on écrit un programme qui la met en application. Ensuite les utilisateurs peuvent l'apprécier ou non. Et s'ils ne l'apprécient pas, on peut probablement se contenter de corriger quelques détails et ça marche.
Il y a un autre problème dont nous n'avons pas à nous occuper : la
fabrication de copies. Quand nous mettons cette condition if
dans la boucle while
, nous n'avons pas à nous demander comment
if
va être insérée dans while
lorsqu'une copie
sera fabriquée. Nous n'avons pas non plus à faire en sorte que la condition
if
soit accessible, au cas où elle grillerait et qu'on devrait
la remplacer. Tout ce que nous avons à faire, c'est de taper
copy
; et il s'agit d'une commande universelle pouvant copier
n'importe quoi. Les gens qui fabriquent des appareils et des produits
physiques ne peuvent pas faire ça, ils doivent les fabriquer un par un à
chaque fois.
Pour eux, au final, la conception d'un ensemble d'une certaine complexité peut coûter cette somme (geste), et l'installation de l'usine, cette somme. Les coûts additionnels qu'entraîne le système de brevets, ils peuvent s'en accommoder. Pour nous, la conception coûte ceci (geste) et la fabrication, ceci ; en comparaison, les frais additionnels qu'entraîne ce système sont écrasants.
Voici une autre façon de voir les choses : puisque nous pouvons (quelques-uns d'entre nous le peuvent) créer un ensemble beaucoup plus grand, il y a beaucoup plus de points de vulnérabilité où quelqu'un pourrait avoir déjà breveté quelque chose. Nous devons parcourir une longue distance à travers le champ de mine alors qu'ils n'ont que quelques mètres à faire. Ainsi le système est beaucoup plus dangereux pour nous que pour eux.
Vous devez comprendre que l'objectif affiché du système de brevets est de promouvoir le progrès. On l'oublie souvent parce que les sociétés qui tirent profit des brevets aimeraient détourner votre attention de ce détail. Elles aimeraient vous convaincre que les brevets ont été créés parce qu'elles méritent un traitement spécial. Mais ce n'est pas ce que dit le système de brevets. Le système de brevets dit : mon but est de promouvoir le progrès au bénéfice de la société en encourageant certains comportements comme de publier les idées nouvelles, pour qu'après un certain temps – à l'origine, c'était un temps assez court – tout le monde puisse les utiliser.
Naturellement la société, de son côté, paie un certain prix, et nous devons nous poser la question : quel est le plus grand, le bénéfice ou le prix. Bon, dans les autres spécialités, je ne suis pas sûr. Je ne suis pas expert dans les autres spécialités de l'ingénierie, je ne les ai jamais étudiées et je ne sais pas si les brevets sont bons pour le progrès dans ces spécialités.
J'ai commencé à travailler dans le logiciel avant que les brevets logiciels n'existent, et je sais qu'ils font beaucoup de mal et presque pas de bien. Autrefois, les idées allaient et venaient. Ou bien des personnes travaillant à l'université avaient une idée, ou bien quelqu'un avait une idée alors qu'il travaillait au développement d'un logiciel. Dans les deux cas, ces idées étaient publiées et ensuite tout le monde pouvait les utiliser. Cela dit, pourquoi les éditeurs de logiciels publiaient-ils ces idées ? Parce qu'ils savaient que le gros du travail était d'écrire le programme.
Ils savaient qu'en publiant les idées ils obtiendraient la reconnaissance de la communauté, et que pendant ce temps-là quiconque voudrait leur faire de la concurrence devrait de toute façon écrire un programme, ce qui représente le gros du travail. Aussi, typiquement, ils gardaient secrets les détails du programme (naturellement, quelques-uns d'entre nous pensent que c'est mal, mais c'est une autre question), ils gardaient secrets les détails du programme et publiaient les idées. En même temps, le développement logiciel (parce que le développement logiciel suivait son cours) alimentait ce domaine avec un flot continu d'idées, de sorte que les idées n'étaient pas le facteur limitant. Le facteur limitant était l'écriture de programmes qui fonctionnent et que les gens apprécient.
Donc en réalité, l'application du système de brevets au logiciel s'efforce de faciliter une étape qui n'est pas le facteur limitant, tout en créant des difficultés à une étape qui est le facteur limitant. Vous voyez, les brevets logiciels encouragent quelqu'un à avoir une idée, et en même temps ils encouragent les gens à restreindre son utilisation. De fait, nous sommes plus mal lotis maintenant en termes d'idées utilisables : autrefois les gens publiaient leurs idées, ainsi nous pouvions nous en servir, alors que maintenant ils prennent des brevets dessus, et nous ne pouvons pas nous en servir pendant vingt ans. En attendant, le vrai facteur limitant – qui est de développer les programmes – est gêné par les brevets logiciels à cause d'autres dangers que je vous ai expliqués dans la première moitié de cette conférence.
En fin de compte, alors que ce système était censé faciliter le progrès du logiciel, il est si mal fichu qu'il a pour seul résultat de faire obstruction au progrès.
Nous avons aujourd'hui une étude économique qui montre mathématiquement comment cela peut se produire. Vous la trouverez à www.researchoninnovation.org. Je ne suis pas tout à fait sûr du titre de l'article, mais il montre que, dans une spécialité où l'innovation par sauts discontinus est la règle, avoir un système de brevets peut aboutir à ralentir le progrès. En d'autres termes, le système produit des effets contre-intuitifs, à opposé de ceux qu'il était censé produire. Ceci conforte la conclusion intuitive de chaque programmeur, qui constate l'absurdité des brevets logiciels.
Que peut donc faire un pays pour éviter ce problème ? Eh bien, il y a deux approches : l'une est d'attaquer le problème au niveau de l'attribution des brevets, l'autre est de l'attaquer au niveau de l'application des brevets.
Le faire au niveau de l'attribution des brevets n'est pas tout à fait aussi facile que vous pourriez le croire. En effet j'ai parlé des brevets logiciels, mais en toute rigueur on ne peut pas classer les brevets en brevets matériels et brevets logiciels, parce qu'un même brevet peut couvrir à la fois du matériel et du logiciel. En fait, selon ma propre définition, un brevet logiciel est un brevet qui peut freiner le développement logiciel.
Si vous examinez beaucoup de brevets logiciels, vous verrez que, souvent, le système qu'ils décrivent comporte une partie importante à propos de l'ordinateur lui-même, dans la description de ce qui se passe. C'est une très bonne façon de faire paraître l'ensemble compliqué alors qu'en fait c'est trivial. C'est une des manières qu'ils ont de convaincre l'office des brevets que c'est non évident.
Mais on peut prendre un critère différent, un endroit un peu différent où tracer la limite, qui produise tout de même un résultat acceptable. On peut la mettre entre les processus qui transforment la matière d'une manière spécifique, et ceux dont le résultat est seulement le calcul et l'affichage d'information, ou bien une combinaison d'étapes de traitement de données et d'affichage. D'autres ont formulé ceci comme « des étapes mentales concrétisés par l'équipement ». Il y a diverses façons de formuler ceci, plus ou moins équivalentes.
Ce n'est pas exactement la même chose que d'interdire les brevets logiciels, parce que dans certains cas les ordinateurs font partie d'un équipement physique particulier et lui permettent de faire une tâche particulière. On pourrait donc autoriser les brevets logiciels s'ils font partie d'une tâche physique particulière, mais ce ne serait pas vraiment catastrophique. Après tout, à partir du moment où des gens sont impliqués dans une tâche physique particulière ou dans un produit physique particulier, ils introduisent dans l'ensemble de leur entreprise toute la complexité du travail avec la matière. Cela se rapproche des autres spécialités de l'ingénierie. Peut-être que c'est une bonne chose d'avoir des brevets sur ces logiciels à objectif restreint. Tant que nous pouvons garder les domaines fondamentaux du logiciel, les tâches purement logicielles, à l'abri des brevets, nous avons résolu l'essentiel du problème.
Donc c'est une approche réaliste, et c'est ce à quoi les gens travaillent en Europe. Cependant cela ne servira à rien aux États-Unis, parce que les États-Unis ont déjà des dizaines, et probablement des centaines de milliers de brevets logiciels. Un changement quelconque dans les critères d'attribution des brevets ne serait d'aucune utilité pour les brevets qui existent déjà.
Ce que je propose donc pour les États-Unis, c'est de changer les critères d'application des brevets, comme ceci : les systèmes purement logiciels fonctionnant sur du matériel informatique généraliste sont immunisés contre les brevets. Par définition, ils ne peuvent pas enfreindre de brevet. De cette façon, les brevets peuvent continuer à être attribués exactement comme ils le sont actuellement et, d'un point de vue formel, ils peuvent toujours couvrir à la fois la mise en œuvre de matériel et la mise en œuvre de logiciel comme ils le font actuellement. Mais le logiciel sera en sécurité.
C'est la solution que je propose pour les États-Unis, mais elle peut aussi s'appliquer à d'autres pays.
Cela dit, la plupart des pays sont actuellement confrontés à un immense danger, l'Organisation mondiale du commerce, qui établit un système commercial régulé par les grandes sociétés – pas un commerce libre, comme ses partisans aiment à l'appeler, mais un commerce régulé par les grandes sociétés. Elle transfère la régulation du commerce, opérée actuellement par des États quelque peu démocratiques pouvant prêter l'oreille à l'intérêt de leurs citoyens, au monde des affaires qui, lui, ne prétend pas écouter les citoyens. Elle est donc fondamentalement antidémocratique et devrait être abolie.
Mais il est essentiel de noter que la partie du GATTg qui traite des brevets n'exige pas les brevets logiciels. C'est ce qu'affirment de nombreux experts qui ont étudié la question, par exemple en Europe, car ils interprètent « effet technique » [technical effect] comme le fait que [le fonctionnement du logiciel] doit avoir une conséquence physique ou actionner un système physique particulier. Et donc un logiciel qui ne fait pas cela ne doit pas appartenir à la catégorie que les brevets peuvent couvrir.
Cela veut dire qu'au moins vous n'avez pas à vous inquiéter des problèmes causés par l'Organisation mondiale du commerce, malgré les problèmes énormes qu'elle cause dans d'autres sphères de la vie.
Préserver l'Inde des brevets logiciels sera votre affaire, l'affaire des citoyens de l'Inde. Je suis un étranger, je n'ai aucune influence sauf quand j'arrive à convaincre d'autres personnes par la logique de ce que je dis. Il y a une chance que vous y arriviez. Quand les États-Unis ont commencé à avoir des brevets logiciels, la question de politique publique n'a pas du tout été prise en compte. Personne ne s'est même demandé si les brevets logiciels étaient une bonne idée. La Cour suprême a rendu une décision qui a été ensuite détournée par une cour d'appel, et depuis il y a des brevets logiciels.
Mais lorsqu'il y a quelques années l'Europe a envisagé officiellement d'autoriser les brevets logiciels, l'opposition publique s'est manifestée et a pris une telle ampleur que les politiciens et les partis ont commencé à y prêter attention et ont commencé à dire qu'ils étaient contre. En fait, deux tentatives d'autoriser les brevets logiciels ont déjà été bloquées en Europe. Le ministre français de l'Industrie dit que les brevets logiciels seraient un désastre et en aucune circonstance ne devraient être permis en France. En Allemagne, tous les partis politiques ont pris position contre les brevets logiciels.
La bataille n'est pas encore terminée, vous savez. Nous n'avons pas bloqué définitivement les brevets logiciels en Europe, parce que les sociétés multinationales et leur serviteur, le gouvernement des États-Unis, font un lobbying effréné, et qu'ils ont l'ignorance de leur côté. Il est si facile de persuader une personne ayant une vue naïve néolibérale de la question que ce monopole d'un nouveau genre doit être une bonne chose !
Il faut examiner en détail comment les brevets logiciels affectent le développement logiciel pour voir qu'ils posent problème. Il faut étudier la recherche économique dont je vous ai parlée dans tous ses détails mathématiques pour voir pourquoi on ne doit pas poser en principe qu'ils sont toujours facteurs de progrès. Il est facile pour IBM d'envoyer un lobbyiste dire à quelqu'un : « Vous devriez vraiment adopter les brevets logiciels, ils sont formidables pour la programmation. Regardez les États-Unis, ils sont en avance et ils ont les brevets logiciels. Si vous aviez les brevets logiciels vous aussi, vous pourriez les rattraper. » Bon, on ne peut pas aller plus loin dans la domination, et les États-Unis étaient en tête en informatique avant d'avoir des brevets logiciels. Ce ne peut donc pas être à cause des brevets logiciels.
Il est important de comprendre que chaque pays a son propre système de brevets et sa propre législation sur les brevets. Ce que vous faites dans un pays donné est placé sous la juridiction de ce pays. Par conséquent, du fait que les États-Unis ont des brevets logiciels, ils deviennent une sorte de champ de bataille où toute personne qui utilise un ordinateur peut faire l'objet d'une procédure. Si l'Inde évite les brevets logiciels, l'Inde ne sera pas un champ de bataille et les utilisateurs d'ordinateurs en Inde ne risqueront pas d'être poursuivis.
Il se trouve que chaque pays accorde des brevets à des étrangers aussi bien qu'à ses propres citoyens. Donc en fait, dans un endroit qui a ce fléau des brevets logiciels, les étrangers peuvent en détenir. Il y a des tas de sociétés non américaines qui possèdent des brevets logiciels aux États-Unis, et elles sont toutes invitées à prendre part à la bataille aux États-Unis. Naturellement c'est nous, les Américains, qui en sommes les victimes. Pendant ce temps-là, si l'Inde ne reconnaît pas les brevets logiciels, cela veut dire que ni les sociétés indiennes, ni les sociétés étrangères ne peuvent venir en Inde attaquer les gens avec des brevets logiciels.
Donc oui, il est important que chaque pays ait son propre droit des brevets. Cela fait une grande différence, mais vous devez comprendre quelle différence ça fait. L'adoption des brevets logiciels par un pays donné n'avantage pas les développeurs de ce pays. C'est un problème pour quiconque y distribue et y utilise des logiciels.
Si vous, en Inde, développez un programme qui sera utilisé aux États-Unis, vous pouvez vous heurter, ou du moins votre client se heurtera, au problème des brevets logiciels américains. Au moins, il est probable que vous ne pouvez pas être poursuivi ici. Le client qui a passé commande du programme et essayé de l'utiliser peut être poursuivi aux États-Unis, et effectivement vous allez devoir traiter le problème – les problèmes des États-Unis – quand vous essayez de faire des affaires là-bas. Mais au moins, ici vous serez en sécurité. Il y a une grande différence, voyez-vous, entre une procédure contre votre client parce qu'il vous a dit de faire un produit et que ce produit est breveté, et une procédure contre vous pour avoir fabriqué ce produit.
S'il y a des brevets logiciels en Inde, alors vous ferez l'objet de poursuites. Tandis que dans le contexte actuel, au moins vous pouvez dire à votre client : « Vous nous avez demandé de faire ceci et nous l'avons fait. Je suis désolé de ce qui vous arrive mais ce n'est pas notre faute. » Tandis que s'il y a des brevets logiciels en Inde, vous serez vous-mêmes poursuivi et vous ne pourrez rien dire.
En fin de compte, les brevets logiciels enferment tous les développeurs, tous les utilisateurs de l'informatique et pratiquement toutes les entreprises dans une nouvelle sorte de bureaucratie qui n'a aucune utilité sociale. Donc c'est un mauvais choix politique, qui doit être rejeté.
Les entreprises n'aiment pas la bureaucratie. Si elles avaient su qu'elles étaient menacées de cette bureaucratie d'un nouveau genre, elles se seraient opposées très fermement aux brevets logiciels. Mais la plupart n'en ont pas conscience.
Aux États-Unis, les brevets logiciels ont conduit directement à des brevets sur les « méthodes économiques » [business methods]h. Qu'est-ce que ça signifie ? Une méthode économique est essentiellement la manière dont on prend les décisions sur ce qui doit être fait dans l'entreprise. Par le passé, ces décisions étaient prises par des humains, mais maintenant elles sont quelquefois prises par des ordinateurs ; ça veut dire qu'elles sont prises par des logiciels, donc ça veut dire que les politiques décisionnelles peuvent être brevetés. Les brevets logiciels impliquent les brevets sur les méthodes économiques et sur les procédures d'entreprise. Le résultat, c'est que n'importe quelle entreprise qui déciderait d'automatiser la réalisation de ses procédures pourrait être poursuivie à cause d'un brevet logiciel.
Si seulement les entreprises savaient cela, elles s'organiseraient, par l'intermédiaire des chambres de commerce par exemple, pour exiger l'opposition aux brevets logiciels. Mais la plupart ne le savent pas et par conséquent cela va être votre travail de les informer. Assurez-vous qu'elles comprennent le danger auquel elles sont confrontées.
Alors l'Inde pourra peut-être, avec l'aide d'autres pays comme la France et l'Allemagne, rejeter les brevets logiciels. C'est important que les gens du gouvernement indien prennent contact avec les officiels des pays européens pour que cette bataille contre les brevets logiciels n'ait pas à être menée par un pays à la fois, pour que les pays puissent coopérer pour adopter une politique intelligente. Peut-être devrait-il y avoir un « traité contre les brevets logiciels » [no-software patent treaty] que divers pays pourraient signer pour se promettre mutuellement de l'aide quand ils sont menacés par la pression économique des États-Unis, manifestation de leur impérialisme économique.
Parce que les États-Unis aiment bien faire cela, vous savez. Une des clauses du GATT est que les pays ont le droit d'établir des licences obligatoires pour fabriquer des médicaments, afin de répondre à une crise de santé publique. Le gouvernement d'Afrique du Sud s'est proposé de le faire pour les médicaments contre le SIDA. L'Afrique du Sud a un problème très grave avec le SIDA ; j'ai entendu dire qu'un quart de la population adulte est infectée. Et naturellement la plupart des gens ne peuvent pas se permettre d'acheter ces médicaments au prix demandé par les sociétés américaines.
Ainsi le gouvernement d'Afrique du Sud était sur le point d'établir des licences obligatoires que même le GATT autorise, mais le gouvernement des États-Unis l'a menacé de sanctions économiques. Le vice-président Gore était directement impliqué. Et puis, un an avant l'élection présidentielle à peu près, il a réalisé que cela ferait mauvais effet et il s'est retiré de cette action.
Mais c'est le genre de chose que le gouvernement des États-Unis fait tout le temps, à propos de brevets et de copyrights. Cela ne les dérange même pas si les gens sont brevetés à mort.
Donc c'est important que les pays se concertent pour agir contre cela.
Pour des informations supplémentaires à propos des problèmes de brevets logiciels, voir www.progfree.org [archivé] et www.ffii.org. Et il y a aussi une pétition à signer sur www.noepatents.org [1]
S'il vous plaît, parlez à tous les dirigeants d'entreprises – toutes sortes d'entreprises – de cette question. Assurez-vous qu'ils comprennent l'étendue des problèmes auxquels ils sont confrontés, et donnez-leur l'idée de se rapprocher de leurs organisations professionnelles pour qu'elles fassent du lobbying contre les brevets logiciels.
Maintenant, je vais répondre aux questions.
Au fait, à tous les journalistes qui sont ici, je recommande d'écrire des articles séparés sur les brevets logiciels et sur le logiciel libre. Si vous couvrez tout dans un seul article, les gens resteront sur l'idée que les brevets logiciels ne sont mauvais que pour les développeurs de logiciel libre et sont OK pour les autres développeurs de logiciel. Ce n'est pas vrai. Si vous repensez à ce que vous ai dit, presque rien ne se rapporte à la question de savoir si les programmes sont libres ou non ; les dangers sont les mêmes pour tous les développeurs. Donc, s'il vous plaît, ne prenez pas de risque, les gens s'embrouilleraient les idées. Écrivez des articles séparés.
Pour développer des programmes non triviaux, vous allez être obligés d'enfreindre des brevets d'IBM. Cela dit, si vous êtes gros et que vous avez souvent de la chance, vous pourriez avoir quelques brevets à vous et amener IBM à négocier des licences croisées avec vous. Autrement, vous êtes complètement à sa merci ; votre seul espoir est qu'elle se contente de vous laisser payer.
Une autre question ?
La plupart des programmeurs ne sont pas d'accord avec vous.
C'était comme ça avant les brevets logiciels. Si vous écriviez le programme vous-même, il n'y avait aucune raison de vous poursuivre. Aujourd'hui, vous pouvez écrire le programme vous-même, il peut même être utile et innovant, mais parce que vous n'avez pas réinventé l'ensemble de la spécialité, que vous avez utilisé des idées qui étaient déjà connues, d'autres personnes vous poursuivront. Naturellement, ces autres personnes qui cherchent une occasion de vous poursuivre, elles vont prétendre que cette extorsion représente pour elles une protection. Protection de quoi ? Protection de la concurrence, je parie. Ils ne croient pas à la concurrence, ils veulent des monopoles.
Eh bien, qu'ils aillent au diable. Ce n'est pas bon pour le public qu'ils obtiennent ce qu'ils veulent. C'est une question de politique publique. C'est à nous de décider ce qui est bon pour les citoyens dans leur ensemble.
Auditoire : [applaudissements]
Ne laissons pas quelqu'un nous dire : « Je veux un monopole parce que je suis si important que j'y ai droit, donc interdisez à tous les autres de développer du logiciel. »
Donc n'essayer pas d'avoir une opinion sur la propriété intellectuelle. Quand vous réfléchissez à la propriété intellectuelle, vous réfléchissez à un niveau simpliste. Faites donc comme moi, vous savez, prenez un sujet à la fois et concentrez-vous dessus, découvrez les détails de ce sujet, et ensuite vous pourrez y réfléchir intelligemment. Plus tard, vous réfléchirez aussi de manière intelligente sur les autres sujets.
Premièrement, affirmez clairement que les brevets ordinaires ne s'appliquent pas et, deuxièmement, si vous voulez, vous pouvez créer un système différent établissant un monopole de cinq ans sur les idées logicielles. Bon, il n'est pas évident que ces monopoles de cinq ans aient un avantage particulier, mais ce serait bien mieux que la situation actuelle. Donc si vous estimez que le gouvernement est prêt à faire cette transaction, je dirais, allez-y. Mais il faut bien comprendre, toutefois, que la première étape est d'abolir les brevets logiciels proprement dits, et que cela doit faire partie de la transaction.
OK, si vous voulez faire passer une note, vous feriez mieux de la lire tout haut. Une autre question ?
En Inde, vous prenez sans doute pour acquis que vous en êtes préservés. Mais cela durera seulement tant que l'Inde n'aura pas de brevets logiciels.
L'important donc, c'est que nous ne leur en donnions pas l'occasion. Par exemple, nous n'avons pas d'agence gouvernementale qui distribue des fusils aux gens dans la rue ; de même, il ne faut pas avoir d'agence gouvernementale qui distribue des brevets logiciels aux gens dans la rue.
Nous avons rassemblé des exemples de cela et cherchons des gens pour en rédiger un compte-rendu – vous savez, examiner chaque exemple, faire une recherche complète à son sujet et rédiger une description claire de ce qui est arrivé, quels dommages ont été causés, etc. Nous avons du mal à trouver des gens pour le faire. Nous cherchons plus de monde. Une personne qui aurait de très bonnes compétences en anglais écrit pourrait vouloir nous offrir son aide.
Donc il semble que nous soyons maintenant arrivés aux questions sur le logiciel libre. Je voudrais vous rappeler que jusqu'à cette dernière réponse, je ne parlais pas pour le mouvement du logiciel libre. Je parlais d'une question vitale pour chaque programmeur : être libre d'écrire des programmes et de ne pas être poursuivi pour les avoir écrits, tant qu'on les a écrits soi-même. C'est cette liberté que vous avez toujours tenue pour acquise jusqu'à présent, et c'est cette liberté que vous perdrez si vous avez des brevets logiciels.
Maintenant cependant, nous en arrivons au sujet du logiciel libre, sur lequel j'ai passé la plus grande partie de mon temps, et du projet de développement logiciel particulier que je conduis effectivement ; il s'agit du développement du système d'exploitation GNU, qui est un système de type Unix, constitué de logiciel libre et utilisé, d'après les estimations, par environ vingt millions de personnes dans le monde. Je vais donc répondre aux questions sur le logiciel libre et GNU.
Je ne peux pas vous dire ce qui va arriver. Ce que je peux vous dire, c'est que, lorsqu'IBM prétend avoir mis un milliard de dollars dans le système d'exploitation GNU plus Linux, ce n'est pas tout à fait vrai. Regardez soigneusement à quoi ils dépensent cet argent, et vous verrez qu'ils le dépensent dans plusieurs choses différentes, dont certaines sont une contribution et d'autres non.
Par exemple, ils financent un travail sur le développement du système GNU/Linux. C'est bien, c'est une contribution. Ils développent même quelques autres paquets de logiciels libres qu'ils ont donnés à la communauté. C'est une vraie contribution.
Ils développent aussi beaucoup de programmes non libres pour les faire tourner avec le système GNU/Linux, et cela n'est pas une contribution. Et ils font de la publicité pour ce système. Bon, ce n'est pas une contribution essentielle, mais cela aide, vous savez. Notre objectif principal n'est pas d'avoir plus d'utilisateurs, mais c'est une bonne chose que plus de gens essaient nos logiciels. Donc oui, cela aide. Mais ils commettent une erreur en appelant ceci Linux, ce qui n'est pas tout à fait exact. Par ailleurs, ils font du lobbying en Europe en faveur des brevets logiciels, ce qui est mauvais. Donc, vous savez, IBM fait beaucoup de choses différentes, quelques-unes bonnes, d'autres mauvaises, et pour avoir un avis réfléchi, il est important d'examiner chaque action individuellement. N'essayez pas de les additionner, car cela voudrait simplement dire que vous passez à côté des aspects importants de la situation.
Est-ce qu'il y a encore des questions ?
if
et la boucle while
. Vous avez dit quelque chose
à propos des différences entre l'informatique et les autres sciences, je
veux dire les autres sciences de l'ingénieur. Vous avez dit que si je change
quelque chose dans la condition if
, il n'y aura aucun
effet. C'est ce que vous avez dit…if
…Pourtant, il y a une chose que je n'aime pas, c'est quand les sociétés qui le font lui ajoutent du logiciel non libre.
Voilà le principal problème auquel notre communauté est confrontée actuellement, la tendance à mélanger le logiciel libre avec le logiciel non libre pour produire ces systèmes globaux non libres. Et puis, vous savez, il peut sembler que nos logiciels aient du succès parce que beaucoup de gens les utilisent. Mais notre véritable objectif, ce n'est pas d'être populaires, c'est de développer une communauté de liberté. Nous ne réussirons pas à atteindre cet objectif si les gens continuent à utiliser des logiciels non libres.
Malheureusement, je ne pouvais pas faire les deux conférences. Je pouvais soit donner la conférence sur les brevets logiciels, soit donner celle sur le logiciel libre. Elles sont très différentes et chacune est très longue. Donc malheureusement, cela veut dire que je ne peux pas vous donner toutes les explications sur le logiciel libre et le projet GNU ici. Est-ce que je dois donner une autre conférence à Kochi ? Est-ce que je dois donner la conférence sur le logiciel libre à Kochi ?
Alors je vais répondre à cinq questions supplémentaires et ce sera tout, parce que cela devient épuisant de répondre à tant de questions.
Ainsi, je dirais, une personne qui utilise Windows, eh bien, elle soutient activement cette structure de pouvoir, ou du moins elle en est prisonnière et n'a pas le courage de s'en échapper. Dans ce cas-là on peut lui pardonner, je suppose, et l'encourager. Vous savez, il existe une variété de situations en chaque lieu où il y a des gens différents. Certaines personne font plus ou moins d'efforts pour essayer d'améliorer les choses. Je crois qu'il faut juger les gens sur le plan individuel, pas en bloc suivant le groupe auquel ils appartiennent.
Mais dans ce cas précis, c'est un peu comme un choix politique qui a des conséquences sur la société, et c'est exactement pour cela qu'il est raisonnable de critiquer les gens.
Note: A cet endroit, il y a eu une courte panne de courant. L'enregistrement et la transcription sont donc incomplets.
Ce sera la dernière question.
C'était donc la dernière question. Je ne peux pas rester toute la journée à répondre aux questions, j'en suis désolé. Maintenant, je vais devoir mettre fin au débat et aller déjeuner. Merci de m'avoir écouté.
[Applaudissements]
[1] En 2012, la pétition contre les brevets logiciels dont il est question ici est archivée.
Voir également notre campagne pour la disparition des brevets logiciels pour plus d'information sur ce sujet.