Une réforme des brevets n'est pas suffisante

Lorsque les gens apprennent que les brevets logiciels posent problème, on attire souvent leur attention sur des exemples particulièrement choquants : 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 des 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 brevet nouvellement émis, 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 la demande de brevet, qui en l'occurrence datait du 18 juin 1990. La publication de Williams, en avril 1991, venait après cette date et n'a donc pas été prise en compte.

En 1988-1989, un étudiant de l'Université de San Francisco avait décrit un algorithme similaire dans un mémoire, mais ce travail n'avait pas été publié. Ainsi, il ne compte pas en tant qu'état antérieur de la technique/recherche, 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 en vigueur, ce brevet semble valide : la recherche d'antériorité n'a rien trouvé, et le brevet est loin d'être « évident » au sens où le système interprète ce terme (comme la plupart des brevets, il n'est ni révolutionnaire ni trivial, mais quelque part entre les deux). La faille se situe dans les règles elles-mêmes et non pas dans leur mise en application.

En droit américain, les brevets sont prévus comme un marché passé entre la société et les individus ; la société est censée gagner quelque chose à 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 actuelles, 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 le problème majeur, qui est celui de délivrer un brevet pour chaque nouvelle petite vague à la surface de l'informatique, comme celle que Williams et d'autres avaient 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 fonctionnalités qui ne sont pas vraiment nouvelles, chacune pouvant être déjà brevetée. Notre capacité à utiliser chaque petite vague va dépendre du hasard, 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.

Ce que vous pouvez faire pour aider

Il y a un effort important en Europe pour stopper les brevets logiciels. Consultez le site web de la FFII pour obtenir plus de détails sur ce que vous pouvez faire pour aider.