Votre invention bourrée de logiciel devrait-elle être brevetable ? Un test.
Je suis dans le camp de ceux qui ne croient pas aux brevets logiciels, pour les nombreuses raisons développées dans ce blog. Je ne suis pas pour autant contre la « Propriété Intellectuelle », même si je trouve le terme mal choisi, par exemple je détiens des marques (et les défends fermement).
Cela ne veut pas dire non plus que je sois contre les brevets en général. Au contraire, l’argument de la protection des inventeurs m’interpelle, particulièrement s’ils n’ont pas les ressources ou la volonté de commercialiser eux-mêmes leur invention. L’argument de l’incitation à innover semble parfois justifié. Mais mon expérience en tant que développeur et entrepreneur m’a montré que ces arguments ne s’appliquent pas au logiciel. Le logiciel est différent, mais ce n’est pas l’objet de ce billet. Parce que le logiciel est différent, les brevets ne sont pas nécessaires pour protéger l’inventeur, et n’engendrent aucune incitation à la création. Ils ne font que vous piéger dans un labyrinthe de brevets douteux qui rendent l’acte d’innovation extrêmement périlleux. Au-delà de la question des brevets, je suis basiquement dans le camp du Droit d’Innover dans le Logiciel.
Nous, du camp du Droit d’Innover dans le Logiciel, devons reconnaître une difficulté avec notre position. Nous disons qu’il y a d’un côté des inventions qui peuvent être brevetées, et que nous sommes prêts à le défendre, et qu’il y a d’un autre côté le logiciel, qui ne peut pas être breveté. Une règle est donc nécessaire pour distinguer entre ce qui devrait être brevetable et ce qui ne l’est pas. Ce test devrait être aussi simple et opérationnel que possible, et laisser aussi peu de place que possible à l’interprétation. Ceci est indispensable pour obtenir la très indispensable sécurité juridique: si le critère est obscur ou flou, nous replongerons dans le cauchemar dont nous cherchons à sortir, nous le camp du Droit d’Innover dans le Logiciel. Si vous pensez que le logiciel peut être breveté, vous n’avez pas ce problème. Etant donné que nous créons le problème de la distinction entre le logiciel, non-brevetable, et les inventions qui contiennent du logiciel, qui sont brevetables, il semble raisonnable que ce soit nous qui devions nous creuser pour proposer un test.
J’ai donc examiné plusieurs critères, et retenu un, et le voici (continuez à lire !). Je commence par quelques tests qui ont été proposés, et j’essaie d’expliquer pourquoi ils n’ont pas « pris ».
Les forces de la nature sont surtout pour les esprits forts
En 2005, au cours de la campaigne en Europe autour des « inventions implémentées par ordinateur » (Computer Implemented Inventions ou CII), le critère de l' »utilisation des forces de la nature » a été particulièrement mis en avant: pour qu’une chose soit brevetable, elle doit faire appel aux « forces de la nature ». L’idée était que, par exemple, un système de freinage anti-blocage ABS est en fait un système de contrôle-commande avec un actuateur. C’est donc une machine, en tant qu’inventeur, vous devriez pouvoir obtenir un brevet, alors qu’un simple algorithme ne devrait pas être brevetable au simple prétexte qu’il tourne sur un ordinateur.
J’ai assisté à des discussions entre des activistes et des représentants élus, les premiers essayant d’expliquer l’argument aux seconds. Ces derniers, quoi qu’étant des gens brillants, ne saisissaient pas l’idée. Pour moi, ceci indique que le test n’est pas suffisamment clair (certains activistes pensent que l’argument n’a pas été assez expliqué, et qu’ils doivent continuer, une perte de temps de mon point de vue).
L’effet technique n’est pas technique en tant que tel
Un critère présent dans la Convention Européenne des Brevets (European Patent Convention, EPC) est que, pour être qualifiée comme telle, une invention doit avoir un « effet technique ». L’idée est plus ou moins la même que celle des forces de la nature, mais, là encore, l’expression du critère n’a pas la signification attendue. Par exemple, le Bureau Européen des Brevets (European Patent Office – EPO) a parfois considéré que la modification du courant électrique dans une mémoire d’ordinateur était un effet technique suffisant. Je considère qu’il s’agit là d’une distorsion audacieuse des termes, car il est clair que n’importe quel programme d’ordinateur a un tel effet, alors que l’EPC exclue explicitement le « logiciel en tant que tel » (« software as such »), de la brevetabilité.
La règle d’or
Il faut donc un nouveau test. Voilà le mien: la règle de distinction du logiciel de Tronche.
« Si une machine déjà existante peut être programmée (sans modification du matériel) pour faire ce que fait votre invention, ce n’en est pas une, et la demande de brevet devrait être rejetée. »
En particulier, s’il est possible de programmer un ordinateur à usage général, brut de décoffrage, pour faire la même chose, clairement votre « invention » n’en est pas une, c’est du pur logiciel, et doit donc être exclue de la brevetabilité. Le brevet porte sur l’ordinateur à usage général (qu’il soit de Zuse / Eckert-Mauchly / Von Neumann), qui est tombé depuis longtemps dans le domaine public.
Si on prend le cas du freinage ABS, le premier inventeur obtiendrait clairement son brevet avec ce test: aucun ordinateur de la FNAC, quel que soit le soit le programme qu’on écrit, ne pourra ralentir votre voiture si vous n’ajoutez pas un peu de matériel.
La protection obtenue alors est particulièrement forte: personne ne peut plus prendre un frein contrôlé par ordinateur, introduire des modifications logicielles, et prétendre avoir une nouvelle invention.
Il est simple de décider d’un litige avec ce test. Si vous pensez qu’un brevet n’aurait
pas dû être attribué, il suffit de décrire comment obtenir le même effet avec une machine pré-existante.
Le test n’empêche pas non plus d’avoir un brevet pour l’implémentation en hardware d’une fonction connue, mais dans ce cas le brevet doit porter sur le design de la machine, non la fonction (elle a déjà été implémentée). Et n’oubliez pas que vous pouvez protéger le masque en tant que dessin, pas seulement par un brevet.
Pensez à appliquer la règle de Tronche la prochaine fois que vous entendrez parler de brevet logiciel, cela vous donnera une idée de vos chances de survivre à la bulle des brevets logiciels.