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 poursuivre cet objectif est la Fondation pour le logiciel libre.
Stallman est un visionnaire de l'informatique moderne. C'est le génie qui a conçu des programmes tels qu'emacs, gcc, le dégogueur GNU et bien d'autres. Surtout, il est l'auteur de la GNU General Public License, la 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 20 millions d'utilisateurs dans le monde, selon les estimations.
La manière dont Stallman envisage le logiciel libre nous parle de liberté, plutôt que de prix. Ses idées contribuent grandement à créer les conditions du 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 été fait docteur honoraire en technologie par 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 des dangers des brevets logiciels. En fait c'est l'un des aspects les plus importants de la liberté de programmer, parce que cette question de brevets logiciels fait 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. Je m'en suis rendu compte dans mon travail sur le logiciel libre, parce qu'ils 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 malheureuse 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 très importante, à 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 on devrait pouvoir examiner les différentes alternatives et 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.Mais le deuxième problème, encore plus fondamental, est que ce terme recouvre en fait une collection de lois couvrant des domaines totalement différents tels que le copyright, les brevets, les marques déposées, les secrets de fabrication et encore d'autre choses. Pourtant, les lois de ces différents domaines n'ont en fait 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 manière intellligente de les regarder est d'en regarder une seule à la fois ; de les regarder séparément.
Ainsi la manière intelligente d'en parler est de ne jamais faire de généralisation, mais au contraire de parler d'une loi spécifique. Vous voyez ce que je veux dire : parler des copyrights, ou bien parler des brevets, ou bien parler des marques déposées, mais ne jamais les mettre toutes dans un même sac étiqueté « 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 si vous me demandez mon opinion sur les copyrights, ou mon opinion sur les brevets, ça me prendra une heure pour vous la 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 la question des copyrights avec la question des brevets. Ils n'ont rien à faire l'un avec l'autre. Permettez-moi de vous dire quelles sont les 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 que 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 de brevets ont un intérêt personnel dans le système. Et ainsi ils décrivent le système des brevets du point de vue de quelqu'un qui veut obtenir un brevet, pour ensuite le présenter aux programmeurs en leur disant « donnez-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 le système des brevets 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 vous en sortir avec le système des brevets ?
Eh bien, la première chose que vous devez chercher à savoir, c'est comment les brevets vont 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 18 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 légal 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, Unysys a commencé à soutirer de l'argent à diverses sociétés.
Comme nous avions besoin, au projet GNU, d'un algorithme de compression, et puisque 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. Donc en principe yous 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 10 ans ils en accordaient 10 000 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, sauf si c'est votre métier. Ce que vous pouvez faire, c'est 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 dans les tableurs. Maintenant, qu'est-ce que ça veut dire ? Cela veut dire que les tableurs, à l'origine, calculaient toujours les cellules de bas en haut. Ce qui veut dire que si une cellule dépendait d'une cellule d'indice inférieur [n.d.t. : placée plus haut dans la feuille de calcul], elle n'était pas prise en compte au premier calcul. Vous deviez faire le calcul à nouveau pour la prendre en compte. C'est clair qu'il vaut mieux faire les calculs 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 fera tout coller.
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 ce terme n'apparaissait pas non plus dans le brevet. Le brevet était présenté comme se rapportant à une technique de compilation. Ainsi une recherche raisonnable n'aurait pas trouvé ce brevet. 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 couvrant d'autres domaines, parce que dans d'autres domaines quelque chose de physique se produit, et les détails de cette chose physique vous donnent un moyen de savoir à peu près 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 de brevets 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 avez tout de même une chance d'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 couvrent. 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 lisent jamais les brevets pour 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. 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 le brevet d'hypercard avec attention, on constatait qu'hypercard tombait dans le domaine réservé de son brevet. 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 la salle et a dit « oh, ce n'est pas vrai, c'est seulement que je ne savais pas jusqu'où mon invention était protégée ». 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 quels brevets 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 d'avoir 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 tout procès. »
Trois stratégies possibles face aux brevets
Maintenant que vous avez un terrain prévisible pour mener vos affaires, qu'est-ce que vous faites ?
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, c'est-à-dire à 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 une meilleure compression que LZW. 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à.Mais dans les années 80, Compuserv avait défini un format d'image appelé GIF qui utilisait l'algorithm de compression LZW. Naturellement, lorsque le tumulte autour de ce brevet est sorti au grand jour, on a 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 is Not GIF (PNG n'est pas GIF).
Mais il y avait un problème : des tas 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. Vous lui en proposez un autre, elle changera. Vraiment ?
Ce que la personne voulait en fait, c'est pouvoir afficher les images dans Netscape. 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. Alors les gens disaient « je ne peut pas changer, c'est impossible. » 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 correct. 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 ont subi une régression de la fonction courrier. Avec ce logiciel de traitement de texte, 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 dans n'importe quel type de travail écrit. Puis quelqu'un prit un brevet sur cette fonctionnalité et XyWrite décida de résoudre le problème en l'enlevant. Ils m'ont contacté parce qu'en fait j'avais mis une fonctionnalité similaire dans la première version 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é 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. Regardez les programmes d'aujourd'hui. 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, mais le résultat est 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 protéger la vie privée des usagers de l'informatique. L'ensemble de ce 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 en fait ce domaine entier des mathématiques a été retardé pendant plus de 10 ans malgré le grand l'intérêt qu'il suscite.
Donc, voila les possibilités de contourner les brevets.
Obtenir des licences d'exploitation
Autre solution, obtenir une licence d'exploitation du brevet. C'est quelquefois possible, 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 celui-ci. Faites donc faillite ! Point à la ligne. »A 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 les jeux en réseau dans lesquels 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 2 opérations ou plus - vous savez, si quelqu'un a construit un système qui permet de jouer à un jeu, et si vous faites en sorte que ce système puisse 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 progrès sont vraiment géniaux. Evidemment, 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 une subroutine, c'est ce que vous faites. Voila donc une des raisons récurrentes pour lesquelles le système des brevets produit, pour les opposer ensuite aux inventeurs, 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 tiendraient pas devant un tribunal. Mais si, 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.
Pourtant, 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 on m'a dit que c'était le tarif bon marché 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 nécessite, disons, 20 licences, et que chaque détenteur de brevet demande cinq pour cent des ventes brutes... (et quand je dis vingt licences...) 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 de les utiliser. Même si une licence était facturée 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 vous 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
Mais 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 ça 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 majorité des sociétés essaient d'obtenir des brevets pour de défendre ; de cette façon elles augmentent leurs chances de succès. Une société a quelques brevets qui pointent de ce côté-ci, un qui pointe de ce côté-là, et encore un qui pointe dans une troisième direction. Et alors si la menace vient d'une quatrième direction, que va faire cette société ? Elle n'a pas de brevet pointant par là, donc elle est sans défense.
Entre-temps, un jour ou l'autre, quelqu'un d'autre va venir se promener par là et le directeur exécutif de la société va penser « Ho ho, nous ne sommes pas aussi profitables que je le voudrais, pourquoi ne pas essayer de 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. Ceci, incidemment, rend fallacieux le mythe que le système des brevets « protège » le « petit inventeur ».
Laissez-moi vous raconter l'épilogue de la légende du génie-qui-crève-la-faim. Prenez quelqu'un qui a travaillé dans son coin pendant des années en tirant le diable par la queue, et qui a une idée novatrice brillante pour faire une chose ou une autre. Alors il crée son entreprise et il a peur que des 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 ce domaine-là. 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 le scénario ne tient pas la route, et de plus, s'il était si bon informaticien, il n'aurait pas eu besoin de tirer le diable par la queue. Il aurait pu trouver un travail n'importe quand s'il avait voulu.
Mais admettons que ce soit vraiment ce qui s'est passé, et qu'il ait obtenu son brevet. Il dit à IBM : « IBM, vous ne pouvez pas entrer en compétition avec moi parce que j'ai obtenu ce brevet ». Mais voici ce qu'IBM lui répond : « Bien, regardons votre produit. Hum, je possède ce brevet-ci, ce brevet-là, et encore celui-là, et encore trois autres que votre produit est en train de violer. Pourquoi pas une licence croisée, vite fait ? » Et le génie-qui-crève-la-faim dit « hum, je n'ai pas assez de nourriture dans l'estomac pour combattre ces choses-là, je ferais mieux de me rendre ». Et donc ils signent un accord de licence croisée. Maintenant, devinez ce qui arrive.
IBM peut 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 grande société peut faire cela, mais une petite entreprise ne le peut pas.
Une fois, IBM a sorti 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 portefeille de brevets d'IBM. L'article disait qu'ils avaient deux manières de tirer profit de leurs 9000 brevets en cours. La première était de collecter des redevances. 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 10 fois supérieur à l'avantage qu'ils tirent de tous leurs brevets. Malgré tout, le système de brevets ressemble beaucoup à une loterie. On ne sait pas a priori ce qui va arriver à 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 de 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 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. Mon but final est de vous l'expliquer.
Contester la validité d'un brevet
So, that is the possibility of licensing a patent. The third possible option is to go to court and challenge the validity of the patent. Now the outcome of this case will depend largely on technicalities, which means essentially on randomness.You know, the dice were rolled a few years ago and you can investigate and find out what the dice came up saying and then you will find out you have got a chance. So its mainly historical accident that determines whether the patent is valid. The historical accident of whether precisely which things people happen to publish and when. So, sometimes, there is a possibility of invalidating. So even if a patent is ridiculously trivial sometimes there is a good chance of invalidating and sometimes there is not.
You can't expect the courts to recognize that it is trivial, because their standards are generally much lower than we would think are sensible. In fact, in the United States, this is been a persistent tendency. I saw a supreme court decision from something like 1954 which had a long list of patents that were invalidated by the Supreme Court starting in the 1800's. And they were utterly ridiculous like making a shape of door-knob out of rubber when previously they've been made out of wood. And this decision rebuked the patent system for going far far away from the proper standards, and they just keep on doing it.
So you can expect sensible results from that, but there are situations where when you look at the past record, you see there is a chance to invalidate a certain patent. It is worth the try, at least to investigate. But the actual court case is likely to be extremely expensive.
A few years ago, one defendant lost and had to pay 13 million dollars of which most went to the lawyers on the two sides. I think only 5 million dollars was actually taken away by the patent holder and so then there were 8 million to the lawyers.
On ne peut pas tout réinventer
Now, these are your possible options. At this point, of course, you have to write the program. And there the problem is that you face this situation not just once but over and over and over because programs today are complicated. Look at a word processor; you'll see a lot of features. Many different things each of which could be patented by somebody, or a combination of two of them could be patented by somebody. British Telecom has a patent in US on the combination of following hypertext links and letting the users dial up through a phone line. Now these are two basically separate things, but the combination of the two is patented.So, that means if there are a 100 things in your program there are potentially some five thousand copairs of two that might be patented by somebody already and there is no law against patenting a combination of three of them either. So that's just the features, you know, there are going to be many techniques that you use in writing the programs, many algorithms they could be patented too. So there are lots and lots of things that could be patented and the result is that developing a program becomes like crossing a field of land mines. Sure, each step probably will not step on a patent, chances are it will be safe. But crossing a whole field becomes dangerous.
The best way for a nonprogrammer to understand what this is like is to compare the writing of these large programs with another area in which people write something — very large symphonies. Imagine if the governments of Europe in the 1700's had wanted to promote progress in symphonic music by adopting a system of music patents. So that any idea that could be described in words could be patented if it seem to be new and original. So you'd be able to patent, say your three note melodic motive which is too short to be but it would have been patentable and may they could have patented a certain chord progression and maybe patented using a certain combination of instruments playing at the same time or any other idea that somebody could describe.
Well, by 1800 there would have been thousands of these music idea patents. And then imagine that you are Beethoven and you want to write a symphony. To write a whole symphony, you are going to have to do lots of different things and at any point you could be using an idea that somebody else has patented. Of course, if you do that, he'll say “oh! You are just a thief, why can't you write something original”. Well Beethoven had more than his share of new musical ideas. But he used a lot of existing musical ideas. He had to, because that is the only way to make it recognizable. If you don't do that, people won't listen at all. Pierre Boulez thought he was going to totally reinvent the language of music and he tried and nobody listens to it because it doesn't use all the ideas that they were familiar with. So you have to use the old ideas that other people have thought of.
Nobody is such a genius that he can reinvent the entire field of software and do useful things without learning anything from anybody else. So in effect, those people were patent holders and their lawyers, they were accusing us of being cheaters because we don't totally reinvent the field from scratch. We have to build on previous work to make progress and that is exactly what the patent system is prohibits us from doing. We have to provide features that the users are accustomed to and can recognize where they'll find our software just too difficult to use no matter how good it is.
L'invention logicielle n'a pas les contraintes pratiques de l'invention matérielle
Now, people sometimes ask me why is software different from other fields. Sometimes, of course they ask this in a rather nasty fashion, they say the other fields can deal with patents why should software be an exception? Now that's a nasty way of putting it because its making the assumption that it is wrong to want to escape from a problem. I could imagine I am saying when other people could get cancer, why shouldn't you? Clearly, if it is a problem, enabling any field to escape is good. But it is a good and serious question “are these fields in the same issue”? The patents affect all these fields the same way? Is the right policy for the software the same as the right policy for automobile engines or pharmaceuticals or chemical processes, you know, this is a serious question which is worth looking at. When you look at it, what you see is that the relationship between patents and products varies between the fields.At one extreme you have pharmaceuticals were typically a whole chemical formula is patented. So if you come up with a new drug then its not patented by somebody else. At the other extreme is software were when you write a new program, you are combining dozens or hundreds of ideas and we can't expect them all to be new. Even in an innovative program which has the few new ideas has to use lots and lots of old ideas too. And in between you find the other fields. Even in other fields, you can get patent deadlocks.
When the United States entered the World War I, nobody in the US could make a modern airplane. And the reason was that modern airplanes use several different techniques that were patented by different companies and the owners hated each other. So nobody could get a license to use all these patents. Well, the US Government decided that this was an unacceptable state of affairs and essentially, paid those patent holders a lump sum and said we have nationalized these patents and now everybody go make airplanes for us. But the amount to which this happens, the frequency and the seriousness of it varies according to how many different ideas go in one product. It varies according to how many points of patent vulnerability there are in one product. And in that question, software is at the extreme.
It's not unusual of for a few people working for a couple of years to write a program that could have a million parts in it, different parts which is maybe, say 300,000 lines of code. To design a physical system that has a million different parts, that's a major project, that's very rare. Now you find many times people make a physical object with a million parts, but its typically many copies of the same subunit and that's much easier to design — that's not a million parts in the design. Now, so, why is this?
The reason is that in other fields people have to deal with the propensity of matter. When you are designing circuits or cars or chemicals, you have to face the fact that these physical substances will do what they do, not what they are supposed to do. We in software don't have that problem and that makes it tremendously easier. We are designing a collection of idealized mathematical parts which have definitions. They do exactly what they are defined to do.
And so there are many problems we don't have. For instance, if we put an if statement inside a while statement, we don't have to worry about whether the if statement can get enough power to run at the speed its going to run. We don't have to worry about whether it would run at a speed that would generates radio frequency interference in it and induces wrong values in some other parts of the data. We don't have to worry about whether it would loop at a speed that causes resonance and eventually the if statement will vibrate against the while statement and one of them will crack. We don't have to worry that chemicals in the environment will get into the boundary between the if statement and the while statement and corrode them and cause a bad connection.
We don't have to worry other chemicals would get on them and cause short-circuit. We don't have to worry about whether the heat can be dissipated from the if statement through the surrounding while statement. We don't have to worry about whether the while statement would cause so much of voltage drop and the if statement so that the if statement won't function correctly. When you look at the value of a variable you don't have to worry about whether you've referenced that variable so many times that you exceed the fan out limit. You don't have to worry about how much capacitance there is in a certain variable and how much time it will take to store the value in it.
All these things are defined a way and the system is defined to function in a certain way and it always does. The physical computer might not function, but that's not the programs fault. So because of all these problems we don't have to deal with, our field is tremendously easier. If you assume that the intelligence of programmers is the same as the intelligence of mechanical engineers, electrical engineers and chemical engineers and so on, what's going to happen. Those of us with the easiest field, fundamentally, are going to push it further. We make bigger and bigger the things and eventually it becomes hard again.
And that's why we can develop much bigger systems than people in the other fields. They just have these hard problems to deal with all the time.
In the other fields, it may be necessary to develop an idea, you may have the idea but then you may have to try out lots of different ways to get it work at all. In software now, like that, you have the idea and what you go and do is write a program which uses this idea and then the users may like it or not. And if they don't like it, probably you can just fix some details and get it to work. There is another problem that we don't have to worry about — manufacturing of copies.
Well, when we put the if statement inside the while statement, we don't have to worry about how the if statement is going to be inserted into the while statement as a copy is being built. We don't have to worry either about making sure we have access to remove and replace the if statement if it should burn out. So all we have to do is take copy in its all purpose copy anything facility. People making physical recruitment and physical products they can do that these things has to be built piece by piece each time. The result is that for them, the cost of designing a system of certain complexity may be (gesturing) this much and the factory may take this much to set up. So they have to deal with this much with the patent system, it's a level of overhead they can live with.
For us, designing it may cost (gesturing) this much and manufacturing it may cost this much, so this much overhead from the patent system is crushing. Another way to look at it is that because we can, a few of us can, make a much bigger system, there are many more points of vulnerability where somebody might have patented something already.
We have to walk a long distance through the mine field where they they only have to walk a few feet through the minefield. So its much more of a dangerous system for us. Now, you have to realize that the extensible purpose of the patent system is to promote progress. This is something that is often forgotten because the companies that benefit from patents like to distract you from it. They like to give you the idea that patents exist because they deserves special treatment. But this is not what the patent system says.
L'invention logicielle est freinée par les brevets
Patent system says, the goal is to promote progress for the society. By encouraging certain behavior like publishing new ideas and after certain — originally that was fairly short — time, everyone could use them. Of course there is a certain price that the society pays as well and we have to ask the question which is bigger — the benefit or the price. Well, in other fields, I am not sure. I am not an expert on other fields of engineering, I've never done them and I don't know whether having patents is good for progress in those fields.I have been in software since before software patents existed and I know that software patents do a lot of harm and essentially no good. In the old days, ideas came along, either people in a university had an idea or somebody had an idea what he was working on developing a software. And either way, these ideas got published and then everyone could use them. Now why did the software publishers publish these ideas? Because they knew that the big job was writing the program.
They knew that publishing the ideas would get them credit from the community and meanwhile anybody else who wanted to compete with them would still have to write a program, which is the big job. So they typically kept the details of the program secret, of course some of us think that it is wrong, but that is a different issue they kept the details of the program secret and they publish the ideas and meanwhile the software development because software development is going on that provided the field with a steady stream of ideas so ideas were not the limiting factor.
The Limiting factor was the job of writing programs that would work and that people would like using. So, in effect, applying the patent system to software focuses on facilitating a thing which is not the limiting factor while causing trouble for the thing which is the limiting factor. You see the software patents encourage somebody to have an idea but at the same time they encourage people to restrict its use, so in fact we are actually worse off now in terms of having ideas we could use, because in the past people have the ideas and publish them and we could use them and now they have the ideas and patented them and we can't use them for twenty years.
In the mean time, the real limiting factor — which is developing the programs — this is hampered by software patents because of other dangers I explained to you in the first half of this talk. So the result is that while the system is supposed to be promoting progress in software actually it is so screwed up its just obstructing progress.
Today we have some economic research showing Mathematically how this can happen. You can find it in www.researchoninnovation.org and I am not completely sure of the name of the paper, but its one that shows that in a field where incremental innovation is typical. Having a patent system can result in slower progress. In other words the system produces counter intuitive results that are the opposite of what it was intended to do. This backs up the intuitive conclusion of every programmer who sees that software patents are absurd.
Certains brevets couvrant à la fois du logiciel et du matériel sont acceptables
So, what can a country do to avoid this problem? Well, there are two approaches, one is to address the problem at the issue of granting patents, and the other is to approach it at the point where the patents are being enforced. Doing this at the stage of granting patents is not quite as easy as you might think, now I have been talking about software patents but strictly speaking you can't classify patents into hardware patents and software patents because one patent might cover both hardware and software so in fact my definition of a software patent is a patent that can restrict software development. And if you look at many software patents you can often find that the system may describe has a large part of the computer itself as a part of the description of what's going on, that's a great way of making the whole thing seem complicated when it is really trivial. So its the way they can get the patent office to decide it is unobvious. But there is a different criterion that can be used, a slightly different place to draw the line that still does a reasonable job and that is between processes that transforms matter in a specific way and processes where the result is just calculation and display of information or a combination of data processing and display steps where others are put it as mental steps being carried out by equipment.There are various ways of formulating this, but more or less equivalent. Now this is not exactly the same as prohibiting software patents, because in some cases computers are used as a part of specific physical equipment to make it do a specific thing. And software patents might be allowed if they are part of a specific physical activity. But that's not really a disaster, after all once people are involved in a specific physical activity or a specific physical product, they are bringing into their home business all those complexities of dealing with matter. So its more like those other fields of engineering, may be its okay to have patents on that narrow kind of software.
As long as we can keep the core areas of the software, the purely software activities safe from patents we have solved the bulk of the problem. So that is a feasible approach and that's what people are working towards in Europe. However that is not going to be any use in the United States because United States already has tens of thousands and probably hundreds of thousands of software patents. Any change in the criterion for issuing patents does not help at all with the patents that already exists.
Les brevets purement logiciels doivent être abolis ou refusés partout dans le monde
So what I propose to the United States is to change the criteria for applying patents to say that purely software systems running on general purpose computing hardware are immune from patents. They by definition cannot infringe a patent and this way patents can still be granted exactly the way they are now and they can still in the formal sense cover both hardware implementations and software implementations as they do now. But software would be safe.That's the solution I propose to the US, but it could be used in other countries as well. Now, one of the tremendous dangers facing most countries today is the World Trade Organization, which sets up a system of corporate regulated trade — not free trade as its proponents like to call it, but corporate regulated trade. It replaces regulation of trade by governments that are somewhat democratic and might listen to the interest of their citizens with regulation of trade by businesses which don't pretend to listen to the citizens. So it is fundamentally antidemocratic and ought to be abolished.
But it is crucial to note that the part of the GATT agreement which deals with patents does not require software patents. Many experts who have studied this in Europe makes this claim and the reason is that they interpret technical affect as there is a specific physical consequences for physical system going on. And the software vector doesn't do that, doesn't have to be, in the domains that the patents can cover. So at least you don't have to worry about the Word Trade Organization causing problems here despite the tremendous problems they cause in other areas of life.
Preventing India from software patents here will be up to you — to the citizens of India. I am a foreigner, I have no influence except when I can convince other people through the logic of what I say. There is a chance that you can do this. When US started to have software patents the public policy question was not considered at all. Nobody even asked whether it was a good idea to have software patents. The Supreme Court made a decision which was then twisted around by an appeals court and ever since then there was software patents.
But when Europe started to consider officially authorizing software patents a few years ago, public opposition started to rise and became so strong that the politicians and the parties began paying attention to it. And started saying that they were against it. In fact two attempts to authorize software patents have been blocked already in Europe. The French Minister of Industry says that the software patents would be a disaster and under no circumstances should they be allowed in France. Over the German political parties have taken a stand against the software patents.
The battle is not yet over, you know, we have not conclusively blocked software patents in Europe because the multinational companies and their servant, the United States government, is lobbying very hard and they have ignorance on their side it is so easy for somebody with a naive near-liberal view to be persuaded that new kind of monopoly has to be good.
Adopter les brevets logiciels serait nocif pour le développement économique de l'Inde
You have to look at the details of how software patents affect software development to see that they cause problem. You have to study that economic research in its Mathematics in order to see why you shouldn't assume that patents always promote progress. So it is easy for IBM to centre someone and say you should really adopt software patents, they are great for programming and look US is ahead in when US has software patents if you have software patents too you might catch up. You can get more dominant and — when US was ahead in computers before it had software patents, it can't be because of software patents. It is important to understand that each country has its own patent systems and its own patent laws and what you do in a certain country under the jurisdiction of that country's patent law. So the result is that if the US has software patents the US becomes a sort of battleground where anybody using computer might get sued.If India avoid software patents then India is not a battleground, and computer users in India do not face this danger of getting sued. So it turns out that each country will issue patents to foreigners just as to its own citizens. So in fact in a place which has this idea of software patents foreigners can own those patents there are lots of non-US companies that own US software patents so they all welcome to get involved in the fighting in the US. Of course is we Americans to suffer become the victims of this. Meanwhile in India if there are no software patents that means Indian companies and foreign companies are prevented from coming to India and attacking people with software patents.
So, yes it is important that each countries has its own patents for that makes big difference but you can't understand what difference it makes. Having software patents in a certain country is not an advantage for developers in that country. It is a problem for anybody distributing and using software in that country. Now, if you in India are developing a program for use in US you may face the problem or your client may face the problem of US software patents. At least probably you can get sued here.
The client who commissioned the program and tried to use it might get sued in the US and indeed you will have to deal with the problem, the US is problem when you try doing business in the US. But at least you will be safe here you know at least it is a big difference between your client got sued because your client told you to make a product and that product is patented versus you get sued for making that product.
If there are software patents in India you will get sued. Wheas in the current situation at least you can say to the client “well, we did our job you told us to make this and we made it and so, I am sorry this happened to you but this is not our fault”. If there are software patents in India you get sued yourself and there is nothing you can say about that.
So the ultimate conclusion is that software patents tie all software developers, all computer users and essentially all businesses in new kind of bureaucracy which serves no beneficial social purpose. So that is a bad policy and it should be avoided. Businesses don't like bureaucracy. If businesses knew that they were threatened with a new kind of bureaucracy they would have opposed software patents very strongly. But most of them aren't aware of this.
In the US software patents have led directly to business method patents. What does this mean? A business method is basically haw you make decisions about what to do in the business. And in the past these decisions were made by humans but now sometimes they are made by computers and that means they are carried out by software and that means decision policies can be patented. So software patents implied business method patents and business procedure patents. So the result is that any business could find itself, you know, once they decide “we're going to automate the way we carry out our procedures” but now they can get sued with software patents. So if the businesses only knew they would be organizing through things like the chamber of commerce to demand opposition to software patents.
But most of them don't know and therefore it is going to be your job to inform them. Make sure that they understand the danger that they are facing. And then India may be able with the help from other countries like France and Germany to reject software patents. It is important for the people in the Indian Government to make contact with officials in European countries so that this battle against software patents doesn't have to be fought at one country at a time, countries can work together to adopt an intelligent policy. May be there should be a no software patents treaty that various countries can sign and promise each other aid when they are threatened by economic pressure from the United States as part of its economic imperialism.
Because United States likes to do that, you know, one of the provisions in the GATT agreement is that the countries have the right to make compulsory licenses for making medicines to address a public health crisis. And the South African Government proposed to do this for medicine against AIDS. South Africa has a very bad problem with AIDS the figures I heard was that a quarter of the adult population is infected. And of course, most of them can't afford to buy these medicines at the prices charged by the US companies.
So the South African Government was going to issue compulsory license which even under GATT is allowed to do, but US Government threatened economic sanctions. Vice President Gore was directly involved with this and then he'd be facing the presidential election he realized that this was going to look bad and so he dropped out of the effort. But this kind of the thing is what the US Government does all the time with regard to patents and copyrights. They only mind if people get patented to death. So it is important for countries to work together against this.
For more information about the problems of software patents see www.progfree.org and www.ffii.org. And there is also a petition to sign, www.knowepatents.org.
Please talk with all executives of businesses — any kind of businesses — about this issue. Make sure that they understand the extend of the problem they face and they think of going to business organizations to have them lobby against software patents.
Now I'll answer questions.
Oh, by the way any journos over here, I would recommend writing articles about software patents separately, from articles about free software. If you cover them in one article together, people may get the idea that software patents are only bad for the free software developers and they are okay for other software developers.
This is not true, if you think back of what I have said, hardly any of it relates to the question of whether the programs are free or not, the dangers of the same for all software developers. So please don't take the risk, the people will get confused, write separate articles.
Questions sur les brevets logiciels
To develop nontrivial programs you're going to have to infringe patents of IBMs. Now if you are big and often lucky enough, you might have some patents of your own and make IBM cross-license with you. Otherwise you are completely at their mercy and you have to hope that they just let you pay the money.
Is someone else asking?
Most programmers don't agree with you.
That's the way was before software patents — if you wrote the program yourself there is nothing to sue you about. Today you can write the program yourself, it may even be an useful and innovative program but because you didn't reinvent the whole field, you use some ideas that were already known, other people sue you. Of course, those people who wanna go around suing you, they are going to pretend that this extortion is protection for them, protection from what, protection from having competitors, I guess, they don't believe in competition, they want monopolies.
Well, to hell with them. It's not good for the public that they should get what they want, this is the question of public policy. We have to decide what is good for the citizens generally.
The US has taken trademarks all little too far. But, basically it is reasonable to have labels that you can rely on. So you shouldn't try to have an opinion about intellectual property. If you are thinking about intellectual property, you are thinking at a simplistic level. And any conclusions you reach will be simplistic. So do as I do, you know, pick one topic at a time and focus on it and find out the details about that one area, then you can think intelligently about that area and later on you can think intelligently about the other areas too.
First, make it clear that ordinary patents do not apply and second, if you wish you could create this different system of five-year software idea monopolies. Well, it's not clear that there is any particular benefit in this five-year software monopolies but it would be much better in the current situation. So if you found the government prepared to make this deal, well, I would say, we should take it. But, but we have to realize, though, that the first step is to abolish software patents strictly speaking, and that has to be part of this deal.
Okay, if you gonna pass a note, you better read it out loud. Any other questions?
Now in India you've probably taken for granted that you're safe from that. But that will only long as long as they're no software patents in India.
The point is, therefore, let me try not to hand them that opportunity. You know, since we don't have a government agency handing out guns to people on the street we should not have a government agency handing out software patents to people on the street either.
Now we collected examples of this and were looking for people to write them up. You've to look at each example and investigate it fully and write down a clear description of what happened and what the harm was and so on. We had had trouble finding people to do this. We're looking for more. So someone who is really good at writing clear English might want to volunteer for this.
Questions sur le logiciel libre
So it looks like we should now we move to Free Software questions. I'd like to remind people that until this last answer, I was not speaking for the Free Software movement. I was speaking of something of vital interest to every programmer which is to be free to write programs and not get sued for having written them as long as you wrote them yourself. And that's the freedom that you've taken for granted until now and that's the freedom you will lose if you have software patents.
Now however we're moving to the topic of Free Software, which is what I spent most of my time working on, and the individual, actual software development project that I've lead which is developing the GNU operating system, which is a Free Software, Unix-like operating system used by some twenty million people estimated today. So I am going to answer questions on Free Software and GNU.
I can't tell you what's going to happen. What I can tell you is that what IBM claims to have put a billion dollars into the GNU plus Linux operating system, that's no entirely true. You've to look carefully on what they're spending this money on, and you'll find they are spending this money on various different things, some contribute and some don't.
For instance, they are funding some work on developing the GNU/Linux system. That's good, that contributes. They do develop some other Free Software packages that they've contributed to the community. That's a real contribution.
They are also developing many non-free programs to make them run with the GNU/Linux system and that is not a contribution. And they are publicizing the system, well, it's not a primary contribution, but it does help. You know, having more user is not our primary goal. But it's nice if more people would try our software, so that does help, but then they're mistakenly calling this Linux which is not quite right, and they're lobbying for software patents in Europe, which is bad, so, yeah IBM is doing many different things, some are good and some are bad, and if you want to have a full view, it's important to look at the individual actions. Do not try to add it up because that just means you're missing the important aspects of the situation.
Are there any more questions?
Now, one thing I'm unhappy about is what the companies do this is that they add some non-free software to it.
So that's a major problem our community faces now. The tendency to put free software together with non-free software and make these non-free overall systems. And then, you know, it might seem that the software is a success because many people are using it. But if you look at our real goal, our real goal is not popularity. Our real goal is to spread a community of freedom and we're not succeeding in doing that if the people are using non-free software systems.
Unfortunately, I couldn't give both speeches. I can give a speech about software patents, or I can give a speech about free software. They're very different and each one of them is a long speech. So unfortunately what it means is that I can't explain about Free Software and the GNU project here. Am I giving anther speech in Kochi? Am I giving the Free Software speech in Kochi?
So I'll answer five more questions and then I have to call it quits because it gets to be quite draining to answer so many.
So, I would say, a person who's using Windows, well, either he's actively supporting this power structure or at least may be he's trapped in it and doesn't have the courage to get out. In that case you can forgive him, I guess, and encourage him. You know there are different situations in any place where people're different. Some people are making more or less effort to try to improve things. I believe in judging people as individuals, not as lumping them together by their groups.
But this is, in this one case it is, somewhat alike political choice with political consequences for society and that's exactly what makes sense to criticize people.
Note: At this point, there was a short blackout, and both the recording and the transcript is incomplete here.
So this will be the last question.
So that was the last question, I can't stay all day answering questions, I'm sorry. So at this point I am going to have to call a halt and get going and go have lunch. So thank you for listening.
[Applause].