Association Bordelaise des Utilisateurs de Logiciels libres

Accueil ›› Enjeux de Societé ›› Brevets Logiciels ›› Articles ›› Analyse de la section « brevets logiciels » du rapport numéro 41 du Conseil (...)

Analyse de la section « brevets logiciels » du rapport numéro 41 du Conseil d’Analyse Économique sur la « Propriété Intellectuelle »

Posté le dimanche 19 octobre 2003 par François PELLEGRINI

Cette note analyse et apporte des éléments correctifs
à certains
points de la section traitant des brevets logiciels (pages 113 à
164)
du rapport numéro 41 du Conseil d’Analyse Économique sur
la
« Propriété
Intellectuelle » [1].

Elle réfute un certain nombre d’assertions contenues dans ce
rapport, sur lesquelles l’auteur du rapport se base pour justifier la
nécessité de légaliser la brevetabilité
logicielle, et démontre qu’il
faut au contraire rejeter la brevetabilité logicielle en Europe.

Remarques préliminaires

Tout d’abord, il convient de noter que cette partie du rapport est
ancienne ; alors que le rapport dans son ensemble est daté
du 11
juin 2003, ce qui laisserait à penser qu’il contient des
informations
à jour, la partie concernant les brevets logiciels est une
reprise
d’un document antérieur de M. Bernard CAILLAUD datant de
2001 [2]. De fait, ce
rapport ne mentionne pas
l’accumulation d’études économiques récentes
démontrant toutes la
nocivité des brevets logiciels [3],
ni ne fait part des critiques de plus en plus vives s’élevant
aux
États-Unis mêmes contre ces brevets [4,5].

Ensuite, si la toxicité économique des brevets logiciels
est très justement
décrite, il est assez surprenant de voir l’auteur du rapport
réaliser un
virage à 180 degrés pour finalement recommander la
légalisation de la
brevetabilité logicielle, en traitant certaines questions
critiques
sur le mode de l’assertion plutôt que de la démonstration
et des faits.
Les questions les plus sujettes à discussion sont listées
ci-dessous,
et notre contribution sur ces points a pour objet de montrer que le
débat
est loin d’être clos, ou bien doit l’être dans le sens
opposé à celui de
l’auteur du rapport.

Conséquences pratiques d’une extension de la brevetabilité sur... la communauté du logiciel libre

Pages 150-152.

La conclusion de cette section est surprenante. Selon l’auteur du
rapport, « Une certaine
complémentarité de marché existe
donc entre logiciels propriétaires et logiciel
libres
 », ce qui est vrai,
« qu’une
extension raisonnable de la brevetabilité à quelques
logiciels
propriétaires ne peut faire
disparaître
 ».

Tout d’abord, il serait intéressant que l’auteur du rapport
précise ce
qu’il entend par « raisonnable », alors que
justement les brevets logiciels ont été
délivrés et utilisés de façon
déraisonnable, et le seront toujours puisqu’ils n’ont justement
d’utilité que comme armes anti-concurrentielles. Ce voeu pieux,
qui
cadre mal avec la rigueur attendue d’un rapport destiné aux plus
hautes instances nationales, est qui plus est en totale contradiction
avec les prémices de ce même rapport, qui décrit
avec justesse les
risques induits par les brevets logiciels et l’impossibilité
pour les
offices de brevets, soumis aux amicales pressions de leurs clients,
d’être « raisonnables » dans l’attribution
des
brevets logiciels.


Ensuite, et ce qui est bien plus grave, le souhait d’une extension de
la brevetabilité « à quelques logiciels
propriétaires » traduit une méconnaissance
totale de la
portée réelle des brevets logiciels. Ce qu’un brevet
monopolise, ce
n’est pas un logiciel (ceci est le rôle du copyright/droit
d’auteur),
mais ses principes sous-jacents, c’est-à-dire les algorithmes
qu’il
implémente. Ainsi, tout brevet sur les algorithmes d’un logiciel
donné
monopolise ces algorithmes pour toute une classe de problèmes,
c’est à
dire un secteur économique entier. Notons de plus que pour
certains
brevets logiciels, tels celui sur la « barre de
progression » [6], le
secteur économique visé est celui de l’informatique
entière...

On voit mal, si de tels monopoles sectoriels sont accordés
à certains
logiciels, comment les logiciels libres (ou tout autre logiciel
propriétaire d’ailleurs) pourraient y faire jouer la concurrence
et
être les garants « d’une qualité
avérée pour des logiciels
profonds ou à haut degré de sophistication »
(page 152).

Cette phrase même montre le désir de cantonner les
logiciels libres à
quelques secteurs limités, quelques réserves indiennes
pourrait-on
dire, où ils seraient parqués et ne pourraient nuire aux
logiciels
propriétaires, même si ceux-ci sont surfacturés
ou de piètre qualité, lésant les consommateurs
dans leur ensemble.
Les promoteurs du logiciel libre apprécieront la grande estime
dans
laquelle l’auteur de ce rapport les tient.


Les raisons pour lesquelles le logiciel libre continue à se
développer
aux États-Unis malgré le très grand nombre des
brevets logiciels qui y
existent sont les suivantes.

D’abord, jusqu’à récemment, les logiciels libres n’ont
été massivement
utilisés que dans le cadre de services enfouis (serveurs de
noms,
routeurs, etc), peu visibles, et représentant un petit nombre
d’implantations. L’irruption de solutions logiciels libres
complètes
pour le grand public, empiétant sur des marchés juteux
tels que le
multimédia et les contenus, risque de faire changer cette
situation,
comme l’ont montré les attaques récentes contre les
personnes ayant
réalisé des logiciels de lecture de DVD sous
Linux [7] (cette affaire
est étonnante à plus d’un titre,
car toute personne a le droit de jouir librement des oeuvres qu’elle
achète et pour laquelle elle a payé des droits aux
auteurs [8] - mais
ceci est
un autre problème).

Ensuite, peu d’entreprises se risqueraient à attaquer
frontalement la
communauté du libre, par crainte de sa réaction, car
cette communauté
est très structurée, très mobilisable, et capable
de gagner une grande
sympathie vis-à-vis du public. Pour les grandes entreprises
capables
de mener de telles actions, le risque de publicité
défavorable est
très grand, et risque de faire basculer encore plus de clients
vers le
monde du libre, en lui offrant un capital de sympathie
supplémentaire.
Ceci n’a pas empêché quelques développeurs de
logiciels libres d’être
menacés de poursuites, le plus souvent par de moyennes
entreprises
disposant d’une niche économique et désireuses d’y
conserver leurs
monopoles, mais ces menaces ont été très
jusqu’à présent très limitées.

Parler de Microsoft comme d’une entreprise soucieuse de collaborer
avec le monde du libre (page 152) constitue un contresens, car
Microsoft justement est l’une des premières entreprises à
user des
brevets logiciels pour interdir aux logiciels libres d’interagir avec
ses propres produits, portant ainsi atteinte à
l’interopérabilité et à
la concurrence [9]. La
stratégie
de Microsoft, telle qu’énoncée par Bill Gates
lui-même [10], est au contraire d’utiliser les
brevets logiciels pour verrouiller son marché, et
également de lutter
contre les logiciels libres [11].


Il est donc légitime de penser, à la lumière de ce
qui précède, que
les brevets logiciels sont une menace réelle et sérieuse
contre les
logiciels libres. Savoir s’il est utile de préserver les
logiciels
libres est une autre question, aux répercussions
stratégiques elles
aussi considérables [12]. Nous
pensons que oui, justement pour ces raisons stratégiques, mais
cette
discussion sort du cadre de la présente note.

Conséquences pratiques d’une extension de la brevetabilité sur... les échanges internationaux et l’équilibre entre États-Unis et Europe

Pages 152-154.

Tout d’abord, il est surprenant de considérer comme caricatural
le
constat que les États-Unis accordent des brevets sur les
logiciels et
les méthodes commerciales. La doctrine de l’USPTO en la
matière est
d’ailleurs explicite « everything Man makes
under
the sun is patentable
 » [13], ce qui, outre les logiciels et les
méthodes
commerciales, a permis d’étendre le système des brevets
aux gènes, aux
plantes, etc., sans que le législateur étasunien ait pu
débattre de
l’opportunité de ces extensions. Le débat politique en
Europe autour
de la brevetabilité logicielle est en ce sens unique, et aura un
impact certain sur les politiques des autres nations [14].

L’omniprésence des brevets logiciels aux États-Unis est
un fait avéré,
largement commenté dans la presse [15,16], et ayant déjà
donné lieu à de nombreuses attaques en
contrefaçon [17,18], qui ne sont que
la partie émergée de l’iceberg car il est difficile de
connaître le
nombre de petites entreprises préférant négocier
de gré à gré des
licences sur de tels brevets logiciels plutôt que de se
défendre
devant les tribunaux.
En effet, l’entreprise qui souhaite se défendre contre ces
brevets
logiciels est en situation défavorable par rapport aux
entreprises
concurrentes du même marché, car elle seule aura à
supporter les frais
de justice qui bénéficieront à toutes, mais qui
pourraient mettre en
danger sa capacité de développement. C’est pourquoi ce
système
encourage les petites entreprises à obtempérer, et
à céder à ce qui
ressemble, par sa structure, à un système de racket. Qui
plus est,
le nombre de brevets contre lesquels se défendre est si
élevé qu’une
PME se défendant contre un brevet ne peut supporter les frais
d’autres
attaques.


D’autre part, il n’est pas exact de dire que la recherche et
développement logiciels se déplaceront
nécessairement vers la zone
étasunienne (page 153) parce que celle-ci offre un niveau de
protection plus élevé. Cette argumentation ne tient pas
pour
plusieurs raisons.

Premièrement, le nombre très élevé de
brevets logiciels aux
États-unis, sur des algorithmes et méthodes informatiques
basiques,
rendent le développement logciel hasardeux, car la
commercialisation
de tout logiciel peut être rendue économiquement
impossible par des
attaques en contrefaçon de brevets, pénalisantes surtout
pour les
PME.
Les brevets logiciels sont en fait un danger pour les
investisseurs [19]. Sans
brevets, tout investisseur est certain de pouvoir commercialiser les
logiciels qu’il a financé, et donc d’avoir un retour sur
investissement si ces produits trouvent un marché. Avec un
système de
brevets logiciels, tout logiciel économiquement valable est
attaquable, et le retour sur investissement est plus incertain. La
très récente étude exhaustive menée aux
États-Unis sur plus de 130.000
brevets logiciels et 1600 entreprises étasuniennes entre 1976 et
nos
jours a montré que les dépenses en brevets logiciels se
sont
substituées à plus de 10 % des dépenses de
R&D des entreprises, au
niveau global [3]. Lors d’auditions
de la
Federal Trade Commission sur le sujet, certains dirigeants
d’entreprises étasuniens ont même indiqué qu’ils
allaient consacrer
jusqu’à 35 % de leurs dépenses de R&D à se
constituer des
portefeuilles de brevets logiciels afin de tenter de se prémunir
contre des attaques en contrefaçon [4].
Dans ce contexte, il est légitime de penser que, parce que le
marché
permettant le meilleur retour sur investissement sera une Europe sans
brevets logiciels, les entreprises les plus à même d’y
réussir seront
les entreprises européennes, plus proches de leur clients, et
plus à
même de fournir les efforts de R&D nécessaires.
Toute entreprise
basant son développement logiciel aux États-Unis peut
faire l’objet
d’une attaque en contrefaçon sur la base des brevets logiciels
américains, puisque les développeurs codent, sciemment ou
non, des
algorithmes brevetés sur le sol étasunien. En revanche,
les
développeurs européens seront libres de réaliser
leurs logiciels sans
contraintes. Ainsi, une Europe sans brevets logiciels peut même
réussir
à attirer des entreprises étasuniennes soucieuses d’y
pérenniser leurs
développements, renversant le sens des flux migratoires des
informaticiens. Ceci cadre parfaitement avec l’exemple de la note
(65), page 153, du rapport, qui rendait perplexe son auteur. RedHat
n’a pu développer de modules cryptographiques parce qu’elle ne
pouvait
les exporter, et aurait dû baser son développement
logiciel en Europe
pour être en conformité avec les lois étasuniennes.

Deuxièmement, rien n’empêche une entreprise
européenne de
déposer des brevets aux États-Unis pour essayer
d’augmenter
ses chances de pénétrer ce marché. Cet
investissement est
minime en comparaison de celui à réaliser pour obtenir
des
brevets européens, et sans commune mesure avec le tribut
que les PME européennes devraient verser aux grandes
entreprises étasuniennes si les brevets logiciels étaient
légalisés en Europe.

Sur la durée de la protection accordée aux brevets logiciels

Page 156.

Il est étonnant pour un économiste de ne pas pouvoir
suggérer de durée
idéale pour la protection de l’innovation logicielle, alors que
ses
confrères ont pu, tout au long de l’histoire, proposer ces
durées dans
le domaine de la pharmacie et des industries lourdes. C’est d’ailleurs
du lobby de l’industrie pharmaceutique que provient la durée de
20 ans
inscrite dans les accords TRIPS, correspondant au temps de
développement et de mise sur le marché d’un nouveau
médicament.

En effet, si le brevet est censé protéger l’innovation
sans trop
perturber la concurrence, sa durée doit être
équivalente à celle
nécessaire aux innovateurs pour rentrer dans leurs frais de
recherche
et développement. Dans le monde du logiciel, la durée de
vie
commerciale d’un logiciel est de 18 mois en moyenne, pendant laquelle
non seulement l’innovateur peut se rembourser, mais encore engranger
de substantiels bénéfices. Ainsi, même pour un
produit aussi
lourd et coûteux que Windows, Microsoft arrive à produire
de nouvelles
versions ou des révisions majeures tous les deux ans en moyenne,
ce qui
montre la validité de ce chiffre. On comprend donc la gêne
de
l’auteur du rapport, car cette durée est inférieure de
loin au temps
nécessaire pour délivrer un brevet, qui est actuellement
de plus de six
ans à l’Office Européen des Brevets. ce qui
démontre incidemment
l’inadéquation complète entre le fonctionnement du
système du brevet
et le cycle du développement du logiciel.

C’est d’ailleurs du fait de cette inadéquation totale que les
brevets
logiciels sont utilisés pour privatiser des algorithmes et
concepts
triviaux, pusique le retour sur les frais de dépôt de
brevet ne peut
se faire que si les algorithmes en question continuent à
être utilisés
plus de dix ans après le dépôt du brevet, et le
sont par le plus grand
nombre de logiciels possible.


La référence aux logiciels embarqués pour
justifier de longues durées
de brevets est toute aussi malvenue. Ces logiciels enfouis étant
couplés à des dispositifs matériels, la protection
par brevet du
matériel suffit à protéger l’ensemble du
dispositif contre la
contrefaçon, à moins de vouloir empêcher
l’utilisation des algorithmes
brevetés en dehors de ce contexte matériel, ce qui
revient à accepter
de breveter le logiciel et les algorithmes « en tant que
tels », ce dont se défendent les offices de brevet,
bien
que cela soit effectivement leur objectif.

Au contraire, cet exemple montre bien qu’il convient de revenir aux
termes exacts de la Convention Européenne du Brevet de
1973 :
dans un dispositif mêlant matériel et logiciel, le
dispositif, en
tant que solution technique à un problème technique
(c’est-à-dire
faisant intervenir l’utilisation contrôlée de forces de la
nature),
est brevetable, mais le logiciel qu’il contient, en tant que tel,
ne peut être couvert par le brevet, car étant
immatériel et
équivalent à une preuve mathématique, qui est non
brevetable.

Que faire des brevets logiciels existants ?

Page 156.

Il est amusant de constater que l’auteur du rapport considère
qu’annuler tous les brevets logiciels existants, alors que ceux-ci
sont collectivement néfastes à l’innovation,
représenterait un
« message très négatif pour les
acteurs économiques
quant à la question des droits de propriété
intellectuelle futurs en
géneral, voire des droits de propriété tout
court !
 ».

L’impression donnée par cette phrase, l’une des rares de ce
rapport
comportant (quelle audace !) un point d’exclamation, est que si
l’on annulait ces brevets, des hordes révolutionnaires
dépenaillées,
incitées par tant de laxisme, viendraient dans les semaines
suivantes
piller l’argenterie de Grand-Maman.


On peut en revanche se demander quel signal représenterait, pour
les
entreprises réalisant ou utilisant du logiciel, le fait de
conserver
les près de 30.000 brevets logiciels triviaux déjà
délivrés, et dont
elles contrefont toutes plusieurs dizaines, les laissant à la
merci d’une
insécurité juridique découlant du fait que, selon
le bon vouloir de
tel ou tel tribunal, elles seraient déclarées coupables
ou non, avec
le risque de voir ces procédures s’éterniser en appel et
coûter des
sommes énormes en frais de justice et d’experts,
pénalisant à plus
d’un titre les contribuables et citoyens.

L’annulation pure et simple de ces brevets représente donc la
seule
solution juridiquement sûre, qui enverra aux investisseurs et aux
créateurs de logiciels innovants le signal fort qu’ils ne
pourront
être attaqués injustement sur la base de brevets logiciels
douteux. Il ne s’agit donc pas
d’« expropriation », terme ici encore
tendancieux, mais plutôt de faire respecter la loi vis à
vis de
squatteurs qui, avec la complicité du concierge, se sont, sans
effraction, illégalement emparés du bien d’autrui,
à savoir de
connaissances appartenant à la collectivité et
nécessaires à son
bon développement (voir par exemple [20] pour un bon exemple des méfaits de
la sur-protection des biens communs).

Recevabilité des demandes et le caractère « technique » du brevetable

Pages 157-159.

Cette section présente un certain nombre d’idées
intéressantes, telles
que la nécessité de conserver une discrimination
technique comme
critère de brevetabilité, mais conclut qu’il convient de
laisser à
l’Office Européen des Brevets le soin de déterminer la
nature de ce
critère, ce dont il s’est bien gardé jusqu’à
présent, ce qui lui a
justement permis de breveter des méthodes
commerciales [21] et
éducatives [22],
voire même des jeux [23], en réussissant l’exploit de les
considérer comme
techniques.

Au vu de ce qui précède, il convient de fixer une limite
claire à
la brevetabilité, qui ne puisse faire l’objet
d’interprétations
multiples, provocatrices de risque juridique pour les acteurs
économiques. Cette limite est celle de
l’immatérialité, et nombreux
sont ceux qui proposent de définir le critère de
technicité comme
le recours à des forces contrôlables de la nature,
permettant ainsi
d’exclure tout logiciel « en tant que tel »
de la brevetabilité.

Conclusion

À la lumière de la plupart des éléments de
ce rapport, ainsi que des
corrections apportées par la présente note à
certains points erronés
basés sur des données anciennes, il semble évident
qu’il faille
rejeter la brevetabilité logicielle en Europe, le logiciel
devant
rester sous le régime du copyright/droit d’auteur.


Il est à noter que, dans l’autre volet du rapport, traitant des
bio-technologies (pages 49 à 112), les auteurs arrivent à
la
conclusion que les brevets sont néfastes, alors que les
investissements dans le domaine des bio-technologies sont encore plus
lourds que dans le domaine du logiciel, ce qui constitue un argument
supplémentaire en faveur du rejet de la brevetabilité
logicielle.

Références

[1]
http://www.cae.gouv.fr/rapports/dl/41.pdf
[2]
http://www.enpc.fr/ceras/caillaud/pdf/Logiciels.pdf
[3]
http://www.researchoninnovation.org/swpat.pdf
[4]
http://www.ftc.gov/opp/intellect/020227trans.pdf
Voir en particulier le témoignage de R. Jordan Greenhall, CEO de DivxNetworks, en date du 27 février 2002.
[5]
http://www.ftc.gov/opp/intellect/barrrobert.doc
[6]
http://l2.espacenet.com/dips/viewer?PN=EP394160&amp ;CY=fr&amp ;LG=fr&amp ;DB=EPD
Brevet européen EP394160.
[7]
http://www.eff.org/IP/Video/DeCSS_prosecutions/Johansen_DeCSS_case/
Il s’agit ici d’attaques basées sur le copyright, mais le principe serait le même dans le cas de brevets logiciels.
[8]
http://www.eucd.info/
[9]
http://msdn.microsoft.com/library/en-us/dnkerb/html/Finalcifs_LicenseAgrmnt_032802.asp
http://swpat.ffii.org/patents/effects/cifs/index.en.html
[10]
http://ftp.std.com/obi/Bill.Gates/Challenges.and.Strategy
[11]
http://www.open5source.net/opensource.org/halloween/
[12]
http://www.transfert.net/a8955
[13]
http://www.mbf-law.com/pubs/articles/830.cfm
[14]
http://www.cafezine.com/index_article.asp?deptId=6&amp ;id=643&amp ;page=3
[15]
http://www.forbes.com/asap/2002/0624/044.html
[16]
http://www.nytimes.com/2001/11/11/business/11PROP.html?pagewanted=pr
[17]
http://www.youmaybenext.com/
[18]
http://www2.museumtour.com/sbc.html
[19]
http://vrijschrift.org/swpat/030508_1/index.html
[20]
http://www.sciencemag.org/cgi/content/full/280/5364/698
[21]
http://l2.espacenet.com/dips/viewer?PN=EP756731&amp ;CY=fr&amp ;LG=fr&amp ;DB=EPD
Brevet européen EP756731.
22
http://l2.espacenet.com/dips/viewer?PN=EP664041&amp ;CY=fr&amp ;LG=fr&amp ;DB=EPD
Brevet européen EP664041.
[23]
http://l2.espacenet.com/dips/viewer?PN=EP866412&amp ;CY=fr&amp ;LG=fr&amp ;DB=EPD
Brevet européen EP866412.

Répondre à cet article