Le danger des brevets logiciels (2001)

par Richard Stallman

↑ Présentation du conférencier

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 Machinery ^c 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é.

↑ Conférence de Stallman

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 deux choses qui ne vont pas dans l'expression « propriété intellectuelle »

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.

↑ Les copyrights et les brevets n'ont rien à faire ensemble

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 :

• Un copyright s'applique à une œuvre particulière, la plupart du temps écrite, et il concerne les détails de cette œuvre. Les idées en sont complètement exclues. Les brevets, au contraire… Eh bien, un brevet couvre une idée. C'est aussi simple que ça. Décrivez-moi n'importe quelle idée, c'est une idée qu'un brevet pourrait vous empêcher de mettre en application.
• Les copyrights ont à voir avec le plagiat ; si vous aviez écrit quelque chose qui soit mot pour mot identique à un certain roman à succès et que vous puissiez prouver que vous l'avez fait alors que vous étiez enfermé dans une pièce, sans avoir jamais vu ce roman, ce ne serait pas une infraction au copyright parce que ce n'est pas du plagiat. Mais un brevet est un monopole absolu sur l'utilisation d'une idée particulière. Même si vous pouviez démontrer que vous y avez pensé tout seul, ce serait considéré comme absolument non pertinent. Cela ne vous aiderait pas.
• La mise sous copyright est automatique. Dès lors que l'on a écrit quelque chose, c'est sous copyright. Les brevets, par contre, sont octroyés à la suite d'un processus de demande qui coûte cher. Il y a des frais importants, et encore des dépenses supplémentaires pour payer les avocats, ce qui naturellement favorise les grosses sociétés. L'office des brevets dit qu'il n'octroie de brevets que pour des choses non évidentes. Mais en pratique, dans beaucoup d'offices de brevets, le critère est plutôt : « non évident pour une personne ayant un QI de 50 ». Et ils donnent toutes sortes d'excuses pour ignorer le fait qu'après avoir regardé le brevet, n'importe quel programmeur s'écrie : « C'est absurde, c'est évident ! » Ils répondent : « Bon, cela semble évident après coup. » Ainsi ils ont une excuse facile pour ignorer complètement le jugement de tout vrai programmeur.
• Le copyright dure extrêmement longtemps. Aux États-Unis de nos jours, les copyrights peuvent durer près de 150 ans, ce qui est absurde. Les brevets, eux, ne durent pas aussi longtemps ; ils durent seulement longtemps – vingt ans, ce qui dans le monde du logiciel est long, vous l'imaginez bien.

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.

↑ Comment marche le système de brevets

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 « recalcul ^d 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 raisonnable ^e 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.

↑ Vous devez travailler avec un avocat

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 :

• essayer de contourner le brevet,
• essayer d'en obtenir une licence d'exploitation
• ou bien essayer d'en contester la validité devant les tribunaux.

Chacune des trois est quelquefois une alternative viable, quelquefois elle ne l'est pas.

↑ Contourner le brevet

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.

↑ Obtenir une licence d'exploitation

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 Freedom ^f, 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.

↑ Contester la validité du brevet

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.

↑ Personne ne peut réinventer complètement le domaine du logiciel

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é.

↑ La relation entre brevets et produits varie suivant les spécialités

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 cela ? C'est 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.

↑ Le développement de programmes est freiné par les brevets logiciels

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 faire un pays pour éviter ce problème ?

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 aux citoyens de l'Inde de préserver leur pays des brevets logiciels

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 GATT ^g 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.

↑ Les entreprises doivent exiger l'opposition aux brevets logiciels

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.

↑ C'est important que les pays se concertent pour agir contre cela

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.

↑ Questions de l'auditoire

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.

↑ Questions sur les brevets logiciels

Q : Monsieur, vous avez dit que, pour des sociétés comme IBM, le dommage est dix fois le profit ?

R : Non. Ce que j'ai dit, c'est que le dommage qu'elles auraient subi est dix fois le profit. Mais ce dommage est purement théorique, il ne se produit pas. Vous voyez, elles l'évitent par des licences croisées. Donc en fait ce dommage ne se produit pas.

Q : Mais il est simplement neutralisé. Ils ne font pas vraiment de profit ?

R : Si, ils en font, voyez-vous, parce que les inconvénients, ils les évitent par des licences croisées, et en même temps ils collectent effectivement de l'argent avec quelques autres licences. Donc au final ils font du profit. Il y a le petit profit, qui est réel, et le gros dommage potentiel, qui ne se produit pas. Donc, comme profit, vous avez zéro plus quelque chose.

Q : Mais pour ce quelque chose, ils vont s'opposer à ce mouvement contre les brevets ?

R : Exact. IBM est en faveur des brevets logiciels. J'ai eu du mal, je n'ai pas entendu tous les mots de votre phrase. Je ne sais pas s'il y avait une négation dedans, je ne pouvais pas distinguer ; il y a deux sens possibles diamétralement opposés à ce que vous venez de dire. Donc veuillez vous assurer que c'est clair dans votre esprit. IBM est en faveur des brevets logiciels, IBM pense qu'elle a beaucoup à gagner avec les brevets logiciels. Ce qu'elle a à gagner, c'est qu'IBM et les autres très grandes sociétés finissent par contrôler en pratique le développement logiciel, parce qu'il sera très difficile de faire du développement indépendant.

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 ?

Q : Monsieur, pourquoi les brevets logiciels ont-ils été développés ?

R : Eh bien, aux États-Unis, il n'y avait pas de raison. Quelqu'un a essayé d'obtenir un brevet qui était un brevet logiciel. Je pense que l'office des brevets a dit non, alors il est allé au tribunal et finalement devant la Cour suprême. Ils n'ont pas envisagé le cas comme une question de politique publique, ils l'ont jugé selon ce qui est écrit dans la loi.

Q : Donc, ce n'était pas parce qu'ils se sont rendu compte que…

R : Désolé, je ne peux pas… Pourriez-vous essayer de prononcer les consonnes plus distinctement, j'ai du mal à comprendre les mots.

Q : Donc, ce n'était pas parce qu'ils se sont rendu compte que le copyright est manifestement faible pour protéger le logiciel ?

R : Le copyright n'est pas seulement quoi ?

Q : Manifestement faible…

R : Eh bien, je pense que toute cette phrase n'a aucun sens. Je ne comprends pas l'expression « protéger le logiciel » et je ne suis pas d'accord avec vous.

La plupart des programmeurs ne sont pas d'accord avec vous.

Q : Quand vous dites que vous n'êtes pas en faveur de la protection du logiciel et que vous-même proposez la licence publique générale, d'où tirez-vous ce pouvoir d'attribuer la licence publique générale ?

R : OK, vous posez une question sur le copyright et le logiciel libre, ce qui n'est pas le sujet maintenant. J'accepterai les questions à propos de cela plus tard. J'ai donné une conférence sur les brevets logiciels et je veux répondre à des questions sur les brevets logiciels.

Q : Monsieur, j'ai une question sur les brevets logiciels. La question est : comment peut-on protéger quand il y a un élément fonctionnel…

R : Protéger quoi ?

Q : L'élément fonctionnel…

R : Qu'est-ce qui va leur arriver ?

Q : Monsieur, comment pouvons-nous obtenir une protection quand il y a un…

R : Protection contre quoi ? Quelqu'un va venir avec un fusil ?

Q : Non monsieur…

R : La protection dont vous avez besoin, en gros, c'est une protection contre des poursuites à cause du programme que vous avez écrit. Les programmeurs ont besoin d'une protection contre les brevets logiciels.

Q : Non, ce ne sont pas les programmeurs eux-mêmes, il y a des sociétés qui ont investi dans quelque chose ?

R : Et vous voulez que la société soit poursuivie parce que dans votre grand programme il y a cinq choses différentes que quelqu'un, que cinq personnes différentes, ont déjà brevetées ? Maintenant on voit clairement la légende qui est à la base de votre raisonnement. C'est l'idée naïve que lorsque vous développez un programme, vous obtiendrez le brevet. Eh bien, cette idée, sa formulation-même, contient une erreur parce qu'il n'existe rien de tel que le brevet. Quand vous développez un programme avec beaucoup de choses différentes dedans, il y en a un grand nombre qui, chacune, peuvent déjà être brevetées par quelqu'un d'autre. Vous les découvrez l'une après l'autre quand ils viennent vous voir et vous disent : « Donne-nous beaucoup d'argent, ou bien ferme boutique. » Et quand vous avez traité avec cinq d'entre eux, vous ne savez jamais quand le numéro six va arriver. C'est beaucoup plus sûr de travailler dans le logiciel si vous savez que vous n'allez pas êtes poursuivi tant que c'est vous qui avez écrit le programme.

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. »

Q : Vous suggérez que nous devrions éviter de créer un champ de bataille pour les brevets. Mais n'avons-nous pas aussi à considérer le problème des nombreux produits américains qui sont vendus ici, et…

R : Et alors…

Q : … et nous allons continuer à être pris pour… ?

R : Non ! Non, vous avez mal compris. Les développeurs américains peuvent avoir des ennuis à cause du système de brevets. Quel effet cela peut-il avoir ? Il y a certains produits qui ne viendront pas des États-Unis. Par conséquent ils ne seront pas vendus aux États-Unis, ni ici. Vous voyez, si un développeur est aux États-Unis et qu'il y a un brevet américain, il va être poursuivi là-bas ; qu'il essaie ou non de faire des affaires avec quelqu'un en Inde, il va être poursuivi. Mais le fait qu'il distribue le programme en Inde ne va pas lui causer de problème supplémentaire, parce que c'est sous la juridiction de l'Inde. C'est au moins une chose pour laquelle on ne va pas le poursuivre. Donc, cela veut dire essentiellement que tout ce qui existe peut être distribué en Inde, sans danger, et que les développeurs qui ont la chance d'être en Inde seront à l'abri de cette sorte de guerre de gangs, tandis que ceux qui ont la malchance d'être aux États-Unis ne seront pas à l'abri.

Q : Monsieur, êtes-vous fondamentalement contre le concept même de droits de propriété intellectuelle ?

R : Comme je l'ai dit au début, le seul fait de réfléchir sur ce thème est une sottise. C'est une généralisation abusive qui mélange des choses totalement différentes comme les copyrights et les brevets. Aussi, toute opinion sur la « propriété intellectuelle » est une sottise. Je n'ai pas d'opinion sur la propriété intellectuelle. J'ai des opinions sur les copyrights, et j'ai des opinions complètement différentes sur les brevets, et même en ce qui concerne les brevets, j'ai des opinions différentes dans les diverses spécialités. Les brevets eux-mêmes sont un large domaine. Et ensuite il y a les marques déposées qu'on appelle aussi « propriété intellectuelle ». Je pense qu'à la base, les marques déposées sont une bonne idée. Les États-Unis sont allés un peu trop loin avec les marques, mais c'est un principe raisonnable que d'avoir des étiquettes sur lesquelles on peut compter.

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.

Q : On peut argumenter que si un droit de propriété intellectuelle particulier n'est pas protégé…

R : Je suis désolé, ce que vous dites n'a pas le moindre sens, vous vous placez à ce niveau général idiot…

Q : Laissez-moi finir, monsieur. Si ce droit de propriété intellectuelle particulier n'est pas protégé, cela peut faire obstacle à l'investissement, et cet obstacle…

R : Cette manière de penser généralisatrice est si simpliste qu'elle est totalement stupide. Elle n'a aucun sens. Il n'existe pas de principe de propriété intellectuelle. Les copyrights, les brevets et les marques déposées ont des origines complètement distinctes. Ils n'ont rien en commun, à part le fait que, plus tard, quelqu'un a inventé ce terme « propriété intellectuelle » pour les désigner en bloc.

Q : Monsieur, est-ce que vous généralisez ce concept à la propriété physique ?

R : Non, je suis désolé, rien de tout cela n'a à voir avec les droits de propriété physique ; ils sont totalement différents. Que voulez-vous dire par généraliser « ce concept ». Quel est « ce concept » ? L'idée que l'expression « propriété intellectuelle » est une généralisation qui conduit à une réflexion simpliste, est-ce qu'il faut appliquer cette idée à la propriété physique ? Non, elles sont totalement différentes. Elles n'ont rien en commun.

Q : La base sur laquelle repose la protection de la propriété intellectuelle n'est-elle pas la « protection des travailleurs », des « travailleurs intellectuels » ?

R : Non ! Non, vous avez complètement tort, vous avez complètement tort. Le but de… Vous avez été endoctriné. Vous avez écouté la propagande des sociétés qui veulent avoir ces monopoles. Si vous demandez à des chercheurs en droit quelle est la base de ces systèmes, ils vous diront que ce sont des tentatives – je parle des copyrights et les brevets – des tentatives de manipulation du comportement des gens pour procurer un avantage au public. Les marques déposées sont un sujet différent. Je pense que le sujet des marques est complètement différent. Donc, vous faites là encore une généralisation abusive.

Q : Pourquoi ne pouvons-nous pas étendre exactement le même principe…

R : Mais de toute façon votre principe est faux. Si vous jetez un coup d'œil aux études économiques publiées sur www.researchoninnovation.org, vous verrez que vous faites des affirmations naïves, des affirmations généralisatrices et naïves qui ne sont tout simplement pas vraies. Vous partez de l'idée ridicule que créer un monopole sur un des aspects de la vie le fera toujours, invariablement prospérer. Eh bien, c'est stupide. Parfois cela peut marcher, mais d'autres fois cela cause un tas d'ennuis.

Q : Ne pensez-vous pas que l'on crée le même genre de monopole en faveur d'une partie quand elle possède une propriété physique ?

A: Je suis désolé, je ne peux pas vous entendre.

Q : Monsieur, ne pensez-vous pas qu'on crée le même genre de droits de monopole si l'on permet à une personne de posséder une propriété physique particulière, exactement comme une propriété intellectuelle ?

R : La propriété physique ne peut être qu'à un endroit à la fois. Vous savez, il ne peut y avoir qu'une seule personne assise sur une chaise de manière normale. [applaudissements] Vous savez que ce sont des questions complètement différentes. Vous savez qu'essayer de généraliser à outrance est une démarche idiote. Nous avons affaire à des lois compliquées qui ont beaucoup, beaucoup, beaucoup de détails compliqués et vous nous demandez d'ignorer tous ces détails. Nous avons affaire à des lois qui ont des effets compliqués dans divers domaines, et vous nous demandez d'ignorer les détails de leurs effets. Je pense que si nous parlons d'une question de politique publique, nous devons nous intéresser aux résultats concrets de cette politique, pas à une quelconque théorie décrivant les résultats prédits par une certaine idéologie. Je vous parle de résultats concrets. Je vous décris ce que j'ai vu et ce que d'autres programmeurs ont vu.

Q : Monsieur, qu'en est-il du brevet LZW ? Est-il…

R : Qu'en est-il du quoi ?

Q : Brevet LZW ?

R : Le brevet LZW ?

Q : Oui. Est-il encore effectif ?

R : Oui, il l'est. Il y a deux brevets LZW comme je vous l'ai expliqué, et ils sont tous deux encore valides.

Q : Monsieur, ainsi c'est pour vingt ans ?

R : Oui, cela ne fait pas encore vingt ans.

Q : Monsieur, pourrions-nous réduire l'étendue du problème en réduisant la période du brevet ?

R : Tout à fait, on pourrait. S'il y avait des brevets logiciels et qu'ils ne duraient que, disons, cinq ans, ou trois ans, cela résoudrait l'essentiel du problème. Oui, c'est pénible d'avoir à attendre trois ou cinq ans, mais c'est beaucoup, beaucoup moins pénible. Mais… mais il y a là une difficulté : l'accord du GATT dit que les brevets doivent durer vingt ans. Donc, le seul moyen par lequel vous pourriez avoir quelque chose comme un brevet logiciel qui dure trois ou cinq ans est le suivant.

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.

Q : Et les brevets sont maintenant aussi victimes de…

R : Je suis désolé, je n'ai pas pu vous entendre. Pourriez-vous parler plus fort ?

Q : Monsieur, les brevets sont maintenant devenus une manière de faire gagner de l'argent aux entreprises, plutôt que de promouvoir l'innovation ?

R : Oui, c'est comme cela que beaucoup d'entre elles les utilisent.

Q : Donc, Monsieur, pouvons-nous encore réduire ce problème en attribuant le brevet à l'inventeur effectif, plutôt qu'à une entreprise ?

R : Pas vraiment. Ce que l'on observe, c'est que la relation entre le salarié et l'entreprise est négociée, et que l'entreprise a un poids déterminant. Donc à la fin ils s'arrangeront toujours pour que le salarié cède le brevet à la société. D'autre part, cela ne fait pas grande différence qui possède le brevet. Le fait est qu'il vous empêche de développer un programme utilisant cette idée. Qui précisément a la faculté de vous poursuivre, cela peut faire une différence, mais ce que vous voulez vraiment, c'est ne pas être poursuivi du tout. Alors, pourquoi envisager une demi-mesure comme celle-ci ? C'est beaucoup mieux de dire simplement que le logiciel ne doit pas avoir de brevets.

OK, si vous voulez faire passer une note, vous feriez mieux de la lire tout haut. Une autre question ?

Q : Les gens qui sont allés en Malaisie disent que si nous achetons un PC là-bas, le prix de tous les logiciels standards est à peu près le dixième de ce que nous paierions dans notre pays. Est-ce qu'en Malaisie ils sont un peu plus laxistes à propos des brevets et des copyrights ?

R : Êtes-vous sûr de ce dont vous parlez ? Parce que vous semblez mélanger les copyrights et les brevets. Je ne suis pas sûr que ce dont vous parlez ait quoi que ce soit à voir avec le sujet des brevets logiciels.

Q : Voilà précisément ce que je voudrais savoir : est-ce que c'est en rapport avec les brevets ?

R : Probablement pas.

Q : Différents pays, selon qu'ils font partie de l'OMC ou non…

R : Non, non.

Q : … je pense que ça importe…

R : Voyez-vous, je ne suis pas certain parce que je ne sais pas ce qui se passe là-bas. Je n'y suis jamais allé. Mais je soupçonne que c'est un problème de copyright qui n'a rien à voir avec les brevets, parce que si vous parlez des mêmes programmes… Rappelez-vous, les brevets logiciels sont avant tout une restriction pour les développeurs. Donc, si ces programmes ont été développés, disons, aux États-Unis, c'est là-bas que les problèmes de brevets sont les plus graves, pas en Malaisie, ni en Inde. Donc c'est probablement en rapport avec le copyright, pas avec les brevets, ce qui est une question complètement différente. Nous ne devons pas mélanger ces questions.

Q : Monsieur, vous avez dit plus tôt que…

R : Je suis désolé, je ne vous entends pas.

Q : Plus tôt dans votre conférence, vous avez dit que le logiciel qui devrait relever de la compétence des brevets est ce que vous avez défini comme ce qui peut tourner sur une machine généraliste.

R : J'ai peur de ne pas pouvoir… Est-ce que quelqu'un comprend ce qu'il dit ? je ne peux pas comprendre les mots. Si vous essayez de les prononcer plus distinctement, je comprendrai peut-être.

Q : Vous avez dit plus tôt que le logiciel qui devait être breveté est, d'après votre définition, du logiciel pouvant tourner sur une machine généraliste…

R : Je suis désolé. Je n'ai pas dit que le logiciel devait être breveté, donc je ne comprends pas cette formulation. Peut-être que si vous expliquez cela à quelqu'un d'autre, l'autre personne pourrait le dire de manière que je comprenne.

Q : Les brevets logiciels, quoi que ce soit que vous appeliez brevets logiciels, ce sont ceux qui peuvent tourner sur une machine généraliste. Donc si un algorithme ou une partie de logiciel peut être exécuté sur une telle machine, alors il ne doit pas être breveté.

R : Oui. Maintenant je peux vous entendre, oui. Une des choses que j'ai proposées, c'est que les brevets ne s'appliquent pas aux logiciels destinés aux machines généralistes, ni à leurs utilisations sur ces machines. Alors, si vous développez un tel programme ou si vous l'utilisez, vous ne pouvez pas être poursuivi.

Q : Nous avons de plus en plus de logiciels actuellement qui ne tournent pas sur des machines généralistes.

R : Eh bien, alors ceux-là resteraient couverts par des brevets logiciels ; ainsi la solution du problème ne serait pas complète, mais au moins elle serait partielle.

Q : Donc si on place la limite aux machines généralistes, ne voyez-vous pas qu'il y a une possibilité que des gens trouvent des failles, comme des contournements pour…

R : Je suis désolé. Est-ce que je vois la possibilité que les gens fassent quoi ?

Q : … trouvent des failles ou des contournements pour convertir ce que vous appelez brevets logiciels et les breveter effectivement.

R : Je suis désolé, je ne comprends pas. Des failles pour… Je suis désolé. Ce que les gens feraient, ce que les développeurs de logiciel feraient dans ce cas, c'est d'utiliser plus souvent les machines généralistes.

Q : Un certain algorithme peut tourner sur une machine généraliste. Ce que j'ai dit, c'est que cet algorithme, je peux l'utiliser pour un dispositif embarqué [embedded device] et le faire breveter.

R : Pourquoi pas ? Vous pourriez essayer, vous avez mal compris. Le fait est que vous avez mal compris quelle est la solution. La solution est que, si je développe et que j'utilise le logiciel sur une machine généraliste, alors personne ne peut me poursuivre pour avoir enfreint un brevet. Donc oui, quelqu'un pourrait prendre un brevet,) et, peut-être, poursuivre d'autres personnes qui font des choses spécialisées demandant un équipement particulier. Mais ils ne pourraient pas me poursuivre, moi.

Q : Excusez-moi monsieur, est-ce que je peux poser une question ?

R : Oui.

Q : Monsieur, vous avez parlé des machines généralistes. Dans ce sens, comment définiriez-vous ces machines, parce que de nos jours il y a beaucoup d'ordinateurs de poche faits sur mesure, etc. Maintenant une façon…

R : Non, les ordinateurs de poche sont généralistes quand ils n'ont pas été conçus pour un calcul spécifique ou pour un processus physique spécifique. Ce sont des ordinateurs généralistes. Ils contiennent des puces généralistes.

Q : Donc la question de savoir si la machine est généraliste serait contestable devant le tribunal…

R : Je suppose, ce sera sûrement le cas, oui. En fin de compte, on doit laisser aux juges le soin de définir précisément la limite.

Q : Merci, monsieur.

Q : Est-ce que l'Allemagne et la France sont les seuls pays européens qui ont dit non aux brevets logiciels ?

R : Eh bien, je ne connais pas complètement la situation. Ce sont les seuls dont j'aie entendu parler. La dernière fois qu'il y a eu un vote, on prévoyait qu'il y aurait une majorité pour le « non », alors ils ont laissé tomber. Et pour les autres pays, je ne me rappelle pas.

Q : Il n'y a pas de décision de la Communauté européenne à ce sujet…

R : Pas encore. En fait, la Commission européenne elle-même est divisée. Une des directions générales (DG) – malheureusement celle qui conduit la négociation sur cette question – s'est laissé convaincre par les multinationales, et elle est en faveur des brevets logiciels. Celle qui a pour mission d'encourager le développement logiciel est contre, et donc essaie de contrecarrer l'action de la première. S'il y a ici une personne qui veut contacter le responsable de la DG opposée aux brevets logiciels, je peux les mettre en relation.

Q : Est-ce qu'il y a un pays qui a dit non aux brevets logiciels ?

R : Eh bien, il y a des pays qui ne les ont pas, mais il n'est pas certain qu'un pays ait affirmé son refus récemment.

Q : Monsieur, pourriez-vous s'il vous plaît nous donner des détails sur les bénéfices que cette politique a apportés à la communauté du développement logiciel dans les pays européens ?

R : Eh bien, le bénéfice est que vous n'avez pas à craindre d'être poursuivi à cause d'une des idées, ou combinaison d'idées, que vous avez utilisée pour écrire un programme. Essentiellement, les brevets logiciels signifient que si vous écrivez un programme, quelqu'un d'autre pourrait vous poursuivre et dire : « Vous n'êtes pas autorisés à écrire ce programme. » Le bénéfice de ne pas avoir de brevets logiciels est que vous êtes préservés de cela.

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.

Q : Est-ce qu'il y a un danger que l'Inde n'accède pas au régime du logiciel ?

R : Il n'y a pas de régime du logiciel. Les accords du GATT n'exigent pas les brevets logiciels. Il n'y a aucun traité qui exige les brevets logiciels.

Q : La plupart des gens, s'ils avaient une chance d'obtenir un brevet et d'en tirer beaucoup d'argent, ils ne s'en priveraient pas…

R : Eh bien, beaucoup de gens, s'ils avaient une chance d'obtenir un fusil et d'en tirer beaucoup d'argent, ils ne s'en priveraient pas.

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.

Q : En tant que porte-parole de l'opposition aux brevets, est-ce que vous avez déjà rencontré…

R : J'ai du mal à vous entendre. S'il vous plaît, essayez de faire un effort pour prononcer chaque son distinctement, pour que je puisse comprendre.

Q : En tant que porte-parole de l'opposition aux brevets, est-ce que vous avez déjà eu des problèmes avec les multinationales ou autres ?

R : Est-ce que j'ai eu des problèmes…

R : Est-ce que j'ai eu des problèmes…

R : Je suis désolé. Qu'est-ce qu'il a dit ?

Q : Est-ce que vous avez déjà eu des problèmes avec les multinationales, dans votre vie ?

R : Eh bien, il y en a beaucoup. Dans la communauté où je développe du logiciel, il y a beaucoup d'exemples de programmes dont des fonctionnalités ont été retirées, de programmes dans lesquels, au départ, on n'a pas mis ces fonctionnalités, de programmes qui n'ont pas même été écrits pendant des années. Il y a beaucoup d'exemples de travaux que nous ne pouvons pas faire, parce que nous ne sommes pas autorisés à les faire.

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.

Q : Je pense qu'il demandait si une multinationale vous avait déjà menacé…

R : Eh bien, elles n'ont jamais menacé ma vie !

Q : Oui, c'était la question !

R : Non, mais elles menacent notre travail. Vous savez, elles menacent effectivement de nous poursuivre.

↑ Questions sur le logiciel libre

Un bénévole : Voici une question d'un monsieur dans le fond : « Si les sociétés multinationales qui produisent le matériel, comme Intel, négocient un contrat avec les grandes sociétés de logiciel pour freiner le logiciel libre en changeant les brevets des microprocesseurs, comment allez-vous surmonter un tel risque ? »

R : Je vois très peu de danger que cela arrive. Intel a récemment développé une nouvelle architecture d'ordinateurs. Loin d'essayer de nous empêcher de la gérer, ils ont recruté des gens pour la mettre en œuvre.

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.

Q : Le logiciel libre n'ayant pas de modèle économique concret, est-ce qu'il va aussi exploser comme les sociétés de la bulle internet ?

R : Je ne peux pas prédire l'avenir, mais je voudrais vous rappeler que les sociétés de la bulle internet étaient des entreprises. Et le logiciel libre n'est pas principalement une entreprise. Il existe quelques entreprises du logiciel libre. Est-ce qu'elles vont réussir ou finalement faire faillite ? Je ne sais pas. Ces entreprises contribuent à notre communauté, mais elles n'en constituent pas la raison d'être. La raison d'être de notre communauté, c'est la liberté de redistribuer, étudier et modifier le logiciel. Une grande quantité de logiciel libre est développée par des bénévoles et cette quantité est en augmentation. Quel que soit le sort des entreprises, cela ne disparaîtra pas.

Q : Je crois que des sociétés comme IBM investissent aussi des sommes considérables pour rendre leurs systèmes et leurs logiciels compatibles avec du code source libre comme Linux…

R : Vous voulez dire GNU ?

Q : D'accord…

R : Oui, ils l'appellent Linux. En fait, le système est essentiellement GNU et Linux est l'un de ses composants.

[De l'auditoire] Le noyau représente à peine dix-huit pour cent.

R : Ah bon, vraiment, tant que ça ? Je le voyais à trois pour cent.

[De l'auditoire] Vous pouvez voir à travers le chas d'une aiguille. Très peu significatif.

Q : Mais je crois aussi qu'ils ont investi pas loin d'un milliard de dollars pour le faire. Maintenant, ma question est…

R : Eh bien, ce n'est pas vrai.

Q : Ma question est : un service qui n'a pas de modèle économique sera-t-il viable sur la durée ? Si je change mon entreprise en…

R : Désolé, je ne peux pas prédire l'avenir. Personne ne le peut.

Q : Comment puis-je…

R : Certains hommes de Dieu prétendent qu'ils peuvent prédire l'avenir. Je n'en suis pas un. Je suis un rationaliste.

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 ?

Q : […]

R : Je ne peux pas du tout vous entendre, je suis désolé […] murmurer. Je suis un peu dur d'oreille, et quand on combine ça avec le bruit des ventilateurs et avec l'accent inhabituel, au final c'est très difficile pour moi de distinguer les mots.

Q : Cette question n'est pas à propos des brevets, des copyrights ou de ce genre de choses, mais c'est à propos de votre exemple sur la condition 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…

R : Non, je n'ai pas dit cela.

Q : Vous avez dit cela ! Vous avez dit qu'il n'y avait pas d'effet d'échauffement. Je m'en souviens…

R : Je suis désolé, je sais ce que j'ai dit. J'ai dit quelque chose qui ressemble un peu à cela…

Q : Je vais répéter la phrase exacte : vous avez dit qu'il n'y aura pas d'effet d'échauffement.

R : Pas d'effet de quoi ?

Q : D'échauffement. Pas de chaleur…

R : Oh oui, nous n'avons pas à nous préoccuper de la quantité de chaleur que la condition if…

Q : Oui, oui, exactement. Alors, qu'est-ce que c'est que cet effet de cascade ? Si je change la structure de la boucle, il y aura un effet.

R : Bien sûr. Le programme va se comporter différemment si vous le modifiez. Je ne dis pas qu'il est facile d'écrire chaque programme, ou que nous ne faisons jamais d'erreurs. J'ai fait la liste de pas mal de problèmes spécifiques qui sont une plaie pour les ingénieurs mécaniciens ou électriciens à chaque petit détail. Chacun de ces petits détails peut même devenir très compliqué pour eux. Par contre pour nous, les problèmes viennent de ce que nous travaillons tant, et si vite, que nous ne réfléchissons pas assez à chaque détail. C'est pourquoi nous faisons des erreurs.

Q : Donc vous admettez qu'il y a un effet.

R : Naturellement. Je n'ai jamais dit autre chose. Je suis désolé que vous l'ayez cru. C'est sûr que si vous modifiez un programme il va se comporter différemment.

Q : Monsieur, quelle est votre opinion sur les distributions commerciales ?

R : Vous m'avez demandé mon opinion sur la distribution commerciale de systèmes GNU/Linux ? Eh bien, je pense que c'est une bonne chose. C'est une des libertés que vous donne le logiciel libre – la liberté de l'utiliser dans l'entreprise, la liberté de le distribuer dans le cadre de l'entreprise, la liberté d'en vendre des copies pour de l'argent. Ces libertés sont toutes légitimes.

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.

Q : C'est le programme d'installation ?

R : Oui, n'importe quel logiciel non libre. Parce que l'objectif était que vous deviez pouvoir vous procurer un système d'exploitation complètement libre. Eh bien, s'il y a quelque chose dans un magasin qui dit « je suis le système GNU/Linux » – naturellement cela dit « Linux » – mais qu'à l'intérieur il y a des programmes non libres, vous n'avez plus quelque chose d'entièrement libre. Cela ne respecte pas complètement votre liberté. Donc le véritable objectif qui nous a fait écrire ce système est perdu de vue.

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 ?

Q : Non.

R : Ah bon. J'ai donné cette conférence à Trivandrum.

Alors je vais répondre à cinq questions supplémentaires et ce sera tout, parce que cela devient épuisant de répondre à tant de questions.

Q : Excusez-moi monsieur, je pose encore une question. Monsieur, c'est une question personnelle. Moi, en ce qui me concerne, j'adore programmer. Je passe beaucoup de temps devant mon système. Et j'ai suivi quelques-unes de vos précédentes conférences où vous avez dit que, dans les années 70, la bienveillance animait la communauté des programmeurs. Ils avaient l'habitude de partager du code, pour le développer.

R : Une communauté particulière de programmeurs à laquelle j'appartenais. Il ne s'agissait pas de tous les programmeurs. C'était une communauté particulière. Continuez.

Q : Oui monsieur. Dans ce contexte, je me sens particulièrement, en ce qui me concerne, je me sens très peiné quand je vois la soi-disant interaction parmi les programmeurs aujourd'hui. Parce que beaucoup d'entre nous sont de très bons programmeurs, mais nous nous regardons mutuellement à travers des filtres de différentes couleurs, selon les outils que nous utilisons – « tiens, voici un gars de Windows », « tiens, voilà un gars de GNU/Linux », « tiens, il est dans le système Solaris », « lui, il est dans la programmation réseau ». Et malheureusement cette discrimination vient pour une bonne part d'une mauvaise interprétation de choses comme celle-là. Aucune de ces personnes ne fait la promotion du logiciel libre en tant que tel et j'en suis peiné en tant que programmeur, ainsi que beaucoup de mes collègues, et je travaille dans un environnement…

R : Pourriez-vous parler un peu plus lentement. J'ai entendu presque tout ce que vous avez dit mais un détail m'a échappé, alors si vous parlez lentement, je…

Q : Oui. Ici nous travaillons dans un environnement où nous sommes jugés d'après les outils que nous utilisons, plutôt que d'après la qualité de notre travail.

R : Pour moi, ceci, eh bien en un sens, c'est une situation qui dans une certaine mesure est logique. S'il existe un outil qu'on utilise normalement pour faire les tâches assez faciles, devant être faites par un grand nombre de personnes, alors, j'imagine, je ne voudrais pas, je pourrais ne pas leur porter autant [d'attention] qu'à une personne qui fait des travaux très difficiles avec un outil différent, adapté à ces travaux difficiles. Mais c'est vrai, si vous parlez des travaux difficiles, cela n'a aucun sens de discriminer les gens selon les outils qu'ils utilisent. Les bons programmeurs peuvent se servir de n'importe quels outils.

Q : Ce n'est pas là-dessus que je mettais l'accent. Je mettais l'accent sur le fait que c'est une question de bienveillance. La bienveillance entre programmeurs semble fondre de nos jours dans les, vous savez, les petites cases de tel ou tel système, et cela me fait mal.

R : Je suis d'accord qu'on doit encourager les gens à apprendre plus de choses différentes et qu'il ne faut jamais avoir de préjugé contre les gens à cause de quelque détail, vous savez, le fait que telle personne préfère Perl, telle autre préfère le langage C ; pourquoi devraient-elles se détester…

Q : Ce n'est même pas si clair. C'est plutôt : telle personne travaille sous GNU/Linux et telle personne travaille sous Windows, qui sont les systèmes d'exploitation principaux aujourd'hui, du moins en Inde.

R : Eh bien, dans ce cas, alors ce n'est pas un préjugé, vous voyez. Windows est un système, un système social, qui maintient les gens dans un état d'impuissance et de division [applaudissements], tandis que GNU/Linux est une alternative qui a été créée spécifiquement pour libérer les gens et les encourager à coopérer. Donc dans une certaine mesure, ce n'est pas comme : « Est-ce que vous êtes né dans tel ou tel pays ? » Non, c'est comme un choix politique. Et il est raisonnable de critiquer les gens sur les choix qu'ils font, s'agissant de questions importantes.

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.

Q : Désolé de continuer là-dessus, Je suis un peu obstiné. Il est…

R : C'est votre dernière chance.

Q : Oui monsieur, merci. Généralement, quand des affirmations comme celles-ci sont faites, les gens qui ne sont pas si, vous savez, au courant de ces choses tendent à supposer que les communautés coopératives, le partage de code source, le partage d'idées et autres choses de ce genre n'existent pas dans les autres environnements. Mais si, ils existent, et c'est très dommage qu'ils pensent cela.

R : Je suis désolé. Quoi n'existe pas dans d'autres environnements ? Je ne sais pas de quels autres environnements vous parlez. Je ne comprends pas.

Q : Des autres environnements de programmation, des autres systèmes d'exploitation.

R : Eh bien, peut-être qu'il existe des utilisateurs qui développent du logiciel libre qui fonctionne sous Windows. En fait, je suis sûr qu'il y en a…

Note: A cet endroit, il y a eu une courte panne de courant. L'enregistrement et la transcription sont donc incomplets.

R : Peut-être là, y a-t-il d'autres questions ? Pourriez-vous parler plus fort ? Je ne vous entends pas du tout.

Q : Monsieur, puis-je vous poser une question ?

R : OK vous pouvez, bien sûr.

Q : Dans le système du logiciel libre, nous distribuons le code source avec le logiciel. Ainsi une personne a le droit de modifier ce qu'elle peut dans le code source. Ne pensez-vous pas qu'il y aura trop de versions d'un même logiciel et que le non-spécialiste aura du mal à déterminer laquelle lui convient le mieux ?

R : En pratique, ce n'est pas un problème. Cela arrive quelquefois, mais pas très souvent. La raison, voyez-vous, est que les utilisateurs veulent de l'interopérabilité et qu'avec le logiciel libre, ce sont les utilisateurs qui décident en dernier ressort. Ce qu'ils veulent, ils ont tendance à l'obtenir. Les développeurs de logiciel libre se rendent compte qu'ils feraient mieux… s'ils sont sur le point de faire des changements incompatibles, cela va probablement mécontenter les utilisateurs et leurs versions ne vont pas être utilisées. Alors, en général, ils tirent les conclusions évidentes et font très attention à l'interopérabilité.

Q : J'ai le sentiment que si j'installe un logiciel sur mon ordinateur, le lendemain matin je vais trouver une meilleure version et alors je devrai changer. Le surlendemain, le code source aura encore été modifié et ce sera une meilleure version. Donc est-ce que vous…

R : En général vous n'allez pas trouver une meilleure version chaque jour, parce que pour un programme donné il n'y a d'habitude qu'une version largement utilisée. Il y en aura peut-être deux, une fois de temps en temps il y en aura trois – s'il n'y a pas de bon mainteneur, cela peut se produire. Donc il ne vous arrivera pas de trouver chaque jour une nouvelle version qui soit bonne ; il n'y en a pas tant que ça. Il n'y aura pas tellement de versions populaires. Il y a un cas où vous pouvez avoir une nouvelle version tous les jours, c'est lorsqu'il y a une équipe très active qui fait un gros travail de développement. Alors, chaque jour vous pouvez vous procurer leur dernière version. Cela, vous pouvez le faire. Mais il n'y a qu'une version à un moment donné.

Q : Monsieur, ne pensez-vous pas que nous devrions mettre sur pied une organisation qui prendrait en compte toutes ces mises à jour et qui fournirait un ensemble logiciel unique avec toutes les mises à jour correctes ?

R : Je suis désolé, je n'ai pas entendu. Ne devrions-nous pas avoir une organisation qui ferait quelque chose avec toutes ces versions, mais je ne sais pas quoi.

Q : Par exemple, supposons que j'aie développé une version de…

R : Quelqu'un d'autre a-t-il entendu ce qu'elle a dit ? Quelqu'un d'autre pourrait-il me répéter ce qu'elle a dit ?

Q : La question est que…

R : C'est une compétence très appréciable que de savoir parler lentement et distinctement. Si jamais vous voulez parler en public, ce qui vous arrivera au cours de votre carrière, il vous sera très utile de savoir articuler distinctement et lentement.

Q : Merci monsieur. Monsieur, ne pensez-vous pas que nous avons besoin d'une organisation qui effectuerait simplement plusieurs mises à jours à la fois et rendrait disponible du logiciel qui cumulerait toutes les mises à jour jusqu'à une certaine date ?

R : Vous voulez dire, qui prendrait les différentes applications et les mettrait ensemble ?

Q : Oui monsieur.

R : Je vais vous dire. Il y a beaucoup d'organisations qui font cela ; en fait, chacune des distributions GNU/Linux fait exactement cela. Debian le fait, Red Hat le fait… Nous le faisons dans une certaine mesure avec les paquets GNU. Nous faisons en sorte qu'ils fonctionnent ensemble.

Q : Excusez-moi monsieur, nous avons beaucoup parlé contre les brevets. Est-ce qu'aux États-Unis vous avez jamais été forcé de déposer une demande de brevet ?

R : Non. Mais personne ne peut me forcer à faire une demande de brevet.

Q : Aussi, est-ce que vous possédez des brevets ?

R : Je ne possède aucun brevet. Cela dit, j'ai envisagé la possibilité de demander des brevets dans le cadre d'une alliance de défense mutuelle stratégique.

Q : Vous voulez dire que si j'ai vingt brevets, je peux en faire don à la FSF qui les maintiendra pour moi ?

R : Eh bien, pas à la FSF. Ce serait une organisation séparée, spécialisée, qui aurait été créée spécialement pour que nous puissions tous faire don de nos brevets, et que l'organisation utilise tous ces brevets pour protéger quiconque souhaite être protégé. Ainsi n'importe qui pourrait rejoindre l'organisation, même s'il ne possède pas de brevet, et cette personne serait protégée par l'organisation. Mais alors nous essaierions tous d'obtenir des brevets pour renforcer l'organisation, de manière qu'elle puisse mieux nous protéger. Voilà l'idée, mais personne n'a réussi jusqu'à présent à mettre ce projet en route. Ce n'est pas facile, l'une des raisons étant que cela coûte très cher de demander un brevet – et c'est aussi beaucoup de travail.

Ce sera la dernière question.

Q : Pourquoi la Fondation pour le logiciel libre ne se met-elle pas à faire sa propre distribution ?

R : Eh bien, la raison, c'est que Debian répond presque à nos désirs. Il semble préférable d'être amis avec Debian et d'essayer de les convaincre de la changer un peu, plutôt que de leur dire : « Nous n'allons pas l'utiliser, nous allons faire la nôtre. » Et aussi, Debian semble avoir une meilleure chance de succès parce qu'après tout il y a déjà beaucoup de gens qui travaillent dessus. Pourquoi essayer de créer une alternative à cette grande communauté ? Il est bien préférable de travailler avec eux et de les convaincre de soutenir encore mieux nos objectifs… si cela marche, évidemment. Et nous avons nos moyens d'y arriver.

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]

Note

[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.