Les brevets logiciels – Obstacles au développement des logiciels

Richard Stallman

Ceci est la transcription d'un discours de Richard M. Stallman du 25 mars 2002 au Laboratoire informatique de l'Université de Cambridge, organisé par la Foundation for Information Policy Research. Cette transcription et son enregistrement audio ont été effectués par Nicholas Hill, la mise en page HTML et les liens par Markus Kuhn. La version originale est hébergée sur http://www.cl.cam.ac.uk/~mgk25/stallman-patents.html.


Vous êtes peut-être familier avec mon travail sur les logiciels libres. Ce discours ne parle pas de cela. Il aborde le mauvais usage des lois qui fait du développement de logiciels une activité dangereuse. Il s'agit de ce qui arrive lorsque la législation sur les brevets est appliquée au domaine du logiciel.

Il ne s'agit pas du brevetage des logiciels. C'est une très mauvaise façon, biaisée, pour qualifier ce discours, car il n'y est pas question de brevetage de programmes individuels. Si c'était le cas, cela ne ferait pas de différence et serait basiquement inoffensif. Il s'agit plutôt du brevetage des idées. Chaque brevet couvre une certaine idée. Les brevets logiciels sont des brevets qui couvrent des idées sur le logiciel, des idées que vous utiliseriez dans le développement de logiciels. C'est ce qui en fait un dangereux obstacle pour tout développement de logiciels.

Vous avez peut-être entendu des gens utiliser un terme biaisé : «propriété intellectuelle». Ce terme, comme vous pouvez le voir est trompeur. Il prétend que quel que soit ce dont vous parlez, il faut le traiter comme une sorte de propriété, ce qui est une des nombreuses possibilités. Ce terme de «propriété intellectuelle» préjuge la plus simple question quel que soit le domaine où vous évoluez. Cela ne favorise pas une pensée claire et ouverte.

Il y a un problème supplémentaire qui n'a rien à voir avec la promotion d'une quelconque opinion. Il réside dans la façon de comprendre même les faits. Le terme «propriété intellectuelle» est un fourre-tout. Il englobe des domaines légaux complètement différents tels que les droits d'auteur et les brevets qui sont totalement différents. Chaque détail est différent. Il met également dans le même panier les marques déposées qui sont encore plus différentes et diverses autres choses rencontrées plus ou moins souvent. Aucun d'entre eux n'a quoi que ce soit en commun avec les autres. Historiquement, leurs origines sont totalement séparées. Les lois qui les régissent ont été conçues indépendamment. Ils couvrent des domaines et activités différentes. Les problèmes de politique publique qu'ils soulèvent sont totalement indépendants. Aussi, si vous essayez de penser à ces questions comme un tout, vous êtes assuré d'en venir à des conclusions stupides. On ne peut littéralement pas avoir d'opinion intelligente et sensée sur la «propriété intellectuelle». Si vous voulez réfléchir clairement, ne mélangez pas ces questions. Réfléchissez aux droits d'auteur puis aux brevets. Informez-vous sur la législation relative aux droits d'auteur, puis, séparément, sur celle relative aux brevets.

Pour donner un exemple de quelques-unes des plus grandes différences entre les droits d'auteurs et les brevets : les droits d'auteur couvrent les détails de l'expression d'une œuvre. Les droits d'auteur ne traitent pas des idées. Les brevets ne concernent que les idées et l'utilisation des idées. Le droit d'auteur s'applique automatiquement. Les brevets proviennent d'un office des brevets en réponse à une demande de brevet.

Les brevets coûtent beaucoup d'argent. En fait, cela coûte même plus de payer les avocats qui rédigent la demande que le dépôt de brevet lui-même. Cela prend typiquement quelques années pour qu'une demande soit prise en compte, même si les offices de brevets font un travail d'analyse extrêmement désordonné.

Les droits d'auteur sont terriblement longs. Dans certains cas, ils peuvent durer jusqu'à 150 ans, alors que les brevets ne s'appliquent que 20 ans, ce qui est assez long pour leur survivre mais très long à l'échelle d'un domaine tel que celui des logiciels.

Rappelez-vous il y a environ 20 ans lorsque le PC venait de naître. Imaginez être obligé de développer des logiciels en utilisant seulement les idées qui étaient connues en 1982.

Le droit d'auteur couvre le plagiat. Si vous écrivez un roman qui s'avère être mot pour mot identique à Autant en emporte le vent et que vous pouvez prouver que vous n'avez jamais vu Autant en emporte le vent, cela pourrait être une défense contre une accusation d'infraction à la loi sur les droits d'auteur.

Un brevet est un monopole absolu sur l'utilisation d'une idée. Même si vous pouviez prouver que vous avez eu l'idée par vous-même, cela serait totalement sans importance si l'idée est brevetée par quelqu'un d'autre.

J'espère que vous oublierez les droits d'auteur pendant le reste de cette discussion car elle traite des brevets et vous ne devriez jamais mélanger droits d'auteur et brevets. Il s'agit de votre appréhension de ces problèmes légaux. C'est ce qui arriverait à votre compréhension de la chimie si vous confondiez l'eau et l'éthanol.

Quand vous entendez quelqu'un décrire le système des brevets, il le décrit généralement du point de vue d'une personne qui espère obtenir un brevet -- de ce que cela donnerait pour vous d'obtenir un brevet. De ce que cela ferait pour vous de vous promener dans la rue avec un brevet en poche, de le sortir aussi souvent que vous le voulez et de le brandir à quelqu'un en disant «Donnez-moi votre argent». Il y a une raison pour ce préjugé, qui est que la plupart des gens qui vous parleront ainsi du système de brevet, y ont un intérêt et c'est pourquoi ils veulent que vous l'appréciiez.

Il y a une autre raison : le système de brevets ressemble beaucoup à une loterie car seule une fraction ténue des brevets profitent effectivement aux détenteurs de brevets. En fait, le journal «The Economist» l'a une fois comparé à une loterie. Si vous avez déjà vu des publicités pour des loteries, elles vous invitent toujours à penser que vous allez gagner. Elles ne vous suggèrent pas que vous aller perdre, même s'il est plus que probable de perdre. Il en est de même avec les publicités pour le système des brevets. Elles vous invitent toujours à penser que vous serez le gagnant.

Pour contrebalancer ce préjugé, je vais vous décrire le système des brevets du point de vue de ses victimes. C'est-à-dire du point de vue de quelqu'un qui veut développer un logiciel mais qui est obligé d'affronter le système de brevets logiciels et dont l'issue pourrait être un procès.

Alors, quelle est la première chose que vous allez faire après avoir eu une idée du genre de programme que vous voulez écrire? La première chose que vous voudriez essayer de faire pour traiter avec le système de brevets est de découvrir les brevets qui pourraient couvrir le programme que vous voulez écrire. C'est impossible. La raison en est que les demandes de brevets en attente sont confidentielles. Après un certain temps, elles peuvent être publiées, disons 18 mois. Mais cela fait beaucoup de temps pour vous pour écrire un programme et même le publier en ne sachant pas s'il y aura un brevet et si vous allez être poursuivi. Ce n'est pas qu'une hypothèse. En 1984, le programme «compress» était écrit, un programme permettant la compression de données. À l'époque, il n'y avait pas de brevet sur l'algorithme de compression LZW qui était utilisé. Puis, en 1985, les États-Unis ont sorti un brevet sur cet algorithme et les années qui suivirent, ceux qui distribuaient le programme «compress» ont commencé à être menacés. Il n'y avait aucun moyen pour que l'auteur de «compress» ait pu réaliser qu'il allait probablement être poursuivi. Tout ce qu'il a fait fut d'utiliser une idée qu'il avait trouvé dans un journal, comme les programmeurs l'ont toujours fait. Il n'avait pas réalisé qu'on ne pouvait plus utiliser en toute sécurité des idées trouvées dans un journal.

Oublions ce problème. Les brevets accordés sont publiés par l'office des brevets de sorte que vous pouvez consulter toute leur longue liste et voir exactement ce qu'ils disent. Bien sûr, vous ne pourriez en fait pas lire toute la liste car il y en a beaucoup trop. Aux États-Unis, il y a des centaines de milliers de brevets logiciels.

Il n'y a aucun moyen pour que vous puissiez savoir ce dont ils traitent tous. Vous essayeriez de rechercher les brevets pertinents. Certains disent que cela devrait être facile de nos jours avec les ordinateurs. Vous pourriez rechercher des mots-clés, etc. Cela marche jusqu'à un certain point. Vous trouverez quelques brevets dans le domaine. Mais vous ne les trouverez pas nécessairement tous cependant. Par exemple, il y avait un brevet logiciel qui doit avoir expiré maintenant, sur le recalcul de l'ordre naturel dans les tableurs. Ce qui signifie en gros que quand vous rendez certaines cellules dépendantes d'autres cellules, cela recalcule toujours tout après les cellules les cellules dont elles dépendent, de sorte qu'après un recalcul, tout est à jour. Les premiers tableurs faisaient le recalcul du haut vers le bas, donc si faisiez dépendre une cellule d'une cellule plus bas dans la feuille, et que vous aviez quelques étapes similaires, vous deviez faire le recalcul plusieurs fois pour que les nouvelles valeurs se propagent. Vous étiez supposés avoir des cellules dépendant de cellules situées au-dessus d'elles. Alors, quelqu'un s'est dit : «Pourquoi ne ferai-je pas le recalcul de sorte que tout soit recalculé en fonction des dépendances, quelle que soit la position dans la feuille? Cet algorithme est connu sous le nom de tri topologique. La première référence à cet algorithme que j'ai pu trouver datait de 1963. Le brevet couvrait plusieurs dizaines de moyens différents pour mettre en œuvre le tri topologique mais vous n'auriez pas pu trouver ce brevet en recherchant «tableurs». Vous n'auriez pas pu le trouver en recherchant «ordre naturel» ou «tri topologique». Il ne contenanit aucun de ces termes. En fait, il était décrit comme une méthode de compilation de formules en code objet. Quand je l'ai vu la première fois, j'ai pensé que ce n'était pas le bon brevet.

Supposons que vous ayez une liste de brevets. Vous voulez donc connaître ce que vous n'êtes pas autorisé à faire. Quand vous essayez d'étudier ces brevets, vous découvrez qu'ils sont très difficiles à comprendre car ils sont écrits dans un langage juridique tortueux, dont la signification est très dure à saisir. Ce que disent les offices de brevet ne veut souvent pas dire ce qu'ils semblent dire.

Il y a eu une étude gouvernementale australienne sur le système des brevets dans les années 1980. Elle concluait que, en dehors de la pression internationale, il n'y avait aucune raison d'avoir un système de brevets. Ce n'était pas bon pour le public et elle recommandait de l'abolir, s'il n'y avait la pression internationale. Une des choses qu'ils ont citées était que les ingénieurs n'essayaient pas de lire les brevets pour apprendre des choses, car il est trop difficiles de les comprendre. Ils citaient aussi un ingénieur qui disait : «Je ne reconnais pas mes propres inventions dans ces brevets».

Ce n'est pas seulement théorique. Aux environs de 1990, un programmeur du nom de Paul Heckel poursuivait Apple en revendiquant que Hypercard violait deux de ses brevets. Quand il vit Hypercard pour la première fois, il ne pensait pas que cela avait quelque chose à voir avec ses brevets, avec ses «Inventions». Cela n'y ressemblait pas. Quand son avocat luit dit que ses brevets pouvaient être lus comme couvrant une partie de Hypercard, il décida d'attaquer Apple. Quand j'ai fait un discours à Stanford à ce sujet, il était présent dans le public et il dit : «Ce n'est pas vrai, je n'avais seulement pas compris l'étendue de ma protection!». J'ai dit : «Oui, c'est ce que j'ai dit!». Donc, en fait, vous devrez passer beaucoup de temps à parler avec vos avocats pour trouver ce que ces brevets vous interdisent de faire. Finalement, ils diront quelque chose de ce genre : «Si vous faites ceci, vous êtes sûr de perdre; si vous faites cela, il y a de grandes chances que vous perdiez, et si vous voulez vraiment être tranquille, restez en dehors de ce domaine. Et à propos, il y a une chance non négligeable qu'il en résulte un procès».

Maintenant que vous savez où vous allez pour faire des affaires(!), qu'allez-vous faire? Bien, il y a trois approches que vous pourriez essayer. N'importe laquelle est applicable dans certain cas.

Ce sont 

  1. Éviter le brevet
  2. Obtenir une licence du brevet
  3. Invalider le brevet au tribunal.

Laissez-moi décrire ces trois approches et ce qui les rend réalisables ou irréalisables.

1) Éviter le brevet

Cela veut dire de ne pas utiliser l'idée couverte par le brevet. Cela peut être facile ou difficile, en fonction de ce sur quoi porte l'idée. Dans certains cas, une fonctionnalité est brevetée. Alors, vous évitez le brevet en ne mettant pas en œuvre cette fonctionnalité. Ensuite, cela dépend juste de l'importance de la fonctionnalité. Dans certains cas, vous pouvez vivre sans. Il y a quelques temps, les utilisateurs du traitement de texte «XyWrite» ont reçu une mise à jour régressive par courrier. Cette mise à jour supprimait une fonctionnalité qui permettait de prédéfinir des abréviations. C'est-à-dire, quand vous tapez une abréviation suivie d'un caractère de ponctuation, elle est immédiatement remplacée par une extension. Ainsi, vous pouvez définir une abréviation pour une phrase longue, taper l'abréviation, et alors la phrase longue sera insérée dans le document. Ils m'écrivirent à ce sujet car ils savaient que l'éditeur «Emacs» offrait une fonctionnalité similaire. En fait, c'est le cas depuis les années 70. C'était intéressant car cela m'a montré que j'avais eu au moins une idée brevetable dans ma vie. Je savais que c'était brevetable parce que quelqu'un d'autre l'a breveté après! En fait, ils avaient essayé ces différentes approches. D'abord ils ont essayé de négocier avec le détenteur du brevet, qui finit par ne pas négocier de bonne foi. Puis, ils cherchèrent s'ils pouvaient avoir une chance d'invalider le brevet. Ce qu'ils décidèrent de faire, c'est d'oter la fonctionnalité. Vous pouvez vivre sans cette fonctionnalité. S'il ne manque que celle-là au traitement de texte, les gens continueront peut-être à l'utiliser. Mais au fur et à mesure que diverses fonctionnalités sont touchées, vous arrivez finalement à un programme dont les gens pensent qu'il n'est pas très bon et il est probable qu'ils le rejettent. C'est un brevet de plutôt petite étendue sur une fonctionnalité très spécifique.

Que faites-vous du brevet British Telecom sur les liens hypertexte traversant ainsi que les accès par ligne commutée? Les liens hypertexte sont absolument essentiels à la plupart des utilisations d'un ordinateur de nos jours. Et les accès par ligne commutée sont aussi essentielles. Comment feriez-vous sans cette fonctionnalité, qui, soit dit en passant, n'est même pas une fonctionnalité, mais en fait la combinaison de deux d'entre elles seulement juxtaposées arbitrairement. C'est un peu comme avoir un canapé et une télévision dans la même pièce.

Quelquefois, l'idée qui est brevetée sera tellement large et basique qu'elle régira un domaine tout entier. Par exemple, l'idée de chiffrement à clé publique qui a été brevetée aux États-Unis. Le brevet a expiré en 1997. Jusque là, il bloquait grandement l'utilisation du chiffrement à clé publique aux États-Unis. De nombreux programmes que les gens ont commencé à développer furent anéantis. Ils ne furent jamais vraiment disponibles car les détenteurs du brevet les menaçaient. Puis, un programme partit. Le programme PGP, qui était initialement publié comme logiciel libre. Apparemment, les détenteurs du brevet, comme ils se préparaient à attaquer comme ils l'avaient prévu, réalisèrent qu'ils pourraient avoir une trop mauvaise publicité. Ils imposèrent alors des restrictions pour qu'il soit à usage non-commercial seulement, ce qui signifiait qu'il ne pourrait pas avoir trop de succès. Ils limitèrent ainsi grandement l'utilisation du chiffrement à clé publique pour une décennie ou plus. Il n'y avait pas moyen de contourner ce brevet. Il n'y avait rien d'autre que vous pouviez faire comme cela.

Quelquefois, un algorithme spécifique est breveté. Par exemple, il y a un brevet sur une version optimisée de la transformation rapide de Fourier. Il s'exécute environ deux fois plus vite. Vous pouvez contourner cela en utilisant la transformation rapide de Fourier ordinaire dans votre programme. Cette partie de votre programme prendra deux fois plus de temps. Peut-être que cela n'a pas vraiment d'importance, peut-être est-ce une petite partie du temps d'exécution de votre programme. Peut-être que s'il est deux fois plus lent, vous ne le remarquerez même pas. Ou peut-être cela signifie que votre programme ne fonctionnera pas car il prendra deux fois le temps réel pour faire son travail. Les effets varient.

Dans certains cas, vous pouvez trouver un meilleur algorithme. Cela peut ou non être bénéfique pour vous. Parce que nous ne pouvions pas utiliser «compress» dans le projet GNU nous avons commencé à chercher d'autres algorithmes pour la compression de données. Quelqu'un nous écrivit en disant qu'il en avait un. Il avait écrit un programme et décidé de contribuer pour nous. Nous allions publier le programme. Par chance, je suis tombé sur un exemplaire du New York Times dans lequel il y avait la colonne hebdomadaire sur les brevets. Je n'avais pas vu d'exemplaires du Times plus d'une fois en quelques mois. Alors je l'ai regardé et cela disait que quelqu'un avait obtenu un brevet pour l'«invention d'une nouvelle méthode de compression de données». Je me suis dit qu'il valait mieux que je jette un œil à ce brevet. J'ai obtenu une copie et il s'avéra qu'il couvrait le programme que nous étions juste à une semaine de publier. Ce programme mourut avant de naître. Plus tard, nous trouvions un autre algorithme qui n'était pas breveté. Cela devint le programme gzip, qui est à présent effectivement le standard de facto pour la compression de données. En tant qu'algorithme à utiliser dans un programme pour la compression de données, il était bien. Quiconque voulait faire de la compression de données pouvait utiliser «gzip» plutôt que «compress». Mais ce même algorithme de compression breveté LZW était aussi utilisé dans les formats d'image tel que le format GIF. Mais là, parce que le travail que les gens voulaient voir effectué n'était pas simplement de compresser des données, mais de faire des images que les gens pourraient afficher dans leurs logiciels, il se révéla extrêmement difficile de passer à un algorithme différent. Nous n'avons pas été capables de la faire en 10 ans! Oui, les gens ont utilisé l'algorithme gzip pour définir un autre format d'image, quand ils ont commencé à être menacés de poursuites judiciaires pour l'utilisation de fichiers GIF. Quand nous avons commencé à dire aux gens d'arrêter d'utiliser des fichiers GIF, de passer aux fichiers PNG, les gens dirent  «Nous ne pouvons pas changer. Les navigateurs ne gèrent pas encore le nouveau format». Les développeurs de navigateurs dirent : «Il n'y a pas d'urgence là-dessus. Après tout, personne n'utilise ce format de fichier».

En effet, il y avait tant d'inertie dans la société dans l'utilisation du format GIF, que nous n'avons pas été capables d'obtenir des gens qu'ils changent. Essentiellement, l'utilisation dans la communauté du format GIF pousse encore les sites à utiliser ce format avec comme résultat qu'ils sont vulnérables à ces menaces de procès.

En fait, la situation est encore plus bizarre. Il y a en fait deux brevets couvrant l'algorithme de compression LZW. L'office des brevets ne pouvait même pas dire qu'il avait accordé deux brevets sur la même chose. Il n'en retrouvait pas trace. Il y a une raison à cela. Cela prend du temps d'étudier ces deux brevets pour voir s'ils couvrent réellement la même chose.

S'il s'agissait de brevets sur un processus chimique, cela serait beaucoup plus facile. Vous pourriez voir quelles substances ont été utilisées, quels étaient les apports, quels étaient les rendements, quelles actions physiques sont entrées en jeu. Peu importe la façon dont ils sont décrits, vous verriez ce qu'ils sont et vous verriez s'ils sont similaires.

Si une chose est purement mathématique, il y a de nombreuses façons de la décrire, qui sont bien plus différentes. Elles ne sont pas similaires de manière superficielle. Vous devez réellement les comprendre pour voir si cela parle de la même chose. L'office des brevets n'a pas le temps de le faire. L'Office américian des brevets et des marques (USPTO) depuis quelques années, a passé en moyenne 17 heures par brevet. Ce n'est pas assez pour y réfléchir avec attention, donc, bien sûr, il commet des erreurs comme celle-là. En fait, je vous parlais du programme mort avant de naître. Cet algorithme avait également deux brevets accordés aux États-Unis. Apparemment, ce n'est pas si inhabituel.

Éviter les brevets peut être facile ou impossible. Cela peut être facile mais cela rend votre programme inutile. C'est fonction de la situation.

Voici un autre point que je dois mentionner : quelquefois une société ou un consortium peut faire d'un format ou d'un protocole le standard de facto. Alors, si ce format ou ce protocole est breveté, c'est un vrai désastre pour vous. Il y a même des standards officiels qui sont restreints par des brevets. Il y a eu une grande indignation politique en septembre dernier quand le World Wide Web Consortium a proposé de commencer à adopter des standards qui étaient couverts par des brevets. La communauté a objecté et ils ont donc fait marche arrière. Ils recommencèrent alors à insister sur le fait que tout brevet devait pouvoir être librement mis en œuvre par quiconque et que les standards devaient être libres pour quiconque pour leur mise en œuvre. C'est une victoire intéressante. Je pense que c'était la première fois qu'un organisme de standardisation avait pris cette décision. Il est normal pour les organismes de standardisation de souhaiter mettre quelque chose dans un standard qui est restreint par des brevets mais les gens ne sont pas autorisés à avancer et à le mettre en œuvre librement. Nous avons besoin d'aller trouver d'autres organismes de standardisation et les appeler à changer leur règles.

2) Obtenir une licence du brevet

La seconde possibilité, au lieu d'éviter le brevet, est d'obtenir une licence pour le brevet. Ce n'est pas nécessairement un choix. Le détenteur du brevet n'est pas obligé de vous offrir une licence, ce n'est pas requis. Il y a 10 ans, la Ligue pour la liberté de la programmation a reçu une lettre demandant de l'aide, d'une personne dont la société familiale fabriquait des machines à sous pour les casinos et ils utilisaient des ordinateurs pour les faire fonctionner. Il a reçu une menace d'une autre société qui disait : «Nous avons les brevets». Vous n'êtes pas autorisés à faire ces choses. Fermez boutique.

J'ai regardé le brevet. Il couvrait  Avoir des ordinateurs sur un réseau pour des jeux tel que chaque ordinateur gère plus d'un jeu et permette de jouer à plus d'un jeu à la fois.

Vous trouverez que l'office des brevets pense réellement qu'il y a quelque chose de brillant à faire plus d'une chose à la fois. Ils ne réalisent pas qu'en informatique, c'est la façon la plus évidente pour tout généraliser. Vous l'avez fait une fois et maintenant vous pouvez le faire autant de fois que vous le voulez, vous pouvez faire un sous-programme. Ils pensent que si vous faites quelque plus d'une fois, cela signifie que d'une façon ou d'une autre vous êtes brillant et que vraiment personne ne peut argumenter avec vous et que vous avez le droit de donner des ordres à tout le monde. enfin, on ne lui a pas proposé de licence. Il devait fermer. Il ne pouvait vraiment pas se permettre d'aller en justice. Je dirais que ce brevet en particulier était une idée évidente. Il est possible qu'un juge ait pu en être d'accord, mais nous ne le saurons jamais car il ne pouvait pas se permettre d'aller au procès.

Cependant, beaucoup de détenteurs de brevets offrent des licences. Ils demandent souvent beaucoup d'argent pour cela. La société qui détenait le brevet du recalcul en ordre naturel demandait 5% des ventes brutes de chaque tableur aux États-Unis pour la licence. On m'a dit que c'était le prix bon marché avant poursuites juduciaires. Si vous allez au procès et qu'ils gagnent, ils demanderaient plus. Vous pourriez vous permettre de donner 5% pour avoir une licence pour ce brevet-là, mais que faire si vous avez besoin des licences pour 20 brevets différents pour faire votre programme? Alors, tout l'argent que vous gagnez irait dans les brevets. Et si vous aviez besoin de licences pour 21 brevets?

Des hommes d'affaires m'ont dit qu'en pratique, deux ou trois empêcheraient de faire marcher une affaire.

Il y a une situation où les licences de brevets sont une très bonne solution. C'est-à-dire si vous êtes une très grosse société multinationale. Car ces sociétés possèdent beaucoup de brevets, et font des licences croisées entre elles. De cette façon, elles échappent à la plupart des dommages occasionnés par le système de brevets et n'en prennent que le bon côté. IBM a publié un article dans le magazine «Think». Je crois que c'était le numéro 5 de l'année 1990 sur le portefeuille de brevets d'IBM, qui disait qu'IBM obtenait deux types de bénéfice de ses 9000 brevets américains. Je crois que le nombre est plus important aujourd'hui. Le premier était de percevoir des royalties et le second, d'avoir accès aux brevets des autres. Ils disaient que le second est plus grand d'un ordre de grandeur. Donc, le bénéfice qu'IBM retirait d'être autorisé à utiliser les idées qui étaient brevetées par d'autres était 10 fois le bénéfice direct qu'il en retirait en donnant des licences de ses propres brevets. Qu'est-ce que cela signifie réellement?

Quel est le bénéfice qu'obtient IBM de son accès aux brevets des autres? C'est en fait le bénéfice d'être excusé des ennuis que peut vous causer le systèmes de brevets. Le système de brevets est comme une loterie. Ce qui peut arriver avec n'importe quel brevet, c'est soit rien, soit une aubaine pour le détenteur du brevet ou un désastre pour quelqu'un d'autre. Mais IBM est si gros que pour eux, cela s'équilibre. Ils ont l'occasion de mesurer la moyenne entre les dommages et les bénéfices du système de brevets. Pour eux, les ennuis du système de brevets auraient été 10 fois ceux des bénéfices. Je dis auraient été car IBM par ses échanges de licences croisées évite d'avoir à affronter les ennuis. Ces ennuis sont seulement potentiels. Cela ne leur est pas réellement arrivé. Mais quand ils mesurent les bénéfices retirés pour avoir éviter ces ennuis, ils les estiment à 10 fois la valeur de l'argent qu'ils ont retiré de leurs brevets.

Ce phénomène de licences croisées réfute un mythe commun, le mythe du génie qui meurt de faim. Le mythe qui dit que les brevets «protège» le «petit inventeur». Ces termes sont des termes de propagande. Vous ne devriez pas les utiliser. Le scénario se présente comme ceci : supposez qu'il y ait un brillant concepteur de quoi que soit. Supposez qu'il ait passé des années à mourir de faim dans son grenier pour concevoir un nouveau type de truc formidable et qu'il veuille maintenant le fabriquer; n'est-ce pas une honte que les grosses sociétés entrent en concurrence avec lui, lui retirant toute l'affaire et qu'il «meure de faim». Je voudrais faire remarquer que les gens dans les domaines de la haute technologie ne travaillent généralement pas seuls dans leur coin et que les idées ne viennent pas du néant, elles sont basées sur les idées d'autres personnes, lesquelles ont de très fortes chances d'obtenir un travail si elles en ont besoin de nos jours. Aussi, ce scénario, l'idée qu'une idée géniale vienne à l'esprit de cette personne brillante travaillant seule est irréaliste tout comme celle qu'il serait en danger de mourir de faim. Mais il est concevable que quelqu'un puisse avoir une idée et cette idée combinée avec 100 ou 200 autres idées peut être la base pour faire un produit et que les grosses sociétés puissent entrer en concurrence avec lui. Alors voyons ce qu'il arrive s'il essaie d'utiliser un brevet pour les arrêter. Il dit : «Oh non, IBM. Vous ne pouvez pas me concurrencer. J'ai ce brevet. IBM dit voyons cela. Regardons votre produit. Hmmm. J'ai ce brevet et celui-ci, et celui-ci et celui-ci et celui-ci et celui-ci et celui-ci, que des parties de votre produit violent. Si vous pensez que vous pouvez vous battre contre tous ces brevets au tribunal, je ferai juste demi-tour et j'en trouverai d'autres. Alors, pourquoi n'échangerions-nous pas des licences croisées?». Et ensuite, ce brillant petit inventeur dit : «Bien, d'accord, nous croiserons nos licences». Alors il peut rentrer et faire son merveilleux truc, mais IBM aussi. IBM a l'accès à son brevet et a de droit de le concurrencer, ce qui signifie que ce brevet n'a pas du tout «protégé» l'inventeur. Le système de brevets ne protège vraiment pas.

Les très grosses sociétés évitent, pour la plupart, les dégâts provoqués par le système des brevets. Elles n'en voient principalement que le bon côté. C'est pourquoi elles veulent avoir des brevets logiciels. Ce sont celles qui en bénéficient. Mais si vous êtes un petit inventeur ou que vous travaillez pour une petite société, la petite société ne sera pas capable de faire cela. Elles essaient. Le problème est qu'elles ne peuvent pas obtenir assez de brevets pour faire cela. Chaque brevet désigne une certaine direction. Donc, si une petite société a des brevets qui pointent là, là et là et que quelqu'un dirige un de ses brevets dessus et dit : «Donnez-moi votre argent», il sont impuissants. IBM peut le faire grâce à ses 9000 brevets, ils désignent tout, peu importe où vous vous situez, il y a probablement un brevet IBM qui vous désigne. C'est pourquoi IBM peut presque toujours faire des licences croisées. Les petites sociétés ne peuvent qu'occasionnellement faire des licences croisées. Elles diront qu'elles veulent des brevets pour se défendre mais elles ne pourront en obtenir suffisamment pour être capables de se défendre.

Il y a de cas où même IBM ne peut pas faire de licences croisées. C'est-à-dire quand il y a une seule société qui a un brevet et qui extorque de l'argent aux gens. La société qui possède le brevet du recalcul en ordre naturel est exactement ce genre de société. Leur seul commerce est de menacer de procès les gens et de récolter de l'argent des gens qui font réellement du développement.

Il n'y a pas de procédures légales pour les brevets. Je pense que les avocats savent la difficulté que ce serait d'avoir à traiter avec le système des brevets eux-mêmes. Le résultat est qu'il n'y a aucun moyen d'obtenir un brevet pour forcer une société à faire des licences croisées. Alors, ils circulent et extorquent tout le monde. Mais je pense que des sociétés comme IBM se disent que c'est le prix à payer et s'en accommodent.

Voilà donc, en matière de licence des brevets, ce qui peut être possible ou non et ce que vous pouvez ou non vous permettre.

3) Invalider le brevet au tribunal

Afin d'obtenir un brevet, l'invention proposée est supposée être nouvelle, utile et non évidente. C'est la formulation utilisée aux États-Unis. Je pense que les autres pays utilisent une formulation différente qui en est très proche. Bien sûr, quand l'office des brevets entre en jeu, ils commencent par interprêter nouveau et non évident. Nouveau finit par signifier nous ne l'avons pas dans nos fichiers et non évident finit par signifier non évident pour quelqu'un avec un QI de 50.

Quelqu'un qui étudie la plupart des brevets accordés aux États-Unis, ou du moins, qui le faisait, je ne sais pas s'il arrive toujours à les suivre, a dit que 90% d'entre eux ne passerait pas le test de la Ville de Cristal, ce qui voulait dire que si quelqu'un de l'office des brevets sortait et allait chez le marchands de journaux acheter quelques magazines d'informatique, il verrait que ces idées sont déjà connues.

L'office des brevets fait des choses si manifestement stupides, que vous n'avez pas besoin de connaître l'état de l'art pour voir que c'est stupide. Ce n'est pas limité au logiciel. J'ai vu une fois le fameux brevet sur la souris de Harvard qui a été obtenu après que Harvard ait génétiquement modifié une lignée de souris avec un gène provoquant le cancer. Le gène en question était déjà connu et était inséré selon des méthodes connues sur une lignée de souris existante. Le brevet qu'ils ont obtenu couvrait l'introduction d'un gène provoquant le cancer pour n'importe quel type de mammifères, quelque soit la méthode utilisée. Vous n'avez pas besoin de connaître quoi que ce soit en manipulation génétique pour réaliser que c'est ridicule.

On m'a dit que cette surenchère de revendication est une pratique normale et que l'Office américain des brevets et des marques invitait parfois les postulants au brevet à rendre leur revendication plus étendue. En fait, rendre la revendication plus étendue jusqu'à ce que vous pensiez qu'elle empiète sur quelque chose d'autre qui est antérieure sans ambiguïté. Voyez tout ce que vous pouvez imaginer que cela recouvre.

Quand les programmeurs regardent des brevets, ils disent pour beaucoup d'entre eux, que c'est si ridiculement évident! Les bureaucrates des brevets ont toutes sortes d'excuses pour justifier d'ignorer ce que pensent les programmeurs. Ils disent : «Oh! mais vous devez considérer cela en vous plaçant 10 ou 20 ans en arrière». Puis, ils découvrirent qu'en disséquant les choses vous pouviez finalement perdre vos positions. Tout peut paraître non évident si vous le décortiquez ou si vous l'analysez suffisamment. Vous perdez tout simplement votre bon sens ou au moins la capacité à décider de ce qui est évident et de ce qui ne l'est pas. Ensuite, bien sûr, ils décrivent les détenteurs du brevet comme de brillants inventeurs, tous. Par conséquent, nous ne pouvons pas remettre en question leur droit à exercer leur pouvoir sur ce que nous pouvons faire.

Si vous allez en justice, les juges sont probablement un peu plus rigoureux sur l'idée de ce qui est évident ou pas. Mais le problème, c'est que cela coûte des millions de dollars de faire cela. J'ai entendu parler d'une affaire de brevet, je me rappelle que le défendeur était Qualcomm, et je crois que la décision de la cour fut 13 millions dollars dont la plus grande partie pour payer les honoraires des avocats des deux côtés. Il restait quelques millions de dollars pour le plaignant car ils avaient perdu.

Dans une large mesure, la question de la validité d'un brevet dépendra des aléas historiques. Des hasards historiques tels que ce qui a été publié précisément et quand ; et laquelle de ces choses a déjà été trouvée. Lesquelles n'ont pas été perdues, les dates précises, etc. Beaucoup d'aléas historiques définissent si un brevet est valide. En fait, c'est une chose bizarre que le brevet de British Telecom pour suivre les hyperliens avec un accès téléphonique, ait été demandé en 1975, je pense. Je pense que c'est en 1974 que j'ai développé le paquetage «info» pour la première fois. Le paquetage «info» vous permet de traverser les hyperliens et les gens utilisaient des téléphones pour appeler et accéder au système. Donc en fait, j'ai produit quelque chose d'antérieur pour ce brevet. C'est donc la deuxième idée brevetable que j'ai eu dans ma vie, mais je ne pense pas avoir une preuve de cela. Je ne pensais que c'était suffisamment intéressant pour le publier. Après tout, j'ai eu l'idée de suivre les hyperliens suite à une démo de l'éditeur de Engelbart. C'était lui qui avait une idée intéressante à publier. J'ai appelé ce que j'ai fait «l'hypertexte du pauvre» car j'avais à le mettre en œuvre dans le contexte de TECO. Ce n'était pas aussi puissant que son hypertexte mais c'était au moins utile pour naviguer dans la documentation, ce qui était le but, et pour ce qui est des accès téléphoniques, et bien, il y en avait, mais il ne m'est pas venu à l'esprit que cela avait quelque chose à voir avec le reste. Je n'allais publier un papier disant : «Oh! J'ai mis en œuvre cet hypertexte du pauvre, et devinez quoi! Il y a aussi des lignes téléphoniques sur l'ordinateur!». Je suppose que je n'ai aucun moyen de dire précisément à quelle date j'ai mis en œuvre ceci. Et était-ce publié d'une manière ou d'une autre ? Bien, nous avons invité des gens à venir à travers ARPAnet et à se connecter sur notre machine, pour qu'il puissent naviguer dans la documentation en utilisant «info» et voir la chose. S'ils nous l'avaient demandé, ils auraient trouvé que nous avions un accès téléphonique. Mais comme vous pouvez le voir, le hasard historique détermine si vous avez l'antériorité sur l'invention.

Maintenant, bien sûr, il y a une publication faite par Engelbart sur l'hypertexte qu'ils vont produire. Je ne pense pas que cela dise quoi que ce soit sur le fait d'avoir une connexion téléphonique sur l'ordinateur cependant, donc cela suffira-t-il, ce n'est pas clair. La possibilité d'aller en justice pour invalider le brevet est donc un choix.

À cause de la dépense, c'est souvent hors de question même si vous pouvez trouver quelque solide réalisation antérieure qui serait suffisante pour invalider le brevet. En conséquence, un brevet invalide, c'est-à-dire un brevet qui n'aurait pas dû exister (mais en fait c'est le cas pour beaucoup d'entre eux) est une arme dangereuse. Si quelqu'un vous attaque avec un brevet invalide, cela peut vraiment vous causer beaucoup de problèmes. Vous pourriez être capable de vous sortir d'affaire en les bluffant en leur montrant la réalisation antérieure. Cela dépend s'ils peuvent être effrayés de cette manière ou ils pourraient penser «Bien, vous bluffez, nous pensons que vous ne pouvez pas vraiment vous permettre d'aller en justice, donc nous vous poursuivrons en justice de toute façon».

Vous pouvez quelquefois réussir à utiliser ces trois possibilités, mais souvent, ce n'est pas le cas. Alors vous devez affronter brevet après brevet après brevet. Chaque fois, vous pouvez être en mesure d'utiliser une des trois possibilités, mais alors il y a un autre brevet puis un autre et un autre. C'est comme traverser un champ de mines. Chaque pas que vous faites, chaque décision de conception ne tombera probablement pas sur un brevet, vous pouvez alors avancer de quelques pas et il n'y aura probablement pas d'explosion. Mais la probabilité que vous avez de marcher au travers du champ de mines et de développer le programme que vous voulez sans tomber sur un brevet s'amenuisera au fur et à mesure que le programme grossit.

Les gens ont l'habitude de me dire «Bien, il y a des brevets dans d'autres domaines, pourquoi le logiciel devrait être exempté?». Remarquez la bizarre supposition qui dit que d'une manière ou d'une autre, nous sommes tous supposés souffrir du système des brevets. C'est comme de dire «Des gens ont le cancer. Pourquoi ne l'auriez-vous pas?». De mon point de vue, chaque personne qui n'a pas le cancer est dans une bonne situation. Mais il y a derrière cela une question moins trompeuse, qui est une bonne question : «Le logiciel est-il différent des autres domaines ? La politique des brevets devrait-elle être différente pour différents domaines ? Si oui, pourquoi ?

Laissez-moi répondre à cette question : les brevets traitent des différents champs différemment car dans des domaines très variés les brevets traitent des produits différemment.

D'un côté nous avons des produits pharmaceutiques où une formule chimique donnée serait brevetée, et donc le brevet ne couvre qu'un seul produit. D'autres produits ne seraient donc pas couverts par le brevet existant. S'il devait y avoir un brevet pour ce nouveau produit, le détenteur du brevet serait celui qui a développé le nouveau produit.

Cela cadre avec l'idée naïve que dans le système de brevets que nous avons, si vous développez un nouveau produit, vous obtiendrez « Le Brevet ». L'idée qu'il y a un brevet par produit et qu'il couvre l'idée de ce produit. Dans certains domaines, c'est presque vrai. Dans d'autres, c'est loin d'être vrai, car les paquetages logiciels sont habituellement très gros. Ils utilisent beaucoup d'idées différentes dans une nouvelle combinaison. Si le programme est nouveau et pas seulement une copie, alors il est probable qu'il utilise une combinaison différente d'idées associées bien sûr à du code nouvellement écrit, parce que vous ne pouvez pas lancer comme ça des idées et comme par magie les voir fonctionner. Vous avez à les mettre en œuvre toutes. Vous devrez les mettre en œuvre toutes dans cette combinaison. Le résultat en est que même si vous écrivez un programme, vous utilisez beaucoup d'idées différentes n'importe laquelle d'entre elles pourrait avoir été brevetée par quelqu'un. L'association de deux peut avoir été brevetée en tant que combinaison par quelqu'un. Il pourrait y avoir plusieurs façons différentes de décrire une idée qui pourrait être brevetée par diverses personnes. Donc il y a probablement des milliers de choses, des milliers de points de vulnérabilité dans votre programme, qui pourraient déjà être brevetées par quelqu'un d'autre. C'est pourquoi les brevets logiciels tendent à empêcher le progrès dans les logiciels -- le travail de développement de logiciels. S'il y avait un brevet pour un produit, alors ces brevets n'empêcheraient pas le développement de produits car si vous avez développé un nouveau produit, il ne sera pas déjà breveté par quelqu'un d'autre. Mais quand un produit correspond à l'association de beaucoup d'idées différentes, il est très probable que votre nouveau produit soit déjà breveté par quelqu'un d'autre. En fait, il y a une étude économique qui montre que d'imposer un système de brevets sur un domaine où l'innovation est incrémentale, peut retarder le progrès. Les partisans des brevets logiciels disent : « Oui, il peut y avoir des problèmes mais le plus important, c'est que les brevets doivent promouvoir l'innovation et c'est si important que peu importe les problèmes qu'ils causent ». Bien sûr, ils ne disent pas ça très fort car c'est ridicule mais implicitement ils veulent que vous croyez que tant que les brevets promeuvent le progrès, cela surpasse tous les coûts. Mais en fait, il n'y a aucune raison de croire que les brevets participent au progrès. Nous avons maintenant un modèle qui montrent précisément comment les brevets peuvent retarder le progrès. Les cas où ce modèle peut s'appliquer correspond très bien au domaine du logiciel  innovation incrémentale.

Pourquoi le logiciel est-il sur cette extrémité du spectre ? La raison est que dans le logiciel nous développons des objets mathématiques idéalisés. Vous pouvez bâtir un château compliqué et le faire reposer sur une ligne ténue et il restera debout car il ne pèse rien. Dans d'autres domaines, les gens doivent composer avec la perversité de la matière -- des objets physiques. La matière fait ce qu'elle doit faire. Vous pouvez essayer de la modeler et si son comportement de fait ne s'ajuste pas au modèle alors c'est dur pour vous, car le défi est de réaliser des objets physiques qui fonctionnent vraiment.

Si je voulais mettre une déclaration « If » dans une déclaration « While », je n'ai pas besoin de me soucier de savoir si la déclaration « If » oscillera à une certaine fréquence et entrera finalement en résonnance pour se fissurer. Je n'ai pas besoin de me soucier de savoir si elle oscillera à une certaine haute fréquence et induira un signal dans la valeur d'una autre variable. Je n'ai pas besoin de savoir combien de courant cette déclaration « If » consommera et si elle peut dissiper la chaleur à l'intérieur de cette déclaration « While ». Ou s'il y aura une chute de tension dans la déclaration « While » qui fera que la déclaration « If » ne fonctionnera pas. Je n'ai pas besoin de me soucier si j'exécute ce programme dans un environnement d'eau salée que l'eau salée s'infiltrera entre la déclaration « If » et la déclaration « While » et provoquera une corrosion. Je n'ai pas besoin de me soucier quand je me réfère à la valeur d'une variable si j'excède la limite de ventilation en m'y référant 20 fois. Je n'ai pas besoin de me soucier, quand je me réfère à la variable, de la capacitance qu'elle a et s'il y a eu suffisamment de temps pour charger la valeur. Je n'ai pas besoin de me soucier quand j'écris un programme de savoir comment je vais assembler physiquement chaque copie et si je peux réussir à obtenir un accès pour mettre cette déclaration « If » dans la déclaration « While ». Je n'ai pas besoin de me soucier sur la façon d'avoir un accès au cas où la déclaration « If » se casse, pour la supprimer et la remplacer par une nouvelle. Il y a tant de problèmes dont nous n'avons pas à nous soucier dans le logiciel. Cela rend le logiciel fondamentalement plus facile. Il est beaucoup plus facile d'écrire un programme que de concevoir un objet physique qui doit fonctionner. Cela peut sembler étrange car vous avez probablement entendu des gens dire combien il était difficile de concevoir un logiciel et que c'était un gros problème et la façon dont ils allaient résoudre cela. Ils ne parlent pas vraiement de la même chose que moi. Je compare des systèmes physiques et logiciels de même complexité, de même nombre de parties. Je dis qu'un système logiciel est bien plus facile à concevoir qu'un système physique. Mais l'intelligence des gens dans ces divers domaines est la même, alors que faisons-nous quand nous sommes confrontés à un domaine facile ? Nous allons encore plus loin ! Nous poussons nos capacités à leurs limites. Si des systèmes de même taille sont simples, faisons alors des systèmes dix fois plus gros, alors ce sera difficile ! C'est ce que nous faisons ! Nous faisons des systèmes logiciels qui sont bien plus grands, en termes de nombre d'éléments que les systèmes physiques. Un système physique dont la conception recèle un million d'éléments différents est un méga projet. Un programme d'ordinateur dont la conception recèle un million d'éléments, fait peut-être 300000 lignes, quelques personnes écriront cela en deux ans. Ce n'est pas un programme particulièrement imposant. Je pense que GNU Emacs a maintenant quelques millions d'éléments dans sa conception. Il fait un million de lignes de code. C'est un projet réalisé essentiellement sans fonds, écrit pour la plupart par des personnes sur leur temps libre.

C'est une autre grosse source d'économie. Si vous avez conçu un produit matériel, la chose suivante que vous devrez faire est de concevoir l'usine pour le fabriquer. Construire cette usine peut coûter des millions ou des dizaines de millions là où la copie du programme ne coûte que de taper « copy ». la même commande copy copiera n'importe quel programme. Vous voulez des copies sur CD, très bien. Vous gravez un CD master et vous l'envoyez à une usine de gravage de CD. Ils utiliseront le même équipement qui copiera n'importe quel contenu sur un CD. Vous n'avez pas besoin de bâtir une usine pour fabriquer ce produit. Il y a une énorme simplification et une énorme réduction des coûts. Le résultat est, disons pour une société automobile : elle dépensera 50 millions de dollars pour bâtir l'usine, pour fabriquer un nouveau modèle de voiture, pour engager des avocats qui s'occuperont des négociations sur les licences de brevets. Ils peuvent même faire face à un procès s'ils le voulaient. Concevoir un programme de même complexité peut coûter 50000 ou 100000 dollars. En comparaison, le coût pour traiter avec le système de brevets est écrasant. En fait, concevoir un programme de la même complexité que la conception mécanique d'une voiture prend probablement un mois. Combien d'éléments contient une voiture, qui ne contient pas d'ordinateur [1]. Il n'y a pas tant d'éléments que cela. Cela ne veut pas dire que concevoir une bonne voiture est simple mais juste qu'elle ne recèle pas tant d'éléments différents que cela.

Le logiciel est vraiment différent des autres domaines car nous travaillons sur des objets mathématiques, dont la conception est bien, bien plus facile, ce qui a pour résultat que nous faisons des systèmes qui sont bien, bien plus grands et avec juste quelques personnes. Le résultat est qu'avec le système de brevets, au lieu d'être proche d'un produit égale un brevet, nous sommes dans un système ou un produit met en jeu vraiment beaucoup d'idées qui pourraient déjà être brevetées.

La meilleure façon de l'expliquer est par analogie avec les symphonies. Une symphonie est également longue et contient beaucoup de notes, et elle utilise probablement beaucoup d'idées musicales. Imaginez si les gouvernements d'Europe dans les années 1700 avaient décidé de promouvoir la musique symphonique en établissant un Office européen des brevets musicaux qui aurait donné des brevets pour toutes sortes d'idées musicales qui pourraient se décliner en mots. Imaginez-vous alors aux environs de 1800, vous êtes Beethoven et vous voulez écrire une symphonie. Vous trouverez alors qu'écrire votre symphonie de sorte qu'elle ne viole pas de brevets deviendra plus difficile que d'écrire une bonne symphonie. Quand vous vous en plaindrez, les détenteurs de brevets vous diront : « Ah Beethoven, vous rouspétez car vous n'avez pas d'idées personnelles. Tout ce que vous voulez, c'est piquer nos inventions ». Beethoven avait beaucoup de nouvelles idées musicales mais il a dû utiliser beaucoup d'idées existantes pour faire une musique reconnaissable, afin de faire de la musique que les auditeurs puissent aimer, et qu'ils reconnaissent comme musique. Personne n'est si brillant qu'il puisse réinventer la musique et faire quelque chose que les gens voudraient écouter. Pierre Boulez disait qu'il essaierait de le faire, mais qui écoute Pierre Boulez ? Personne n'est si brillant qu'il puisse réinventer l'informatique totalement. S'il le faisait, il ferait quelque chose que les utilisateurs trouveraient si étrange qu'ils ne voudraient pas l'utiliser. Si vous regardez un traitement de texte aujourd'hui, vous trouverez, je pense, des centaines de fonctionnalités différentes. Si vous développez un joli traitement de texte innovant, cela signifie qu'il y a de nouvelles idées dedans, mais il doit y avoir aussi des centaines d'idées anciennes aussi. Si vous n'avez pas le droit de les utiliser, vous ne pouvez pas faire de traitement de texte innovant.

Parce que le travail de développement est si conséquent, nous n'avons pas besoin besoin de plan artificiel pour inciter à trouver de nouvelles idées. Vous avez juste des gens qui écrivent des logiciels et ils auront de nouvelles idées. Si vous voulez écrire un programme et que vous voulez qu'il soit bon, alors des idées vous viendront et vous trouverez un moyen de les utiliser. Ce qui se passait, car j'étais dans le domaine logiciel avant qu'il y ait les brevets logiciels, c'était que la plupart des développeurs publiaient toute nouvelle idée qu'ils jugeaient importante, dont ils pensaient qu'ils pourraient retirer un certain crédit ou respect. Les idées mineures ou pas assez importantes n'étaient pas publiées car cela aurait été stupide. Maintenant, le système de brevets est supposé encourager la divulgation de idées. En fait, auparavant, personne ne gardait les idées secrètes. Ils gardaient le code secret, c'est vrai. Le code, après tout, représentait la majeure partie du travail. Ils gardaient le code secret et publiaient les idées, de sorte que les employés obtiennent quelque crédit et soient satisfaits. Après les brevets logiciels, ils gardent toujours le code secret et ont breveté les idées, donc, en fait, la divulgation n'a pas été encouragée dans un quelconque sens pertinent.

Les mêmes choses sont gardées secrètes maintenant comme c'était le cas auparavant, mais les idées qui étaient publiées de sorte que l'on puisse les utiliser sont maintenant brevetées et hors d'atteinte pendant 20 ans. Que peut faire un pays pour changer cela ? Comment peut-on changer la politique pour résoudre ce problèmes ?

Il y a deux points que vous pouvez attaquer. L'un est l'endroit où sont demandés et accordés les brevets, à l'office des brevets. L'autre, c'est quand les brevets ont été appliqués -- c'est-à-dire, la question de ce que le brevet couvre.

Changer le critère pour accorder les brevets ou simplement conserver un bon critère, peut fonctionner dans un pays qui n'a pas autorisé les brevets logiciels auparavant, par exemple, en grande partie, en Europe. Simplement pour clairement faire respecter les règles de l'Office européen des brevets qui dit que le logiciel n'est pas brevetable. C'est une bonne solution pour l'Europe. L'Europe est en train d'examiner une directive sur les brevets logiciels. Je suppose que le directive est peut-être plus étendue que cela mais une de ses importantes implications concernent les brevets logiciels. Simplement en modifiant ceci pour dire que les idées logicielles ne peuvent pas être brevetables préservera l'Europe de ce problème en grande partie, exceptés quelques pays qui ont pu reconnaître le problème de leur côté. Malheureusement, l'un d'eux est le Royaume-Uni. Malheureusement pour vous.

Cette approche ne fonctionnerait pas aux États-Unis. La raison est que les États-Unis ont déjà un grand nombre de brevets logiciels et que tout changement dans le critère de délivrance de brevet ne débarassera pas des brevets existants [2]. En fait ces brevets ne sont pas officiellement étiquetés comme brevets logiciels. Je dis brevets logiciels mais qu'est-ce que je veux réellement dire ? Des brevets qui peuvent potentiellement s'appliquer aux logiciels. Des brevets qui pourraient potentiellement vous faire poursuivre en justice pour avoir écrit un logiciel. L'office des brevets ne divise pas les brevets logiciels d'un côté et les autres de l'autre. Donc, il est concevable que tout brevet pourrait vous amener devant le tribunal pour avoir écrit un logiciel s'il pouvait s'appliquer au domaine du logiciel. Aussi, aux États-Unis, la solution passerait par un changement de la demande de brevet, l'étendue du brevet précisant qu'une pure mise en œuvre logicielle exécutée sur un ordinateur universel qui n'enfreint pas en soi de brevet, n'est pas couverte par un brevet et vous ne pouvez pas être poursuivi pour cela. C'est l'autre type de solution.

Le premier type de solution, la solution qui opère sur les types de brevets qui sont valides est une bonne solution à utiliser pour l'Europe.

Quand les États-Unis ont commencé à avoir des brevets logiciels, il n'y a pas eu de débat politique. En fait, personne ne l'a remarqué. Dans le domaine du logiciel, pour la plupart, personne ne l'a même remarqué. Il y a eu une décision de la Cour suprême en 1981 qui traitait d'un brevet sur un processus de vulcanisation de caoutchouc. Le jugement disait que le fait que l'appareillage incluait un ordinateur et un programme comme partie intégrante du processus pour vulcaniser le caoutchouc ne le rendait pas non brevetable. La Cour d'appel l'année suivante qui examine tous les cas de brevets annula les restrictions. Elle dit que les fait qu'il y ait un ordinateur et un programme inclus le rendait brevetable. Le fait qu'il y ait un ordinateur et un programme dans n'importe quoi le rendait brevetable. C'est pourquoi les États-Unis ont commencé à avoir des brevets sur les procédés commerciaux. C'est pourquoi les procédés commerciaux furent exécutés sur ordinateur et que cela les rendaient brevetables. Donc, cette décision était rendue et je pense que le brevet sur le recalcul en ordre naturel était le premier ou avait pu être le premier. Pendant les années 1980, nous ne savions pas cela.

C'est aux environs de 1990 que les développeurs aux États-Unis ont commencé à être conscients qu'ils affrontaient un danger avec les brevets logiciels. J'ai donc vu comment fonctionnait l'informatique avant et après. Je n'ai pas vu une accélération particulière après 1990. Il n'y avait pas de débat politique aux États-Unis, mais en Europe, il y a eu un grand débat politique. Plusieurs années auparavant, il y avait eu un effort pour amender le Traité de Munich qui établissait le Office européen des brevets. Il y avait une clause disant que le logiciel n'était pas brevetable. L'effort consistait à amender cela pour autoriser les brevets logiciels. Mais la communauté s'en aperçut. Ce furent en fait les développeurs et les utilisateurs de logiciel libres qui prirent la tête de l'opposition.

Nous ne sommes pas les seuls menacés par les brevets logiciels. Tous les développeurs de logiciels sont menacés par les brevets logiciels et même les utilisateurs. Par exemple, Paul Heckel, quand Apple n'avait pas très peur de ses menaces, menaça de commencer à poursuivre les clients d'Apple. Apple eut très peur. Ils ont pensé qu'ils ne pouvaient pas se permettre de voir leurs clients poursuivis comme cela, même si en fin de compte, ils auraient gagné. Donc, les utilisateurs peuvent être poursuivis aussi, soit comme un moyen d'attaquer un développeur ou comme un moyen de leur extorquer de l'argent soit pour semer la pagaille.

Tous les développeurs et les utilisateurs de logiciels sont vulnérables. Mais ce fut la communauté du logiciel libre en Europe qui prit la tête de l'organisation de l'opposition. En fait, par deux fois maintenant, les pays qui dirigent l'Office européen des brevets ont voté pour ne pas amender le traité. Alors la Commission européenne s'en mêla et les Commissions parlementaires étaient divisées sur le problème.

Celle dont le travail est de promouvoir le logiciel est contre les brevets logiciels semble-t-il. Ils n'étaient pas en charge de ce problème. C'est la Commission parlementaire juridique et du marché intérieur qui est en charge de cela et qui est menée par une personne qui est en faveur des brevets logiciels. En fait, ils ont ignoré l'opinion publique qui s'était exprimée. Ils ont proposé une directive pour autoriser les brevets logiciels [3]. Le gouvernement français a déjà dit qu'il était contre. Les gens qui travaillent dans les divers autres gouvernements s'opposent aux brevets logiciels et il est vital de commencer à faire la même chose ici.

Selon Hartmut Pilch, qui est un des leaders dans la bataille européenne contre les brevets logiciels, l'élan principal provient de l'Office britannique des brevets. L'Office britannique des brevets est tout simplement partial en faveur des brevets logicels. Il a eu une consultation publique et la plupart des réponses étaient opposées aux brevets logiciels. Ils ont ensuite écrit un rapport disant que les gens semblaient en être satisfaits, ignorant complètement les réponses. Vous voyez, la communauté du logiciel libre leur a demandé de leur envoyer les réponses ainsi qu'à eux, pour qu'ils puissent les publier. Ils ont alors publié ces réponses qui étaient généralement opposées. Vous n'auriez jamais pu deviner que le rapport que l'Office britannique des brevets a publié en était tiré.

Ils (l'Office britannique des brevets et des marques) utilisent un terme qu'ils appellent effet technique. C'est un terme que l'on peut étirer énormément. Vous êtes supposé penser que cela signifie qu'une idée de programme ne serait brevetable que si elle se rapporte étroitement à des activités physiques spécifiques. Si c'est l'interprétation, cela résoudrait en grande partie le problème. Si les seules idées logicielles qui peuvent être brevetées étaient celles qui sont vraiment reliées à une technique particulière un résultat physique spécifique que vous auriez pu breveter si vous n'aviez pas utilisé de programme, ce serait OK. Le problème, c'est que vous pouvez étirer ce terme. Vous pouvez décrire le résultat que vos obtenez en exécutant un programme comme résultat physique. En quoi ce résultat physique diffère de tout autre ? Eh bien, c'est le résultat de ce calcul. Ce qui en résulte, c'est que l'Office britannique des brevets propose quelque chose qui semble mener à resoudre presque tout le problème et qui donne vraiment carte blanche pour breveter pratiquement tout.

Les personnes dans le même ministère sont également impliquées dans le problème du droit d'auteur, qui n'a vraiment rien à voir avec les brevets logiciels excepté qu'il est traité par les mêmes personnes. C'est une question d'interprétation d'une récente directive européenne sur le copyright, une loi horrible comme la Digital Millennium Copyright Act aux États-Unis. Mais il y a une certaine latitude pour les pays pour décider comment la mettre en œuvre. Le Royaume-Uni propose le moyen le plus draconien pour mettre en œuvre cette directive. Vous pourriez grandement réduire le mal qu'elle fait en la mettant en œuvre proprement. Le Royaume-Uni veut maximiser l'effet tyrannique de cette directive. Il semble qu'il y ait un certain groupe, le Ministère du commerce et de l'industrie, qui a besoin de tirer les rênes. Il est nécessaire de vérifier leur activité, de les empêcher de créer de nouvelles formes de pouvoir.

Les brevets logiciels attachent chaque développeur et chaque utilisateur de logiciel dans une nouvelle forme de bureaucratie. Si les sociétés qui utilisent des ordinateurs réalisaient tous les ennuis que cela peut leur causer, ils partiraient en guerre et je suis sûr qu'ils peuvent l'arrêter. Les sociétés n'aiment pas être retenues dans la bureaucratie.

Quelquefois, bien sûr, cela sert une cause importante. Il y a certains domaines où nous souhaitons que le gouvernement britannique fasse un travail plus attentif en appliquant la bureaucratie avec certaines sociétés, comme lorsqu'il s'agit de l'importation d'animaux [4]. Mais dans certains cas, cela ne sert aucune cause sauf de créer des monopoles artificiels de sorte que quelqu'un puisse interférer dans le développement logiciel, extorquer de l'argent aux développeurs et aux utilisateurs, et là, nous devons alors le rejeter.

Nous devons rendre les directions conscientes de ce que peuvent faire les brevets logiciels. Obtenez leur soutien en combattant les brevets logiciels en Europe.

La bataille n'est pas finie. Elle peut encore être gagnée.

Notes

  1. Il y a approximativement 300 à 400 pièces uniques dans une transmission automatique et une transmission est généralement le composant le plus compliqué dans une auto. Concevoir une transmission peut prendre de six mois à un an et cela peut même prendre en fait plus de temps pour la faire construire et fonctionner. Cependant, un programme avec 500 à 600 parties fonctionnelles a environ 200 à 300 lignes de code et cela ne prendrait à un bon programmeur que d'un jour à une semaine pour écrire, tester et déboguer.
  2. Je dis « brevets logiciels » mais qu'est-ce que je veux réellement dire ? L'Office américain des brevets ne sépare pas officiellement les brevets logiciels des autres brevets. Donc en fait, tout brevet pourrait vous valoir des poursuites pour avoir écrit du logiciel s'il peut s'appliquer à un logiciel. Les brevets logiciels sont des brevets qui peuvent s'appliquer potentiellement à du logiciel, des brevets qui peuvent potentiellement vous valoir des poursuites pour avoir écrit du logiciel.
  3. Le 6 juillet 2005, le Parlement européen a rejeté la directive sur les brevets logiciels par 648 voix sur 680. Cependant, nous ne devons pas oublier le problème des brevets logiciels car ceux qui avaient fait pression pour ce brevetage essaient de ressusciter cette directive rejetée récemment. Nous devons aussi nous assurer que l'Office européen des brevets (EPO) et que les divers offices nationaux des différents pays européens arrêtent d'accorder des brevets pour des logiciels intégrés dans d'autres sortes d'inventions.
  4. Pour limiter la propagation de la fièvre aphteuse.

Cet essai est publié dans Free Software, Free Society: The Selected Essays of Richard M. Stallman.

Traductions de cette page