Re: [Fsfe-france] M. Breese ?

[Vincent Caron]

Jean-Baptiste Soufron said:
>
> Le brevet est nécessaire pour protéger l'investissement, voila tout. Le 
> brevet est un
> frein à l'innovation mais c'est un frein limité par rapport au secret 
> industriel qui
> est un frein définitif à toute innovation. Le brevet est l'assurance de 
> pouvoir
> commercialiser une invention facilement (pas de problèmes à essayer de garder 
> son
> fonctionnement secret, etc. la loi se charge de veiller contre la 
> contrefaçon) en
> échange de sa remise, à terme, dans le domaine public.

La première phrase occulte la question principale : le brevet est-il 
"nécessaire" dans
tous les domaines ? Pour ma part, si j'en arrive à conclure que le brevet ne 
doit pas
s'appliquer au logiciel (donc que la législation est adéquate depuis 30 ans), 
c'est
qu'un brevet adapté au logiciel n'aurait pas de sens. Faisons la mesure :

- première protection : le brevet protège le fond au lieu de la forme. Ce n'est 
pas
souhaitable pour toutes les formes de créations originales, si on cite la 
littérature
(au sens large, journalisme etc) cela ne fait de doute pour personne. Pour le 
logiciel
la question n'a rien de simple : il est toujours réductible à un texte (le 'code
source') dont la longueur, la versatilité et l'originalité n'ont souvent rien à 
envier
à Zola (pardon Emile!). Même si son contenu est parfaitement technique et 
n'émeut que
des processeurs...

En pratique, on ne se lasse pas le répéter, cela veut dire que le logiciel 
recoupe une
masse de _concepts_ _récents_ qui rendent la pratique même du brevet peu 
réaliste. Le
logiciel est à la fois une méthode d'expérimentation et une réalisation 
technique.
Pour la première fois, il n'y a pas de différence entre le plan de l'invention 
et
l'invention (puisqu'ici on ne parle pas de protéger des binaires, j'oublie la
compilation qui n'a d'intérêt que dans le débat du droit d'auteur).

J'insiste encore sur la versatilité. Identifier par exemple un différentiel 
dans un
schéma mécanique n'est pas une gageure, dans ce monde matériel il existe peu de 
moyens
d'assembler des engrenages sur deux axes perpendiculaires sur un support 
rotatif. Dans
le monde informatique, un algorithme peut être implémenté par une variété de 
languages
impressionnants, et pour chaque language de nombreuses façons (Perl est déjà 
une tour
de Babel pour les pratiquants de Perl dont je suis !). Je programme depuis plus 
de 10
ans avec de nombreux languages, je lis et consulte beaucoup de code source, 
j'affirme
que l'identification d'algorithmes dans un seul logiciel de taille modeste 
(~100,000
ligne) est un travail titanesque. La seule tâche de compréhension de 
l'interface d'un
logiciel dont on veut acquérir un savoir (pour s'inspirer, améliorer, modifier, 
etc)
est déjà souvent longue et pénible, sans que je prenne le temps de m'intéresser 
aux
algorithmes sous-jacents mis en oeuvre.

Mettons que l'argument pratique ne tienne pas. Vous avez décuplé (au bas mot) 
les
effectifs de votre section 'veille juridique', vous avez des spécialistes en 
Python,
Java, C, C++, Perl, Eiffel, Lisp, ObjectiveC, Ruby, TCL, C# (_tous_ extrêmement
populaires et utilisés), vous leur laissez du temps pour faire une veille
technologique continue sur les 'algorithmes informatiques', en priant pour 
qu'on ne
vous attaque que sur les algorithmes centrés sur votre domaine d'expertise, et 
non pas
un morceau d'infrastructure qui ne vous intéresse pas.

- Il reste à régler la durée de ce brevet. Visiblement tout le monde est 
d'accord que
la durée actuelle de 20 ans est ridicule pour le logiciel. Mon expérience me 
pousse à
suggérer un maximum de 2 ans : la versatilité du logicielle encourage 
précisément à de
multiples implémentations d'un même algorithme, et les utilisateurs veulent le
meilleur, même une amélioration constante comme on le constate aujourd'hui. Si 
en 2
ans l'inventeur n'a pas su profiter de son monopole pour exceller 
techniquement, il ne
lui reste plus qu'à s'incliner devant la concurrence. Sinon le frein 
technologique de
ce monopole coûte cher pour la société. Exemples : LZW menaçant le 'compress' 
de GNU
de ne plus être libre, moins de 2 ans plus tard gzip (fort heureusement basé 
sur LZ77)
arrive et est plus efficace. MP3 : développé en 93, en 95 il existe déjà 
plusieurs
implémentations bien plus efficaces que celles vendues par Fraunhofer.

Enfin dernière remarque importante sur ta phrase même : il est effectivement 
plus que
vrai que le brevet sur le logiciel s'annonce comme un frein à l'innovation, car 
il ne
partage pas le savoir comme sa raison d'être l'exige. Un brevet n'est pas 
accompagné
de code source, formulation pourtant la plus concise et efficace pour un "homme 
de
l'art" pour décrire un algorithme. Il a même été rappelé que son jargon rend 
l'accès
particulièrement difficile, et j'ai déjà lu soigneusement plusieurs brevets 
logiciels
(de l'USPTO et de l'OBE), y compris un sur un logiciel auquel j'ai participé (à 
mon
grand dam, il s'agit de SCOL de Cryonetworks) : parfaitement obfuscatoire.

Ce qui au passage permet de conclure que le logiciel libre est un formidable 
support
de l'innovation (je n'en vois pas de meilleur : liberté de consulter, exécuter,
modifier, redistribuer), que l'histoire le prouve (20 ans de GNU pour ~40 ans
d'informatique industrielle), et que le moindre mal est que nous puissions 
continuer à
le pratiquer.