Accueil > Brevets logiciels > Analyses générales > Boucliers communs contre les brevets logiciels

Boucliers communs contre les brevets logiciels

vendredi 8 avril 2005, par Thibault Gironnay (cabugs)

Construire un portefeuille de brevets est une option difficilement réalisable pour la défense de la communauté du logiciel libre/opensource. Cependant cette communauté a une certaine chance d’utiliser l’état de l’art à son avantage, particulièrement si elle le fait de manière efficace et réalise le potentiel d’insécurité juridique inhérent au système des brevets logiciels. Une publication défensive, comme cela a été proposé dans des initiatives comme celle du Foresight Institute, apparaît cependant être une approche incroyablement idiote. La tâche la plus urgente en ce moment — printemps 2001 — est de sauvegarder toutes les archives CVS et toutes les listes de diffusion dans lesquelles des idées liées aux logiciels sont développées.

Sommaire

Peu d’espoirs dans une stratégie d’utilisation défensive des brevets

Obtenir et maintenir des brevets coûte cher :

coût de motivation : Les développeurs trouvent de nouvelles idées tous les jours et ne sont habituellement pas motivés pour faire ce travail fastidieux qui est d’appliquer ces idées en en tirant des brevets. Ils veulent développer des produits et non des brevets et n’apprécient en général pas du tout de breveter, pour différentes raisons. Même si les lois leur garantissent un partage des revenus provenant de ces brevets, ce n’est habituellement pas une motivation suffisante. Les grosses compagnies comme Siemens, IBM ou SAP ont donc mis en place des commissions d’experts en application des brevets et de grosses primes pour les développeurs afin de surmonter ce problème et fournir des motivations suffisantes pour développer les brevets.

coût d’obtention : D’après les chiffres de l’OEB, un brevet européen coûte en moyenne 30 000 € en taxes, sachant qu’il n’est valable que 10 ans et qu’il n’est pas transcrit dans toutes les langues européennes. Les prix des honoraires des avocats en brevets sont plus élevés et souvent calculés sur une base de 300 € par heure.

coût d’entretien : Même une simple action en justice contre une personne enfreignant un brevet ou un adversaire coûtera plus de 100 000 € en honoraires. Souvent le coût est dans la gamme des millions et beaucoup d’inventeurs, y compris pour des brevets portant sur des bases importantes, ont fait faillite dans ce système (ex. Goodyear). Les polices d’assurance pour les litiges dûs aux brevets sont soit inexistantes, soit extrêmement élevées.

Ces coûts peuvent rapporter par la suite en exerçant des droits monopolistes. Ceci passe habituellement par une combinaison d’un paiement d’avance (une somme forfaitaire) et d’un droit de licence unitaire. Le logiciel libre et la licence unitaire sont incompatibles. Ainsi, les coûts liés aux brevets doivent être remboursés par le paiement forfaitaire direct, ex. 1 million de dollars dans le cas du MP3. Il n’y a habituellement aucune chance de recevoir 1 million de quiconque en retour de la permission d’écrire un logiciel libre. Il y a cependant peut-être une chance de gagner de l’argent de la part des vendeurs de logiciels propriétaires. Toutefois, dans le meilleur des cas, ce revenu sera faible si vous accordez à la concurrence une licence libre pour l’utilisation du logiciel libre. Dans ces conditions, les chances d’utiliser des brevets pour défendre les logiciels libres sont vraiment minces, voire inexistantes.

De bons espoirs dans la guerre de l’état de l’art

Nous voyons que la nature propriétaire du jeu des brevets rend impossible pour les développeurs de logiciels libres d’organiser une légitime défense dans ce jeu. Cependant cette même nature propriétaire du système des brevets génère des faiblesses qui peuvent être exploitées. Le développement de logiciels libres produit le plus grand volume disponible d’art antérieur publié. Les idées sous-jacentes des logiciels libres tombent alors dans le domaine public accessible et tous les brevets obtenus dessus seront invalidés, si l’antériorité de l’art est prouvée.

Strictement parlant, ça n’empêchera personne de revendiquer un brevet trivial et de grande portée pour lequel aucun état de l’art n’existe, ceci ne change rien en ce qui concerne la source la plus importante de danger. Mais étant donné les difficultés de trouver un état de l’art antérieur et de savoir si le brevet est vraiment valide, un vaste arsenal d’état de l’art difficile à fouiller peut servir de bouclier de protection indirect pour toute la communauté du logiciel libre :

un grand ensemble de l’art qui est publié chaque jour dans un nombre énorme de lieux partout dans le monde ;
une insécurité juridique inhérente aux portefeuilles de brevets logiciels des acteurs principaux, causée par l’impossibilité de faire une recherche sérieuse dans l’état de l’art ;
une large communauté de développeurs de logiciels hautement compétents et courageux, capables d’actions concertées contre ceux qui attaquent le logiciel libre.

Dans ces conditions, la chose la plus urgente à faire est d’automatiser l’horodatage et de le fournir comme service de base dans toutes les archives majeures (CVS, listes de diffusion, HTTP etc) dans lesquelles sont mis au point les logiciels libres et les discussions relatives. Quand ce type de service n’est pas disponible, les développeurs doivent déplacer leurs discussions correspondantes et leurs publications sur Usenet, depuis qu’ils peuvent y trouver un assez fiable horodatage dans DejaNews (racheté depuis par google).

« Publication défensive », non merci !

La chose la plus stupide à faire pour les développeurs de logiciels libres serait de s’engager pour aider les offices de brevets à construire des bases de données de l’état de l’art « afin d’éviter les problèmes avec les faux brevets », comme cela a été proposé par le Foresight Institutes avec l’approbation de certains « leaders du mouvement open source ». Ce que l’on peut appeler « publication défensive » est un boomerang à la fois pour les développeurs qui l’expérimentent et pour la communauté. Démontrons cela en comparant la stratégie de « publication défensive » à la publication normale de l’état de l’art.

Publication défensive parfaite	Déroulement du processus normal de développement ouvert
Idées de brevet pertinent faciles à rechercher	Idées de brevet pertinent difficiles à trouver
Gros efforts et coûts pour le développeur, moins d’efforts pour le chercheur et le détenteur du brevet	Moins d’efforts et de coûts pour le développeur, plus d’efforts et de coûts pour le chercheur
Coûts réduits pour breveter, plus de brevets logiciels (de grande portée et triviaux)	Coûts plus élevés pour breveter, moins de brevets (de grande portée et triviaux)
Votre idée de logiciel ne sera probablement brevetée par personne	Votre idée de logiciel peut être brevetée par quelqu’un, mais ce propriétaire de brevet évitera tous les conflits avec vous et les autres développeurs de logiciels libres dès que vous lui aurez prouvé l’antériorité de votre art. Il deviendra très prudent même avec ces autres brevets, spécialement envers les développeurs de logiciels libres, car ils peuvent lui faire des torts incalculables. Il préférera garder des brevets invalides afin de rassurer ses investisseurs et de lever des fonds, plûtot que de réellement offenser quelqu’un. Dans certains cas il vous paiera même pour rester silencieux sur vos trouvailles.
Beaucoup d’opportunistes se rassembleront sur la base de données de « publication défensive » pour voir quelles idées peuvent donner des brevets pertinents et alors voir s’ils peuvent trouver des idées complémentaires pour breveter eux-mêmes. Ces brevets seront probablement valides. Votre champs d’action sera alors bloqué par des tas de brevets	Aucun opportuniste ne trouvera à temps les infomations sur votre art et vous garderez une tête d’avance, en ayant de bonnes chances de rendre étape par étape un champ entier d’idées libres de droit
Les offices de brevet peuvent paraître crédibles quand ils disent : « Regardez, nous avons fait notre travail de recherche dans l’état de l’art. Les développeurs de logiciels libres doivent arrêter de pleurnicher et s’adonner à la publication défensive. S’ils font leur boulot en fabricant des bases de données de l’état de l’art, alors nous ferons le notre en leur garantissant que leurs idées ne seront pas brevetées »	les offices de brevet doivent admettre que le probléme de l’exploitation de l’état de l’art antérieur dans les logiciels n’est pas “seulement une question de temps”

Le développement de l’horodatage du logiciel propriétaire aide aussi

Les développeurs de logiciels propriétaires doivent rendre leur travail reconstructible jour après jour, en utilisant les mêmes méthodes que les développeurs de logiciels libres.

Une telle archive historique de développement propriétaire ne constitue pas un état de l’art et ne peut donc pas servir à invalider directement le brevet. Mais il peut établir un « droit d’utilisation antérieure », signifiant que le développeur peut continuer à « vendre des produits basés sur cette idée ». Il ne peut cependant pas transférer ce droit à une tierce partie.

Jusqu’à présent ce qui arrive avec le droit d’utilisation antérieure quand le propriétaire d’un tel droit décide un jour de publier son logiciel propriétaire sous une license opensource n’est pas complètement clarifié. Est-ce que cela constitue un transfert du droit de « vendre le produit » ? Ou est-ce qu’aucun propriétaire de droit d’utilisation antérieure ne devrait être libre de « vendre » ses « produits » à ses « clients » de quelque manière que ce soit, en se basant sur le principe que ses clients n’ont pas à acquérir des licenses d’utilisation séparément. On peut voir ici que les hypothèses sous-jacentes au système des brevets ne concordent pas avec la réalité des produits des technologies de l’information.

Cependant, aussi longtemps qu’il n’y aura pas de verdict ayant l’effet opposé, nous avons de bonnes raisons d’espérer que l’utilisateur antérieur est libre de distribuer son travail en logiciel libre. Dans ce cas tout le monde est libre de contourner le brevet aussi longtemps qu’il met la suite du développement dans ce logiciel libre.

Ainsi l’utilisateur antérieur d’une idée brevetée liée à un logiciel a une position particulièrement inconfortable. Il peut soit rendre l’idée libre pour tout le monde, soit négocier une prime pour ne pas faire cela. Pour le public, le droit d’utilisation antérieur a divisé par deux la valeur réelle de l’état de l’art. Cette demi-valeur fait qu’il est intéressant pour les développeurs de logiciels propriétaires de diffuser au public leurs archives de développement au bout d’un certain temps. Ce jeu, s’il est joué efficacement, peut réduire significativement l’intérêt de breveter des innovations triviales pour lesquelles beaucoup d’utisations antérieures privées peuvent exister même si aucun art antérieur n’est trouvé.

Qu’est-ce qui doit être fait ?

Horodatage de tous les sites dédiés au développement, beaucoup de discussions publiques sur des idées de logiciels, traduites en plusieurs langues.
Documentation facile à comprendre pour le public des brevets logiciels que les détenteurs ou les licences exploitent de façon particulièrement abusive.
Formation de coopératives pour l’exploitation de l’état de l’art et l’acquisition de brevets logiciels défensifs pour autant que cela soit possible.
Continuellement influencer le public et les responsables politiques afin de réguler l’inflation de brevets et de rendre illégaux les brevets logiciels.

Lectures supplémentaires

Voir en ligne : Article original en anglais