Quand on apprend pour la première fois qu'il existe un problème avec les brevets sur les logiciels, l'attention est souvent attirée par les exemples fallacieux : des brevets portant sur des techniques déjà fort bien connues. Ces techniques comprennent le tri d'un ensemble de formules de façon à ce qu'aucune variable ne soit utilisée avant d'être calculée (ce qu'on appelle «ordre naturel de recalcul» dans les «tableurs»), et l'utilisation du ou-exclusif pour la modification des contenus d'une image bitmap affichée.
La focalisation des gens sur ces exemples peut leur faire oublier le reste du problème. Ils sont attirés par la thèse selon laquelle le système de brevets est correct à la base et qu'il y a seulement besoin de «réformes» pour mener à bien ses propres règles.
Mais une implémentation correcte résoudrait-elle réellement le problème des brevets sur les logiciels? Prenons un exemple.
Au début des années 90 nous avions désespérément besoin d'un nouveau programme de compression, car le vieux programme standard de-facto «compress» nous avait été retiré par les brevets. En avril 1991, le développeur Ross Williams commença à publier une série de programmes de compression de données utilisant de nouveaux algorithmes de sa propre conception. Leur vitesse et la qualité de la compression supérieures attirèrent très vite les utilisateurs.
En septembre de la même année, quand la FSF fut à une semaine de la publication de l'un d'entre eux comme nouveau choix pour compresser nos fichiers de distribution, l'utilisation de ces programmes aux USA fut stoppée par un nouveau brevet sorti sous le numéro 5,049,881.
D'après les règles du système des brevets, l'autorisation pour le public d'utiliser ces programmes (c'est à dire le fait de savoir si le brevet est légal) dépend du fait qu'il existe un «travail antérieur» : soit la publication de l'idée de base avant «l'application» du brevet, qui a eu lieu en date du 18 juin 1990. La publication de William en avril 1991 vient après cette date et n'est donc pas pris en compte.
En 1988-1989, un étudiant décrivit un algorithme similaire dans un article de classe de l'Université de San Francisco, mais l'article ne fut pas publié. Ainsi, il ne peut être pris en compte comme «travail antérieur» selon les lois en vigueur.
Les réformes pour faire fonctionner le système des brevets «proprement» n'auraient pas empêché ce problème. D'après les règles du système de brevets, celui-ci semble valide. Il n'y a pas de «travail antérieur» le concernant. Il n'est pas proche d'un principe évident, au sens où le système des brevets interprète ce terme (comme la plupart des brevets, il n'est ni révolutionnaire ni trivial, mais quelque part entre les deux). L'anomalie se situe dans les règles elles-mêmes et non pas dans leur mise en application.
Dans le système juridique des États-Unis d'Amérique, les brevets sont conçus comme un marché passé entre la société et les individus; la société est supposée obtenir un bénéfice à travers la révélation de techniques qui sinon ne seraient jamais dévoilées. Il est clair que la société n'a rien gagné en enregistrant le brevet numéro 5,049,881. Cette technique allait être révélée de toutes façons. C'était suffisamment facile à découvrir pour que plusieurs personnes l'aient fait à peu près en même temps.
D'après les lois en vigueur, notre capacité à utiliser les programmes de William dépend du fait que des personnes aient publié la même idée par hasard avant le 18 juin 1990. Ce qui revient à dire que cela dépend de la chance. Ce système est bon pour la promotion de la pratique du droit, mais pas pour le progrès des logiciels.
Apprendre à l'Office des brevets à examiner plus largement l'existence de «travaux antérieurs» permettrait d'éviter des erreurs excessives. Cela ne sera pas le remède à un problème plus grave, qui est celui du dépôt de brevet pour toute nouvelle petite ride à la surface de l'informatique, comme pour celle que William et d'autres ont développé indépendamment.
Ceci transformera le logiciel en mare de boue. Même un programme innovant utilise typiquement des dizaines de techniques et de caractéristiques qui ne sont pas vraiment nouvelles, chacunes d'elles ayant pu être déjà brevetées. Notre capacité à utiliser chaque petite ride va dépendre de la chance, et si nous n'avons pas de chance la moitié du temps, vraiment très peu de logiciels échapperont à l'infraction envers un grand nombre de brevets. Naviguer dans le dédale des brevets sera plus difficile que d'écrire des logiciels. Comme le dit The Economist, les brevets logiciels sont tout simplement mauvais pour les affaires.
Il y a un effort important en Europe pour stopper les brevets logiciels. Veuillez soutenir cette pétition pour une Europe sans brevets logiciels, et consulter le site Web de la FFII pour obtenir plus de détails sur ce que vous pouvez faire pour aider.