Lorsque les gens apprennent que les brevets logiciels posent problème, on attire souvent leur attention sur des exemples classiques : des brevets portant sur des techniques déjà fort bien connues, par exemple le tri d'un ensemble de formules de façon qu'aucune variable ne soit utilisée avant d'être calculée (ce qu'on appelle le « recalcul en ordre naturel » dans les tableurs), et l'utilisation du ou-exclusif pour modifier le contenu d'un affichage bitmap.
Lorsque les gens se focalisent sur ces exemples, ils peuvent oublier le reste du problème. Ils sont amenés à penser que le système de brevets repose sur un principe juste et qu'il a seulement besoin de « réformes » pour appliquer ses propres règles convenablement.
Mais une mise en œuvre correcte résoudrait-elle vraiment le problème des brevets 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 standard de facto, le programme 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 leur qualité de 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 publier l'un d'entre eux comme alternative 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, le public est autorisé à utiliser ces programmes si le brevet est invalide, c'est-à-dire si l'idée qu'il couvre se retrouve dans « l'état antérieur de la technique » [prior art] ; autrement dit si l'idée de base a été publiée avant le dépôt de brevet, qui a eu lieu le 18 juin 1990. La publication de Williams en avril 1991 vient après cette date et n'est donc pas pris en compte.
En 1988-1989, un étudiant de l'université de San-Francisco a décrit un algorithme similaire dans un mémoire, mais l'article n'a pas été publié. Ainsi, il ne peut pas être pris en compte comme état antérieur de la technique selon les règles en vigueur.
Réformer le système des brevets pour le faire fonctionner correctement n'aurait pas évité ce problème. D'après les règles du système de brevets, celui-ci semble valide : il n'apparaît pas dans l'état antérieur de la technique, et il est loin d'être é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, les brevets sont conçus comme un marché passé entre la société et les individus ; la société est censé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 toute façon. C'était suffisamment facile à découvrir pour que plusieurs personnes l'aient fait à peu près en même temps.
D'après les règles en vigueur, notre capacité à utiliser les programmes de Williams repose sur la publication de la même idée avant le 18 juin 1990, ce qui revient à dire que cela dépend d'un coup de chance. Ce système est bon pour promouvoir la pratique du droit, mais pas pour faire progresser le logiciel.
Apprendre à l'Office des brevets à examiner plus soigneusement l'état antérieur de la technique permettrait d'éviter des erreurs grossières. Cela ne résoudra pas 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 celle que Williams et d'autres ont développée indépendamment.
Cela transformera le domaine du logiciel en bourbier. Même un programme innovant utilise typiquement des dizaines de techniques et de fonctionnalités qui ne sont pas vraiment nouvelles, chacune pouvant être déjà brevetée. Notre capacité à utiliser chaque petite ride va dépendre de la chance, et si la chance nous fait défaut la moitié du temps, peu de logiciels s'en sortiront sans enfreindre 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.