Cher journal,

Les voix sur LinuxFR, pour autant divisées qu'elles étaient sur le TCE, sont unanimement contre dès qu'on parle de brevets logiciels. C'est sûr que l'exemple américain n'est pas très encourageant, mais les brevets ça part d'une bonne idée a priori, celle de permettre à un "inventeur" de bénéficier de son travail pendant une période donnée.
J'ai un peu réfléchi à la question, avec mes connaissances modestes (je ne suis pas juriste), et donc peut être avec des raisonnements à contre-sens de la réalité, mais je vous en fait part.

Il me semble que, brevets logiciels ou pas, un programmeur ne désirant pas déposer de brevet peut tout à fait décider de rendre public ses "inventions" via des preuves d'antériorité, que ce soit sous forme de code placé en domaine public, BSD ou GPL, ce qui empêchera en théorie toute entreprise de s'emparer de l'idée en exclusivité... (dans le cas du code GPL, cela "condamne" même l'idée à rester "GPL"...)
Maintenant, si une personne décide de déposer un brevet sur une idée jugée basique, il "bloque" l'avancée à son seul profit pendant un certain temps. Or, le logiciel avance relativement vite, et plusieurs blocages de quelques années peuvent à moyen terme freiner l'avancée de l'informatique en général.
Mais y a-t-il encore tant de choses basiques à inventer ? Il me semble que, si demain les brevets logiciels devaient être mis en place, tout ce qui a été développé jusque aujourd'hui, et qui nous permet aujourd'hui d'avoir des bureaux libres utilisables (KDE, Gnome, xfce, etc), ou des sites webs communautaires, ne serait pas brevetable, du fait de l'ensemble des preuves d'antériorité que constitue le code rendu public de ces applications.

Finalement, pour les avancées futures, si le brevet n'avait cours que sur une durée limitée (disons deux à trois ans maximum), je pense que ce serait un bon compromis. D'autant plus qu'il me semble que quand on dépose un brevet, on doit donner tous les détails de l'implémentation de ces idées, et permettrait le développement des logiciels libres sur les bases de la R&D effectuée en entreprise, un peu comme pour les médicaments génériques.
On aurait donc d'une part des "inventions" rendus publiques par les bénévoles et la recherche publique, au bénéfice de tous, et d'autre part, une rentabilisation pendant quelques années de la R&D privée, avant que les apports de celle-ci soient eux aussi rendus publics. Tout cela me semble à long terme bénéfique à l'avancée de l'informatique...

Le principal argument des anti-brevets, c'est qu'il est relativement facile pour une personne en ayant les moyens de déposer des brevets bidons (en particulier, en faisant fi des preuves d'antériorité). Ces brevets bidons seraient annulés par le premier tribunal venu, mais à un coût insupportable pour les plus petits. Ici, une question qui m'interroge : pourquoi le problème n'existerait que pour les brevets logiciels et pas pour les brevets "classiques", comme pour une poubelle à pédale révolutionnaire ?
D'autre part, le coût de la justice a-t-il lieu d'être ? Sur ce genre d'attaque bidon de la part de l'entreprise, il me semble étrange que le procès dure plus d'une heure, n'importe quel avocat au rabais devrait pouvoir assurer la défense, et ses honoraires remboursés par le perdant du procès, avec intérêts...
Le seul obstacle étant la preuve d'antériorité, dont il faut prouver qu'elle date bien d'avant le dépôt du brevet. Une sorte de Sourceforge agréé ne suffirait-il pas ?

Voilà, voilà. Je suis peut être d'une naïveté touchante, mais dans un monde honnête, tout irait quand même pour le mieux.

> Lire le journal (23 commentaires, moyenne: 2,9).

Hop, pour un premier journal, un journal que j'espère utile.

En passant sur un forum d'amateurs d'Histoire, je suis passé sur un topic parlant de la cryptographie lors de la seconde guerre mondiale (Enigma, Turing/Rejewski, toussa).

Je me suis emballé et j'ai rapidement rédigé une réponse de mémoire, exposant mes connaissances d'amateur sur la cryptographie moderne. La réponse est rapidement devenue assez conséquente, et je me demande si elle ne pourrait pas servir de base à un article de vulgarisation plus complet.

Je m'auto-cite :

Alan Turing est un personnage très intéressant et on le considère comme un des pères fondateurs des théories de l'Intelligence Artificielle et de la science de l'informatique fondamentale en général.
En particulier, il a démontré qu'il existait des problèmes pour lesquels aucun algorithme ne trouverait jamais de solution (ce sont des problèmes indécidables).
Il existe aussi des problèmes pour lesquels la durée d'exécution de l'algorithme évolue exponentiellement avec le nombre d'informations. Ces problèmes sont au coeur de la cryptographie moderne. Ainsi, si un programme met 2 secondes à casser une clé 8 bits (généralement en essayant toutes les clés possibles, les algorithmes de cryptage étant a priori mathématiquement conçus pour ne pas permettre d'autre méthode), il mettra 4 secondes à casser une clé 9 bits, 8 secondes à casser une clé 10 bits... A 16 bits, on en est déjà à 8 minutes, à 24 bits à 36 heures... A 128 bits, il faudrait un milliard de milliards de milliards d'années de calculs pour "casser" le cryptage !
On sent bien que l'augmentation de puissance des ordinateurs n'est pas une solution suffisante au décryptage... D'ailleurs ils est très facile d'augmenter la taille des clés.

Une propriété très importante de ces algorithmes est que même en en connaissant parfaitement les rouages, il est impossible de décrypter des messages sans disposer de la clé de décryptage.

Le problème, c'est que personne n'a réussi à démontrer mathématiquement que ce type de problèmes exponentiels existait ! Ou plutôt, on connaît des problèmes qu'on ne sait résoudre que de cette manière, mais personne n'a réussi à démontrer qu'il n'existerait pas une méthode susceptible de résoudre ces problèmes sans augmentation exponentielle des temps de calcul. Trouver de tels algorithmes est le travail de la majorité des chercheurs en intelligence artificielle aujourd'hui (ces algorithmes ont d'ailleurs des applications ailleurs qu'en cryptographie).

De plus, face à un message crypté, il existe des méthodes basées sur les statistiques susceptibles d'aider au décryptage des messages. Cacher les messages cryptés dans des documents anodins (données musicales, images...) permet de renforcer encore la protection.

D'autre part, même en supposant qu'on ait le moyen d'avoir des algorithmes de cryptage totalement incassables, la gestion des clés de cryptage et de décryptage est également quelque chose de très complexe. Actuellement, la plupart des méthodes de cryptage utilisent un système de "double clés", publique et privée. La clé publique permet de cryptage de message, et la clé privée en permet de décryptage. La clé publique est générée à partir de la clé privée, et il est normalement impossible de retrouver la clé privée à partir de la clé publique (en fait le problème est le même que pour le décryptage lui même, voir paragraphe ci dessus).
De cette façon, la clé publique peut être envoyée à tout le monde sans problème, et vous serez le seul à pouvoir lire les messages codés avec la clé publique.

Ce système de paire de clés permet également la "signature numérique" des messages : à partir du contenu du message et de la clé privée, on génère une "signature". Avec la clé publique, on peut vérifier que la signature n'a pu être réalisée qu'à partir de la clé privée. Ainsi, on est sûr que le message provient bien du possesseur de la clé privée associée à la clé publique dont on dispose.

Il existe même des systèmes permettant de se prémunir contre les fausses clés (si je publie une clé publique en me faisant passer pour quelqu'un d'autre, je pourrais facilement signer des messages à son nom).

Je sollicite l'avis des mou^W linuxéfèriens avisés, pour corriger les grosses coquilles (et en même temps parfaire mes connaissances sur le sujet). N'oubliez pas que je destine ce texte plutôt à un article de vulgarisation, mais à titre personnel je suis ouvert aux détails techniques.

Pour info, les informations sur la complexité des algorithmes, et notamment l'absence de démonstration P=NP provient de plus ou moins vagues souvenirs d'un DEA d'IA, et la partie concernant les clé, de l'installation et configuration d'Enigmail (oui, j'ai pas été chercher bien loin).

Et si ça intéresse quelqu'un, je mets la partie entre "blockquote" sous licence FDL. Là.

P.S. Ah tiens, le correcteur orthographique de LinuxFR me rappelle qu'on dit "chiffrage" et non pas "cryptage". Je pourrais le corriger, mais ça serait long, et ça permettra de le rappeler.

> Lire le journal (8 commentaires, moyenne: 2,9).