conférence de Richard M. Stallman
au Model Engineering College du Gouvernement de Kerala, Inde
Le Professeur Jyothi John, responsable du département d'informatique, présente Stallman :
C'est pour moi un privilège et un devoir que d'introduire 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, avec pour 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 FSF (Free Software Foundation - Fondation pour le logiciel libre).
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 GPL (GNU General Public License - 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. 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 (Association pour le développement des outils informatiques) en 1991. En 1990, une bourse de la fondation MacArthur lui a été attribuée - 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. En 1999 il a reçu 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 d'autres sociétés.
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, est un peu éloignée de la question du logiciel libre : les brevets logiciels sont un danger pour tous les programmeurs et pour tous les utilisateurs d'ordinateurs. 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 à travers le monde.
« Propriété intellectuelle » est une expression erronée
Il y a une expression très malencontreuse que vous avez probablement déjà entendue. C'est l'expression « propriété intellectuelle ». D'abord il y a 2 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, ou de travaux. Elle ne fait pas le détail, elle suppose que toutes seront traitées comme une propriété quelconque. Pourtant, c'est une décision de politique publique et l'on devrait pouvoir examiner les différentes alternatives pour choisir la meilleure. Ce qui veut dire qu'on ne devrait pas désigner l'ensemble du 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 désigne en réalité un catalogue de lois relatives à des domaines totalement différents les uns des autres comme les copyrights, les brevets, les marques déposées, les secrets de fabrication et autres. Pourtant, les lois de ces différents domaines n'ont en réalité presque rien en commun. Ce qu'elles disent change totalement quand on passe de l'une à l'autre. Leurs origines sont complètement indépendantes et les questions de politique publique qu'elles soulèvent sont complètement différentes. Aussi, la seule manière intelligente d'y réfléchir est d'en choisir une, puis d'y réfléchir ; d'y réfléchir séparément.
Ainsi la manière intelligente d'en parler est de ne jamais généraliser, mais au contraire de parler d'une loi spécifique. Vous comprenez ? Parler des copyrights, ou bien parler des brevets, ou bien parler des marques déposées, mais ne jamais les rassembler 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.
Copyright et brevet sont deux notions différentes
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 l'un avec l'autre. Permettez-moi de vous citer quelques-unes des différences fondamentales entre les copyrights et les brevets :
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 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 fonctionne le système des brevets
La plupart du temps, les personnes qui décrivent comment fonctionne le système des brevets ont un intérêt personnel dans le système. Et ainsi ils le décrivent du point de vue de quelqu'un qui veut obtenir un brevet, pour ensuite le présenter aux programmeurs en leur disant « passez-moi votre argent ». C'est naturel, vous savez. Ceux qui vendent des billets de loterie parlent 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 pensiez à eux, aussi ils parlent des gens qui gagnent. C'est la même chose avec les brevets.
Le système des brevets est une loterie coûteuse pour les participants. Mais naturellement, les personnes qui gèrent le système veulent que vous pensiez à la petite chance que vous avez de gagner. Aussi, pour rétablir la balance, je vais vous expliquer à quoi ressemble ce système du point de vue d'une personne qui pourrait être victime d'un brevet. C'est-à-dire d'une personne qui veut développer du logiciel. Donc je suppose que vous êtes dans un pays qui a des brevets logiciels. Comment allez-vous faire face au système des brevets ?
Eh bien, la première chose que vous devez chercher à savoir, c'est comment les brevets pourraient éventuellement affecter votre champ d'activité. C'est une tâche impossible, car les projets en cours d'examen par l'office des brevets sont secrets. 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 être poursuivis. 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 au bout de quelques années, Unisys a commencé à soutirer de l'argent à diverses sociétés.
Comme le projet GNU avait besoin d'un algorithme de compression, et que nous ne pouvions plus utiliser Compress, nous avons commencé à chercher un autre programme de compression. Il s'est trouvé que quelqu'un s'est présenté et nous 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 ne m'arrive pas très souvent). Il se trouve qu'il contenait la rubrique hebdomadaire des brevets, que je l'ai remarquée, et que je l'ai lue. Elle disait que quelqu'un avait obtenu un brevet pour l'invention d'une nouvelle méthode, une meilleure méthode de compression. (Bon, ce n'était pas vraiment le cas.)
Quand j'ai vu cela, j'ai pensé que nous ferions mieux de nous procurer une copie du brevet et de voir si c'était un 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 détenteur du brevet) avait inventée n'était pas meilleure, parce qu'elle n'était pas nouvelle. Mais cela n'a pas d'importance, il en avait le monopole.
Puis finalement nous avons trouvé un autre algorithme de compression qui est utilisé dans le programme connu sous le nom de GISA. Mais ceci illustre le danger auquel vous êtes confrontés : même si vous aviez des moyens illimitées, vous ne pourriez pas vous renseigner sur tous les brevets susceptibles de mettre en danger votre projet. Mais vous pouvez vous renseigner sur les brevets déjà accordés parce qu'ils sont publiés par l'office des brevets. En principe vous pourriez tous les lire, et voir lesquelles restreignent votre activité. 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. C'est juste une estimation. Je sais qu'il y a dix ans ils en accordaient dix mille par an, et je suppose que le rythme s'est accéléré depuis. C'est trop pour que vous puissiez vous tenir au courant, à moins que ce soit votre travail à plein temps. Vous pouvez cependant rechercher ceux qui ont rapport avec ce que vous faites ; cela marche quelquefois. Si vous faites des recherches par 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 aux États-Unis - peut-être le brevet a-t-il expiré depuis - sur le « recalcul en ordre naturel » (natural order recalculation) dans les tableurs. Maintenant, qu'est-ce que ça veut dire ? Cela signifie que les tableurs, à l'origine, calculaient toujours les cellules de haut en bas. Ce qui veut dire que si une cellule dépendait d'une autre cellule placée plus bas, elle n'était pas calculée en une fois. Vous deviez recalculer toute la feuille pour l'obtenir. C'est clair qu'il vaut mieux calculer dans le bon sens, voyez-vous. Si A dépend de B, alors calculez B d'abord, puis calculez A. De cette façon, un seul calcul rendra tout cohérent.
Eh bien, c'est ce que ce brevet couvrait. Si vous aviez fait une recherche sur le mot « tableur », vous n'auriez pas trouvé ce brevet parce que le mot n'y figurait pas. La phrase « recalcul en ordre naturel » n'y figurait pas non plus. C'est l'algorithme que le brevet couvrait, c'est-à-dire essentiellement 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 ne l'aurait pas trouvé. De ce fait, vous auriez pu être poursuivi.
En réalité vous ne pouvez pas savoir, même approximativement, ce qui est couvert par un brevet, à moins de l'étudier soigneusement. C'est différent pour les brevets relatifs à d'autres domaines, parce que dans les autres domaines quelque chose de physique se produit, et les détails de cette chose physique vous donnent habituellement un point de départ (anger > handle) 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 rendre compte. 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 1984 et le second, je pense, en 1989, mais celui-là avait été demandé encore plus tôt. Un de ces brevets appartient à Unisys et l'autre à IBM.
En fait, ce type d'erreur n'est pas si rare. Celle dont je vous ai parlée n'est pas unique. Voyez-vous, les personnes qui examinent les demandes n'ont pas beaucoup de temps à consacrer à chaque brevet ; aux États-Unis, ils ont en moyenne 17 heures. Ce n'est pas suffisant pour étudier en détail tous les autres brevets du même domaine d'activité, pour savoir si vraiment il n'y en aurait pas un qui décrit la même chose. C'est pourquoi ils répéteront cette sorte d'erreur indéfiniment. Au final, vous ne trouverez pas tous les brevets qui pourraient vous menacer, mais vous pourriez tout de même en trouver quelques-uns.
Il faut demander conseil à un avocat
Maintenant qu'est-ce que vous faites ? Vous devez essayer de découvrir précisément ce que ces brevets interdisent. C'est très difficile parce qu'ils sont écrits dans un langage juridique tortueux qui est très difficile à comprendre pour des ingénieurs. Il va vous falloir y travailler avec un avocat.
Dans les années 80, le gouvernement australien a commandé une étude sur le système des brevets ; le système des 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 pas mal d'ennuis. La seule raison pour laquelle les auteurs ne recommandaient pas de le faire était la pression internationale. Parmi les motifs de leur conclusion, il y avait le fait que les brevets, pourtant censés divulguer l'information pour qu'elle ne reste pas secrète, n'atteignaient pas leur but. Les ingénieurs ne regardaient jamais les brevets pour essayer d'apprendre quoi que ce soit parce qu'ils sont trop difficiles à lire. Le rapport citait par exemple un ingénieur qui disait « je n'arrive pas reconnaître mes propres inventions dans les brevets ».
Il y a quelques années aux États-Unis, un ingénieur nommé Paul Heckel a poursuivi Apple. Il avait pris deux brevets logiciels à la fin des années 80 pour un ensemble de logiciels. Puis quand il a vu sortir le brevet d'Hypercard, il l'a regardé de près et a dit « cela ne ressemble pas à mon programme ». Il n'y a plus pensé, mais plus tard son avocat lui a expliqué qu'en lisant ce brevet avec attention, on constatait qu'Hypercard tombait dans le domaine interdit par ses propre brevets. Donc il a poursuivi Apple, pensant que ce serait peut-être l'occasion de gagner un peu d'argent. Eh bien, alors que je donnais une conférence comme celle-ci, il était dans l'auditoire 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 dire quelles techniques brevetées ils emploient. Cela va coûter cher. Et quand vous aurez fini, l'avocat vous dira : « 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 être en sécurité vous feriez mieux d'en rester à l'écart . Et naturellement il y a un facteur chance considérable dans toute procédure. »
Trois stratégies possibles face aux brevets
Maintenant que vous avez un terrain prévisible pour mener vos affaires, qu'est-ce que vous allez faire ? Vous devez envisager trois possibilités :
Contourner les brevets qui vous menacent
D'abord voyons comment contourner le brevet. Eh bien, dans certains cas, c'est facile, mais pas toujours. Vous vous rappelez qu'Unisys effrayait avec son brevet tous les gens qui se servaient de la compression LZW, les obligeant à trouver un autre algorithme de compression pour contourner le brevet. Eh bien cela n'a pas été très facile parce qu'il y avait beaucoup d'autres brevets couvrant beaucoup d'autres algorithmes de compression de données. Mais finalement nous en avons trouvé un qui n'était pas couvert par ces autres brevets. 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, et beaucoup de gens se servent de GZIP. Ainsi, dans ce cas précis, cela a demandé beaucoup de travail mais nous avons pu contourner ce brevet-là.
Entre-temps, dans les années 80, Compuserv avait défini un format d'image appelé GIF qui utilisait l'algorithme de compression LZW. Naturellement, lorsque le tumulte fait autour de ce brevet a été connu, des gens ont défini un autre format d'image qui se sert d'un algorithme de compression différent, l'algorithme GZIP. Ce format est appelé PNG, ce qui veut dire « PNG N'est pas GIF »(PNG is Not 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 des images au format GIF, mais ils ne pouvaient pas afficher le format PNG. Le résultat, c'est que les gens trouvaient trop difficile de changer. Imaginez la situation. Il y a un programme de compression de données et quelqu'un qui dit « je veux comprimer des données », mais cette personne peut être poursuivie si elle utilise ce programme. Si vous lui en proposez un autre, elle changera, vous pensez ?
Ce que la personne voulait en fait, c'est créer des images que Netscape pourrait afficher. Elle ne pouvait donc changer de format que si Netscape reconnaissait le nouveau format. Ce n'était pas le cas. Il s'est passé des années, je crois, avant que Netscape commence à reconnaître le format PNG. Pour l'essentiel, les gens disaient « je ne peux pas changer, je ne l'ai simplement pas fait ». Au final, une société avait énormément investi dans ce seul format, mais l'inertie était trop grande pour que les gens changent, alors même que ce nouveau format était bien supérieur à l'ancien.
Quand un brevet couvre un domaine étroit, le contourner peut être très difficile. Par exemple, les spécifications de Postscript incluent la compression LZW que nous ne pouvons pas utiliser dans notre mise en œuvre de Postscript. Nous avons employé une autre sorte de compression, d'une manière peu orthodoxe bien qu'elle donne un résultat utilisable. Donc un brevet peut être contourné, même s'il couvre un domaine étroit.
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 en ont reçu par courriel un avis de « dégradation ». Avec ce logiciel, on pouvait définir un mot court, une suite de lettres, comme abréviation. Quand on tapait cette suite de lettres, puis un espace, on obtenait le mot complet. On pouvait définir cette abréviation en cours d'écriture. 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 que ce brevet ne soit pris. Ainsi il y avait une chance que je puisse leur donner des arguments qui les auraient aidés à combattre le brevet.
Bon. Au moins, cela m'a montré que j'avais eu au minimum une idée brevetable dans ma vie. Je le sais parce que quelqu'un d'autre a pris le brevet. Naturellement, vous pouvez vous défendre contre ces brevets en enlevant des fonctionnalités. Mais quand votre programme aura perdu plusieurs des fonctions que les utilisateurs recherchent, il pourrait ne plus être d'aucune utilité.
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 lui manque une fonctionnalité importante, le système Pantone de correspondance des couleurs, qui est important lorsqu'on veut imprimer des images sur papier avec des résultats reproductibles. Cette fonctionnalité a été omise parce qu'elle est brevetée. Et par conséquent le programme est déficient pour tout une classe d'utilisateurs. Si vous regardez les programmes actuels, vous voyez que souvent ils ont de nombreuses fonctionnalités, et c'est ce que demandent les utilisateurs. Si l'une des fonctions importantes manque, on peut s'en passer facilement, 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. Par exemple le chiffrement par clés publiques est essentiel pour préserver la vie privée des usagers de l'informatique. L'ensemble du domaine était breveté. le brevet a expiré il y a juste quatre ans, de sorte qu'aux États-Unis, on peut maintenant rêver de logiciels libres de chiffrement par clés publiques. Jusque là, plusieurs programmes libres et non-libres avaient été éliminés par l'office des brevets. Et de fait ce domaine entier de l'informatique a été retardé pendant plus de dix ans malgré le grand l'intérêt qu'il suscite.
Voilà donc les possibilités de contourner les brevets.Obtenir des licences d'exploitation
Autre solution quelquefois disponible : obtenir une licence d'exploitation du brevet. Mais le détenteur du brevet n'est pas obligé de vous offrir une licence ; elle lui appartient. Le détenteur du brevet peut dire « je ne propose pas de licence pour ceci, faites donc faillite ; point final ».
À la League for Programming Freedom (Ligue pour la liberté de programmer), nous avons entendu parler au début des années 90 d'une personne dont l'entreprise familiale fabriquait des jeux de casino, numériques naturellement. Cette personne avait été menacée par quelqu'un qui avait un brevet sur une catégorie très large de jeux numériques de casino. Le brevet couvrait un réseau dans lequel il y a plus d'une machine, chaque machine permettant de jouer à plusieurs types de jeux et d'en afficher simultanément le déroulement. Maintenant, il y a une chose dont vous devez vous rendre compte : l'office des brevets pense que c'est vraiment une idée géniale. 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, si quelqu'un a construit un système qui permet de jouer à un jeu, et que vous rendez ce système capable de jouer à plusieurs jeux - c'est une invention. Si vous pouvez afficher un jeu et que vous décidez de régler l'affichage pour afficher plusieurs jeux en même temps, c'est une invention.
Si cette personne le fait avec un ordinateur, et que vous le faites avec un réseau d'ordinateurs portables, ils considèrent cela comme une invention. Ils pensent que ces étapes sont vraiment géniales. Évidemment, 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 des brevets produit, pour les opposer ensuite aux programmeurs, des brevets dont nous dirions tous qu'ils sont ridiculement évidents. Vous pensez peut-être que s'ils sont si ridiculement évidents, ces brevets ne tiendront pas devant un tribunal. Pourtant, ils peuvent être légalement valables bien qu'ils soient stupides. Ainsi, la personne qui fabriquait des jeux de casino s'est trouvée face à ce brevet, et son détenteur ne lui a même pas laissé une chance d'obtenir une licence. « Ferme boutique ! » C'est ce que le détenteur du brevet a dit, et c'est ce qu'elle a fait en fin de compte. Elle n'avait pas les moyens de combattre le brevet.
Cependant, beaucoup de détenteurs de brevets vous laisseront une chance d'obtenir une licence ; mais cela vous coûtera cher. Les propriétaires du brevet sur le recalcul en ordre naturel demandaient cinq pour cent des ventes brutes de chaque tableur, et l'on m'a dit que c'était le tarif minimum d'avant le procès. Si l'on insistait pour engager une procédure, 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. Et si votre programme utilise, disons, vingt brevets, et que chaque détenteur de brevet demande cinq pour cent des ventes brutes... (et quand je dis vingt brevets...) L'un d'eux conteste ; alors vous êtes vraiment dans la mouise.
Mais en pratique, les entrepreneurs disent qu'avec deux ou trois de ces brevets, la charge serait si lourde qu'une société ferait faillite, même si théoriquement elle aurait pu s'en tirer. Donc, obtenir une licence pour exploiter un brevet n'est pas nécessairement une chose faisable, et pour nous, développeurs de logiciels libres, c'est encore pire parce que nous ne pouvons même pas compter le nombre de copies distribuées. Comme la plupart des licences ont des clauses sur le nombre de copies, cela nous est absolument impossible d'utiliser une de ces licences. Savez-vous que si une licence était facturée ne serait-ce qu'un millionième de roupie par utilisateur, cela nous serait impossible de nous conformer au contrat parce que nous ne pouvons pas compter les copies ? Peut-être que j'ai assez d'argent dans ma poche pour payer, 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 de temps en temps.
Les licences croisées
Pourtant il existe une catégorie d'organisations pour lesquelles la concession de licences marche très bien, ce sont les grandes multinationales. En effet elles possèdent elles-mêmes de nombreux brevets qui leur servent à négocier des licences croisées. Qu'est ce que cela veut dire ? Eh bien, comme la dissuasion est pour ainsi dire la seule défense contre les brevets, vous devez posséder des brevets à vous. Ensuite vous attendez que quelqu'un vous vise avec un de ses brevets, alors vous pouvez le viser avec un des vôtres en lui disant « ne me fais pas de procès, parce qu'alors c'est moi qui t'en fais un ».
Cependant, la dissuasion ne marche pas aussi bien avec les brevets qu'avec les armes nucléaires. La raison en est 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 essaient d'obtenir des brevets pour se défendre, pour augmenter leurs chances de succès. Peut-être qu'elles en obtiendront quelques-uns, un qui pointe de ce côté-ci, un de ce côté-là. Et alors si la menace vient de par là-bas, que va faire cette société ? Ses brevets pointent ailleurs, 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 voudrais, pourquoi ne pas lui soutirer un peu d'argent ? » Donc ils commencent par prendre des brevets défensifs, mais souvent ils changent d'avis par la suite quand une victime passe à leur portée (wants to buy > wanders by). Ceci, incidemment, montre à quel point est fallacieux le mythe que le système des brevets « protège » le « petit inventeur ».
Permettez-moi de tirer pour vous la leçon du mythe du génie affamé. Prenez quelqu'un qui a travaillé dans son coin 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 que de grandes sociétés comme IBM entrent en compétition avec lui. Il prend donc un brevet qui va le « protéger ». Naturellement, ce n'est pas comme cela que ça se passe dans notre domaine. On ne fait pas ce genre d'innovation dans l'isolement. On la fait en travaillant avec d'autres, en discutant avec d'autres, afin de développer un logiciel la plupart du temps. 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 passé, et qu'il ait obtenu son brevet. Il dit à IBM : « IBM, tu ne peux pas entrer en compétition avec moi parce que j'ai obtenu ce brevet ». Mais voici ce qu'IBM lui répond : « Bien. Regardons ton produit. Hum, je possède ce brevet-ci, ce brevet-là, et encore celui-là, et encore trois autres que ton produit est en train de violer. Pourquoi pas une licence croisée, vite fait ? » Et le génie affamé dit « hum, je n'ai pas assez de nourriture dans l'estomac pour combattre ces choses-là, je ferais mieux de céder ». Et donc ils signent un accord de licence croisée. Maintenant, devinez ce qui arrive.
IBM peut parfaitement entrer en compétition avec lui… Il n'est pas du tout protégé. IBM peut faire cela parce qu'il a beaucoup de brevets. Ils ont des brevets pointant par ici, par là, par là… dans toutes les directions. De sorte que n'importe quelle attaque, d'où qu'elle vienne ou presque, sera repoussée. Une petite société ne peut pas faire cela, mais une grande peut le faire.
Une fois, IBM a fait paraître un article. C'était dans le magazine Think - c'est le magazine interne d'IBM - numéro cinq de 1990 je crois, un article sur le portefeuille de brevets d'IBM. L'article disait qu'ils avaient deux manières de tirer profit de leurs 9000 brevets valides. 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 sans craindre d'être attaqués, au moyen de licences croisées. Et l'article disait que la seconde sorte de profit était supérieure à la première d'un ordre de grandeur.
En d'autres termes, l'avantage que tire IBM du fait de travailler librement, sans être poursuivi, est dix fois supérieur à l'argent qu'ils gagnent avec tous leurs brevets. Malgré tout, le système des brevets ressemble beaucoup à une loterie. On ne sait pas a priori ce qui va advenir d'un brevet particulier, et la plupart ne rapportent rien à leur propriétaire. Mais dans un portefeuille de la taille de celui d'IBM, les choses s'équilibrent en moyenne. Donc on peut dire que ce qui se passe chez IBM donne une bonne idée de la moyenne. Ce qu'on voit, c'est que, de manière un peu surprenante, l'avantage que tire IBM de pouvoir utiliser les idées brevetées par d'autres contrebalance le mal que le système des brevets aurait fait à IBM s'il n'y avait pas de licences croisées - s'il était vraiment interdit à IBM d'utiliser toutes ces idées brevetées par d'autres.
Ainsi, je vous ai dit que les dommages causés par le système des brevets seraient en moyenne dix fois supérieurs à ce qu'ils rapportent. Pour ce qui est d'IBM, ces dommages n'existent pas, parce qu'ils ont 9000 brevets et ainsi peuvent forcer les gens à négocier des licences d'exploitation et des licences croisées. Mais si vous êtes petits, vous ne pouvez pas éviter le problème de cette façon et vous serez vraiment confrontés à dix fois plus d'ennuis que de profits. En tout cas, les licences croisées sont la raison pour laquelle les grosses multinationales sont en faveur des brevets logiciels et disent des choses naïves comme « c'est une nouvelle sorte de monopole pour les développeurs de logiciels, 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. C'est ce que j'essaie de vous expliquer.
Contester la validité d'un brevet
Donc nous venons de voir quelles sont les possibilités d'acquérir une licence. La troisième option possible est d'aller au tribunal pour contester la validité du brevet. Le résultat de cette démarche va dépendre pour une large part de facteurs techniques, c'est-à-dire essentiellement du facteur chance.
Vous voyez, les dés ont été jetés il y a plusieurs années. Vous pouvez faire une recherche sur l'historique de l'invention, et découvrir ce que les dés ont décidé. Vous trouverez peut-être que vous avez une chance. Ainsi c'est essentiellement un accident historique qui détermine si un brevet est valable ; à savoir, quelles inventions précisément se trouvent avoir été publiées, et quand. Quelquefois il y a une possibilité de faire invalider un brevet. Mais même si le brevet est ridiculement trivial, ce n'est pas garanti. On a parfois une bonne chance de le faire invalider, parfois non.
On ne peut pas compter sur les tribunaux pour reconnaître que c'est trivial, parce que leurs standards sont généralement bien inférieurs à ce que nous considérons 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 invalidés par la Cour suprême depuis le 19e siècle. Et ils étaient totalement ridicules, comme de faire des formes en caoutchouc pour le moulage des poignées de porte, alors que jusque là on les faisait en bois. Cette décision retoquait le système des brevets pour avoir dérivé loin, très loin de ses propres standards. Et ils continuent.
Ainsi vous ne pouvez pas vous attendre à des résultats sensés. Cependant dans certains cas, 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 très cher.
Il y a quelques années, le perdant d'un procès a dû payer 13 millions de dollars qui, en majorité, allèrent aux avocats des deux parties. Je pense que le détenteur du brevet a remporté 5 millions de dollars seulement, les 8 millions restant allant aux avocats.
On ne peut pas tout réinventer
Voilà donc les options possibles. À ce stade, naturellement, vous devez commencer à écrire votre programme. Le problème, c'est que vous n'êtes pas confrontés à cette situation une seule fois, mais qu'elle se répète, encore et encore, parce que les programmes d'aujourd'hui sont compliqués. Regardez un logiciel de traitement de texte ; vous y verrez une multitude de fonctionnalités, beaucoup de choses différentes dont chacune peut avoir été brevetée par quelqu'un, ou dont chaque combinaison de deux d'entre elles peut avoir été brevetée. British Telecom a un brevet aux États-Unis sur la combinaison de liens hypertextes avec la composition d'un numéro téléphonique. Ce sont deux choses bien séparées, mais la combinaison des deux est brevetée.
Cela veut dire que si vous avez 100 éléments dans votre programme, il y a potentiellement 5000 paires de ces éléments qui pourraient déjà être brevetées par quelqu'un. Et il n'y a pas de loi interdisant de breveter des combinaisons de trois éléments. Et encore, il ne s'agit que des fonctionnalités, vous savez. Vous allez vous servir de beaucoup de techniques en écrivant les programmes, 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 développer un programme devient comme traverser un champ de mines. Bien sûr, vous n'allez pas marcher sur un brevet à chaque pas, il y a des chances que ce soit sans danger. Mais traverser tout le champ devient dangereux.
La meilleure manière d'expliquer la situation à un non-programmeur est de comparer l'écriture de ces grands programmes à un autre domaine dans lequel les gens écrivent - celui des très grandes symphonies. Imaginez que les gouvernements européens du 18e 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 vous auriez pu breveter, disons, un motif mélodique de trois notes, trop court pour être une vraie mélodie mais néanmoins brevetable, ou bien une certaine progression d'accords, ou encore une certaine combinaison d'instruments jouant en même temps. En somme, n'importe quelle idée musicale pouvant être décrite.
Eh bien, vers l'année 1800 il y aurait eu des milliers de ces brevets sur les idées musicales. Maintenant imaginez que vous êtes Beethoven et que vous voulez écrire une symphonie. Pour écrire une symphonie complète, vous allez devoir utiliser un tas de choses différentes, et à chaque é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, cette personne dira : « Oh, vous êtes un voleur, pourquoi n'écrivez-vous pas quelque chose d'original ? » Beethoven avait plus que sa part d'idées originales, mais il a utilisé beaucoup d'idées musicales existantes. C'est ce qu'il devait faire, car c'était le seul moyen de faire connaître sa musique. Si vous ne faites pas ça, les gens n'écouteront pas. Pierre Boulez voulait réinventer complètement le langage musical. Il a essayé, mais personne n'a écouté car ce langage ne leur était pas familier. 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 apprendre quoi que ce soit d'une autre personne. En pratique, ces personnes sont les détenteurs de brevets. Ils nous accusent de tricher parce que nous ne réinventons pas le domaine complètement à partir de rien. Pour progresser, il nous faut construire en nous basant sur les travaux précédents et c'est exactement ce que le système des brevets nous interdit de faire. Nous devons fournir aux utilisateurs les fonctionnalités dont ils ont l'habitude et qu'ils peuvent reconnaître, autrement ils trouveront que nos logiciels sont trop difficiles à utiliser, quelles que soient leurs qualités.
L'invention logicielle n'a pas les contraintes physiques de l'invention matérielle
Les gens me demandent quelquefois pourquoi le logiciel est différent des autres domaines d'activité. Parfois, ils le demandent de manière assez méchante. Ils disent : « Si les autres domaines peuvent s'arranger des brevets, pourquoi le logiciel serait-il une exception ? » C'est une manière méchante de poser la question car elle suppose que c'est mal d'essayer d'échapper à un problème. J'imagine que je pourrais dire : « Puisque d'autres personnes ont un cancer, pourquoi pas vous ? » Il est évident que, si c'est un problème, permettre à un domaine d'y échapper est une bonne chose, quel que soit ce domaine. Mais il y a une bonne question, une question grave : « Est-ce que ces autre domaines sont dans la même situation que le logiciel ? » Est-ce que les brevets affectent tous ces domaines de la même façon ? Si une politique est bonne pour le logiciel, est-elle 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 il vaut la peine de s'y intéresser. Si on le fait, on se rend compte que la relation entre les brevets et les produits dépend du domaine considéré.
À une extrémité, il y a les médicaments où un brevet couvre une formule complète. Donc, si vous sortez un nouveau médicament, il ne peut pas être breveté par quelqu'un d'autre. À l'autre extrémité, il y a le logiciel où lorsque vous écrivez un nouveau programme vous combinez des douzaines ou des centaines d'idées, qui ne peuvent pas toutes être nouvelles. Même dans un programme innovant qui comporte quelques idées nouvelles, il y a aussi des tas et des tas de vieilles idées. Entre les deux on trouve les autres domaines. Même dans ces autres domaines, 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. La raison en était que les avions modernes utilisaient plusieurs techniques différentes qui étaient brevetées par différentes sociétés dont les propriétaires se haïssaient. Ainsi personne ne pouvait obtenir de licence pour utiliser tous ces brevets. Eh bien, le gouvernement a décidé que cet état de choses était inacceptable et, pour l'essentiel, a payé une somme forfaitaire aux détenteurs des brevets ; puis il a dit « nous avons nationalisé ces brevets, et maintenant tout le monde peut construire des avions pour nous ». Mais l'importance des impasses de ce genre, leur fréquence et leur gravité, dépendent du nombre d'idées utilisées dans la fabrication d'un produit. Et de ce point de vue, le logiciel est un cas extrême.
Il n'est pas rare de voir quelques personnes écrire en deux ans un programme contenant des millions de parties différentes, chaque partie ayant, peut-être, 300 000 lignes de code. Concevoir un système physique qui contient des millions de parties différentes est un projet énorme, c'est très rare. Cela dit, on trouve de nombreux objets physiques qui ont des millions de pièces, mais typiquement ce sont plusieurs copies de la même sous-unité, et la conception en est beaucoup plus facile - on n'a pas besoin de concevoir des millions de pièces. Maintenant, pourquoi est-ce comme cela ?
La raison de cet état de choses, c'est que les autres domaines doivent tenir compte des tendances naturelles de la matière. Quand on conçoit des circuits, des voitures ou des produits chimiques, on doit prendre en compte le fait que les 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, ils ont beaucoup de problèmes que nous n'avons pas. Par exemple, si nous mettons une boucle if à l'intérieur d'une boucle while, nous n'avons pas besoin de nous demander si la boucle if va recevoir assez d'énergie pour tourner à la vitesse voulue. Nous n'avons pas à craindre qu'elle tourne à une vitesse pouvant générer à l'intérieur 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 que la vitesse de cette boucle la fasse entrer en résonance, et que finalement la boucle 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 la boucle if et la boucle while, causant de la corrosion, puis un mauvais contact.
Nous n'avons pas à craindre que d'autres produits chimiques les contaminent et produisent des court-circuits. Nous n'avons pas à nous demander si la chaleur dégagée par la boucle if peut se dissiper à travers la boucle while qui l'entoure. Nous n'avons pas à nous demander si la boucle while pourrait causer une chute de tension telle que la boucle 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 capacitance d'une certaine variable et combien de temps il faudra pour l'amener à sa valeur.
Toutes ces choses sont définies d'une certaine façon, 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 ne pas fonctionner mais ce n'est pas la faute des programmes. Aussi, du fait que nous n'avons pas à traiter tous ces problèmes, notre domaine 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 un domaine en principe plus facile vont le pousser plus loin. Nous construirons des choses de plus en plus grandes, et finalement cela redeviendra difficile.
Voilà pourquoi nous pouvons développer des systèmes beaucoup plus grands que les gens travaillant dans d'autres domaines. C'est seulement qu'ils ont en permanence ces problèmes difficiles à traiter.
Dans les autres domaines, il peut être nécessaire de « développer » une idée : on a une idée, mais ensuite on doit l'essayer de nombreuses manières différentes pour qu'elle commence à fonctionner. Dans le logiciel, on a une idée, on écrit un programme qui met en œuvre cette idée, et ensuite les utilisateurs peuvent l'apprécier ou non. Et si les utilisateurs ne l'apprécient pas, on peut probablement améliorer 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 la boucle if dans la boucle while, nous n'avons pas à nous demander comment la boucle if va être insérée dans la boucle while lorsqu'une copie sera fabriquée. Nous n'avons pas à nous préoccuper non plus de rendre la boucle if facile d'accès, pour le cas où elle grillerait et qu'on devrait la remplacer. Tout ce que nous avons à faire, c'est de faire la copie dans une machine multi-usages pouvant copier n'importe quoi. Les gens qui fabriquent des produits physiques ne peuvent pas faire ça, ils sont obligés de fabriquer la copie pièce par pièce. Pour eux, au final, la conception d'un système d'une certaine complexité a un coût élevé, et l'installation de l'usine également. En comparaison, les frais additionnels entraînés par le système des brevets sont minimes. Ils peuvent s'en accommoder. Pour nous, le coût de conception est très faible, et le coût de fabrication encore plus faible. En comparaison, les frais additionnels entraînés par le système des brevets sont écrasants.
Voici une autre façon de voir les choses : puisque nous pouvons (quelques-uns d'entre nous le peuvent) créer des systèmes beaucoup plus grands que dans les autres domaines, il y a beaucoup plus de points de vulnérabilité, où quelqu'un pourrait avoir déjà breveté quelque chose. Nous devons marcher sur une longue distance à travers le champ de mine alors qu'ils n'ont que quelques pas à faire. Ainsi le système est beaucoup plus dangereux pour nous que pour eux.
L'invention logicielle est freinée par les brevets
Vous devez comprendre que l'objectif essentiel du système des 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 notre attention de ce détail. Elles aimeraient nous 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 des brevets.
Le système des 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 après un certain temps - à l'origine c'était un temps assez court - tout le monde pourrait les utiliser. Naturellement la société, de son côté, paie un certain prix, et nous devons nous demander lequel est le plus grand, le bénéfice ou le prix. Bon, dans les autres domaines, je ne suis pas sûr. Je ne suis pas expert dans les autres domaines de l'ingénierie, je ne les ai jamais étudiés et je ne sais pas si les brevets sont bons pour le progrès dans ces domaines.
J'ai commencé à travailler dans le logiciel bien avant que les brevets logiciels existent, et je sais qu'ils font beaucoup de mal et presque pas de bien. Auparavant, les idées allaient et venaient. Ou bien l'idée venait de personnes travaillant à l'université, ou bien quelqu'un avait une idée sur laquelle il travaillait pour développer un logiciel. Dans les deux cas, les idées étaient publiées et ensuite tout le monde pouvait les utiliser. Pourquoi les éditeurs de logiciel publiaient-ils leurs idées ? Parce qu'ils savaient que le gros travail était d'écrire le programme.
Ils savaient qu'en publiant leurs idées ils obtiendraient la reconnaissance de la communauté. Pendant ce temps-là, celui qui voudrait entrer en compétition avec eux devrait de toutes façons é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, et en même temps développaient le logiciel. Ainsi le développement logiciel était alimenté par un flot continu d'idées. Les idées n'étaient pas le facteur limitant.
Le facteur limitant était l'écriture de programmes qui fonctionnent et que les utilisateurs apprécient. Donc en réalité, l'application du système des 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 : par le passé les gens publiaient leurs idées, ainsi nous pouvions nous en servir, alors que maintenant ils prennent des brevets sur leurs idées, et nous ne pouvons pas nous en servir pendant vingt ans.
De plus, le vrai facteur limitant - qui est l'écriture du programme - est gêné par les brevets logiciels à cause d'autre dangers que je vous ai expliqués dans la première partie 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.
Il y a une étude économique récente qui montre mathématiquement comment cela peut se produire. Vous la trouverez à www.researchoninnovation.org. Je ne suis pas sûr du nom de l'article, mais il montre que, dans un domaine où l'innovation par sauts discontinus est la règle, un système des 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.
Comment protéger des brevets le développement purement logiciel
Que peut faire un pays pour éviter ce problème ? Eh bien, il y a deux approches.
Le faire au niveau des critères d'attribution n'est pas 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. D'après 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, dans la description du système et de son fonctionnement, on trouve une grande partie se rapportant à l'ordinateur lui-même. C'est une très bonne façon de faire paraître compliqué un système trivial. C'est comme cela qu'ils arrivent à convaincre l'office des brevets que le système est non-évident. Mais on peut utiliser un autre critère, mettre la limite à un endroit un peu différent, et tout de même obtenir un résultat acceptable. On peut mettre la limite entre les processus qui transforment la matière d'une manière spécifique, et les processus dont l'objet est seulement le calcul et l'affichage d'information (ou bien une combinaison d'étapes de traitement de données et d'affichage). C'est différent du critère actuel, qui considère un calcul comme un processus mental concrétisé par l'équipement. Il y diverses façons de formuler ceci, à peu près é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 de l'équipement matériel particulier nécessaire à une tâche particulière. On pourrait donc autoriser les brevets logiciels qui sont nécessaires à une action physique déterminée. Ce ne serait pas vraiment un désastre. Après tout, à partir du moment où une personne veut réaliser une action physique ou un produit physique, elle introduit dans son entreprise familiale toute la complexité du travail avec la matière. Cette situation ressemble à celle des autres domaines de l'ingénierie. Peut-être que c'est une bonne chose d'avoir des brevets sur des logiciels de ce type, à objectif restreint.
Tant que nous pouvons garder les domaines fondamentaux du logiciel, les activités purement logicielles, à l'abri des brevets, nous avons résolu le gros du problème. Donc c'est une approche valable, et c'est ce à quoi les gens travaillent en Europe. Cependant cela ne servirait à 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 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 : « Les systèmes purement logiciels fonctionnant sur du matériel informatique multi-usages sont immunisés contre les brevets. Par définition, ils ne peuvent pas enfreindre de brevet. » De cette façon, les brevets pourraient être attribués comme ils le sont actuellement et, d'un point de vue formel, ils pourraient 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 serait en sécurité.
Les brevets logiciels doivent être repoussés par tous les pays
C'est la solution que je propose pour les États-Unis mais elle peut aussi bien s'appliquer à d'autres pays. L'un des dangers immenses qui confrontent la plupart des pays actuellement est la WTO (World Trade Organization - Organisation du commerce mondial). Cette organisation é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 voudrait que 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, soit transférée 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 (General Agreement on Tariffs and Trade - Accord général sur les tarifs douaniers et le commerce) qui traite des brevets n'exige pas les brevets logiciels. C'est ce qu'affirment de nombreux experts européens qui ont étudié la question, car ils interprètent l'expression technically affect comme signifiant qu'il doit y avoir une conséquence physique particulière sur le fonctionnement du système pour qu'un procédé soit brevetable. Et le logiciel ne fait pas cela, n'a pas à le faire, dans les domaines couverts par le brevet logiciel. Là au moins, vous n'avez pas à vous inquiéter des problèmes causés par la WTO, contrairement à d'autres aspects de la vie où elle crée des problèmes immenses.
Empêcher que les brevets logiciels arrivent en Inde est 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 été prise en compte. Personne n'a même posé la question de savoir 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 nous avons les 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 ils ont commencé à dire qu'ils étaient contre. De 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 (over > all ?) 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 servant, le gouvernement des États-Unis, font un lobbying effréné. Ils ont l'ignorance de leur côté. Il est si facile de persuader une personne ayant une vue naïve et plutôt libé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 faite à leur sujet dans tous ses détails mathématiques pour voir pourquoi on ne doit pas supposer a priori qu'ils sont toujours facteur de progrès. Il est facile à IBM de prendre quelqu'un pour cible et de lui dire : « Vous devriez 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. Vous pourriez dominer… » Pourtant 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.
Adopter les brevets logiciels en Inde serait mauvais pour les développeurs
Il est important de comprendre que chaque pays a son propre système de brevets et ses propres lois sur les brevets. Ce que vous faites dans un pays donné est placé sous une juridiction qui applique la loi de ce pays. Par conséquent, à cause des brevets logiciels, les États-Unis deviennent une sorte de champ de bataille où n'importe quelle 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 personnes utilisant un ordinateur en Inde ne risqueront pas d'être poursuivies.
Il se trouve que chaque pays accorde des brevets à des étrangers aussi bien qu'à ses propres citoyens. Donc en fait, là où les brevets logiciels sont reconnus, les étrangers peuvent en détenir. De nombreuses sociétés étrangères possèdent des brevets logiciels américains, et elles sont toutes les bienvenues pour prendre part à la bataille là-bas. Naturellement, nous, les Américains, en souffrons et en sommes les victimes. Pendant ce temps-là, le fait qu'il n'y ait pas de brevets logiciels en Inde empêche les sociétés indiennes et les sociétés étrangères de venir attaquer les gens avec ces brevets.
Donc oui, il est important que chaque pays ait ses propres lois sur les brevets, car cela fait une grande différence. Vous n'imaginez pas quelle différence cela peut faire. L'adoption des brevets logiciels par un pays n'avantage pas les développeurs de ce pays. C'est au contraire 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 votre client peut se heurter, au problème des brevets logiciels américains. Au minimum, vous risquez d'être poursuivis là-bas. Le client qui a passé commande du programme et essayé de l'utiliser peut être poursuivi également, et effectivement vous allez devoir traiter ce problème. Les États-Unis sont un problème quand vous essayez de faire des affaires là-bas. Mais au moins, ici vous êtes en sécurité. Il y a une grande différence 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, vous serez poursuivi. Tandis que dans le contexte actuel, au moins vous pouvez dire à votre client : « Bon, nous avons fait notre travail. 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. » S'il y avait des brevets logiciels en Inde, vous seriez vous-mêmes poursuivis et vous ne pourriez rien dire.
Les entreprises doivent être sensibilisées au danger des brevets logiciels
En fin de compte, les brevets logiciels enferment tous les développeurs, tous les utilisateurs d'ordinateurs 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 genre nouveau, 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 commerciales » (business methods). Qu'est ce que ça veut dire ? Une méthode commerciale est essentiellement la manière dont vous prenez les décisions dans l'entreprise. Auparavant, ces décisions étaient prises par des humains, mais maintenant elles sont quelquefois prises par des ordinateurs. Cela veut dire que les logiciels qui prennent les décisions de politique commerciale peuvent être brevetés. Ainsi, les brevets logiciels impliquent les brevets sur les méthodes commerciales et les procédures commerciales. Le résultat, c'est que n'importe quelle entreprise qui dirait « nous allons automatiser nos procédures » pourrait être poursuivie à cause d'un brevet logiciel. Si seulement les entreprises savaient cela, elles mèneraient des actions communes, par l'intermédiaire des chambres de commerce par exemple, pour exiger du gouvernement qu'il s'oppose 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 qui les menace.
Les pays doivent coopérer pour repousser les brevets logiciels
Et 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. Les pays peuvent coopérer pour mettre en place une politique intelligente. On pourrait imaginer que différents pays signent un « traité contre les brevets logiciels » (no-software patent treaty) par lequel ils se promettraient mutuellement de l'aide si les États-Unis les menaçaient de faire peser sur eux son impérialisme économique.
Parce que les États-Unis aiment bien faire ce genre de choses, vous savez. Une des clause du GATT est que les pays ont le droit d'établir des licences obligatoires pour fabriquer des médicaments en cas de 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 acheter ces médicaments au prix demandé par les société américaines.
Donc le gouvernement d'Afrique du sud était sur le point d'établir cette licence obligatoire 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é, mais comme il allait bientôt affronter l'élection présidentielle, il a réalisé que cela ferait mauvais effet et a laissé tomber. Mais c'est le genre de choses que le gouvernement des États-Unis fait tout le temps, à propos de brevets et de copyrights. Cela ne commence à les déranger que si les gens sont brevetés à mort. Il est donc important que les pays coopèrent pour contrer cela.
Pour des informations supplémentaires à propos des problèmes de brevets logiciels, voir www.progfree.org et www.ffii.org. le troisième lien est mort
S'il vous plaît, parlez à tous les dirigeants d'entreprises - n'importe quelles sortes d'entreprises - de cette question. Assurez-vous qu'ils comprennent l'étendue du problème auquel ils sont confrontés, et donnez-leur l'idée de se rapprocher de leurs organisations professionnelles pour faire du lobbying contre les brevets logiciels.
Maintenant, je vais répondre aux questions.
Au fait , les journalos par là-bas, je vous recommande d'écrire des articles séparés sur les brevets logiciels et sur le logiciel libre. Si vous mettez 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 qu'ils sont OK pour les développeurs d'autres logiciels.
Ce n'est pas vrai. Si vous repensez à ce que vous ai dit, presque rien ne se rapporte à la question de savoir si un logiciel est libre 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
Pour développer des programmes non triviaux, vous allez être obligés d'enfreindre des brevets d'IBM. Si vous êtes gros et que vous avez souvent de la chance, vous pourriez avoir des brevets à vous et amener IBM à négocier des licences croisées avec vous. Autrement, vous êtes complètement à leur merci et votre seul espoir est qu'ils vous laissent payer.
Est-ce que quelqu'un d'autre a une question ?
La plupart des programmeurs ne sont pas d'accord avec vous.
C'était comme ça avant les brevets logiciels… Si vous écriviez le programme vous-même, il n'y avait aucune raison de vous poursuivre. Aujourd'hui, vous pouvez écrire le programme vous-même, il peut même être utile et innovant, mais parce que vous n'avez pas tout réinventé, 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 compétition, je parie. Ils ne croient pas dans la compétition, 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, pas à eux, de décider ce qui est bon pour les citoyens en général.
Donc on ne devrait pas essayer d'avoir une opinion sur la propriété intellectuelle. Quand on réfléchit à la propriété intellectuelle, on réfléchit à un niveau simpliste. Faites donc comme moi, prenez un sujet à la fois et concentrez-vous dessus, découvrez les détails de ce sujet, et ensuite vous pourrez y réfléchir intelligemment. Plus tard, vous réfléchirez aussi de manière intelligente sur les autres sujets.
Premièrement, affirmez clairement que les brevets ordinaires ne n'appliquent pas et, deuxièmement, si vous voulez, vous pouvez créer ce système différent établissant un monopole de cinq ans sur les idées logicielles. 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 que la première étape est d'abolir les brevets logiciels proprement dits, et que cela doit faire partie de la transaction.
OK, si vous voulez faire passer une note, vous feriez mieux de la lire tout haut. Une autre question ?
En Inde, vous prenez sans doute pour acquis que vous en êtes préservés. Mais cela durera seulement tant que l'Inde n'aura pas de brevets logiciels.
L'important donc, c'est de ne pas leur en donner l'occasion. De même qu'aucune agence gouvernementale ne distribue de fusils aux gens dans la rue, nous ne devrions pas non plus avoir d'agence gouvernementale qui distribue des brevets logiciels aux gens dans la rue.
Nous avons rassemblé ces exemples, et cherchons des gens pour en rédiger un compte-rendu. Il faudra examiner chaque exemple et faire une recherche complète à son sujet. Ensuite il faudra 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. Ainsi toute personne ayant de très bonnes compétences en anglais écrit peut proposer son aide.
Questions sur le logiciel libre
Donc il semble que nous passions maintenant aux questions sur le logiciel libre. Je voudrais rappeler à tout le monde 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 une liberté que vous avez toujours tenue pour acquise jusqu'à présent, et que vous perdrez si vous avez des brevets logiciels.
Maintenant cependant, nous passons au logiciel libre, sujet sur lequel j'ai passé la plus grande partie de mon temps. Concrètement, le projet particulier que je conduis est le système d'exploitation GNU. C'est un système de type Unix, constitué de logiciel libre, qui est utilisé, d'après les estimations, par environ vingt millions de personnes dans le monde. Je vais donc répondre aux questions sur le logiciel libre et GNU.
Je ne peux pas vous dire ce qui va arriver. Ce que je peux vous dire, par contre, 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 représentent une contribution au projet GNU, et d'autres non.
Par exemple, ils donnent des fonds pour un travail sur le développement du système GNU/Linux. C'est bien, c'est une contribution. Oui, ils développent quelques autres paquetages de logiciels libres qu'ils ont donné à la communauté. C'est une vraie contribution. Ils développent aussi beaucoup de programmes non-libres pour les rendre compatibles avec le système GNU/Linux. Cela n'est pas une contribution.
Ils font de la publicité pour ce système. 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 ce système 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 oui, IBM fait beaucoup de choses différentes, quelques-unes bonnes, d'autres mauvaises, et pour avoir une vue d'ensemble il faut examiner chaque action individuellement. N'essayez pas de les additionner, car vous passeriez à côté d'aspects importants.
Est-ce qu'il y a encore des questions ?
Pourtant, il y a une chose que je n'aime pas dans ce que font ces sociétés : Elles ajoutent du logiciel non-libre dans la distribution.
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 ce logiciel ait du succès parce que beaucoup de gens l'utilisent. Mais notre vrai but, ce n'est pas la popularité. Notre vrai but est de faire se propager une communauté de liberté. Nous ne réussiront pas à l'atteindre si les gens utilisent des systèmes de 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 d'explications sur le logiciel libre et le projet GNU. Est-ce que je dois donner une autre conférence à Kochi ? Est-ce que je dois donner la conférence sur le logiciel libre à Kochi ?
Alors je vais répondre à cinq questions supplémentaires et je vais arrêter, parce que cela devient épuisant de répondre à tant de questions.
Ainsi, je dirais, une personne qui utilise Windows, eh bien, elle soutient activement cette structure de pouvoir, ou du moins elle en est prisonnière et n'a pas le courage de s'en échapper. Dans ce cas-là on peut lui pardonner, je suppose, et l'encourager. Vous savez, dans un endroit où les gens sont différents, il existe une variété de situations. Certaines personnes 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, du moins dans ce cas précis, c'est un peu comme un choix politique qui a des conséquences sur la société. C'est exactement pour cela qu'il est raisonnable de critiquer les gens.
Note: A cet endroit, il y a eu une courte panne de courant. L'enregistrement et la transcription sont donc incomplets.
Ce sera la dernière question.
C'était donc la dernière question. Je ne peux pas rester toute la journée à répondre aux questions, j'en suis désolé. Maintenant, je vais devoir mettre fin au débat et aller déjeuner. Merci de m'avoir écouté.
[Applaudissements]