Signal fort et beau symbole, en 2007 il avait été décidé de passer les postes des députés sous GNU/Linux Ubuntu et OpenOffice.org (cf ces témoignages). Arrive aujourd’hui le temps du renouvellement et les députés, fraîchement élu(e)s ou réélu(e)s, ont le choix du choix, avec Windows ou Ubuntu et Microsoft Office ou LibreOffice.

François Revol est un acteur bien connu de la communauté francophone du logiciel libre. Il fait ici acte de citoyenneté en prenant le temps d’adresser une lettre détaillée et personnalisée à son député sur ce sujet à ses yeux bien plus important qu’il n’y paraît. Nous vous invitons à vous en inspirer pour en faire de même, si vous partagez ses arguments et sa préoccupation.

Nous ne souhaitons pas qu’une assemblée nationale plus rose devienne moins libre.

Objet : Système d’exploitation de votre ordinateur

Madame, Monsieur le Député,

Si ce n’est déjà fait, et que personne n’a choisi à votre place, vous allez devoir prendre une décision très importante, que vous pourrez considérer comme anodine mais qui pourtant est cruciale.

Pour cette législature, conformément à la demande de la questure, vous avez le choix du système d’exploitation (SE) qui sera utilisé sur votre ordinateur. La législature précédente avait permis un énorme progrès par l’installation de GNU/Linux^[1] sur toutes les machines des députés auparavant sous Windows, mettant ainsi à leur disposition un système plus éthique, plus économique, plus flexible, et participant à restaurer une certaine indépendance européenne dans le secteur du logiciel. Il semble au contraire pour cette législature, pour certaines raisons obscures et surtout exprimées bien tardivement, qu’il ait été décidé de vous laisser le choix. L’histoire dira, et surtout votre choix, si c’est un recul ou un progrès, et si vous avez usé sagement de ce qui pour beaucoup d’entre nous est encore un luxe, puisque précieux mais trop peu répandu.

En effet, malgré l’interdiction par la loi de la vente liée^[2], le choix du système d’exploitation lors de l’achat d’un ordinateur par un particulier relève encore du plus rare des luxes, réservé aux seules entreprises. Si l’on en croit les revendeurs et fabricants, le particulier est simplement trop stupide pour faire un choix éclairé. L’excuse d’une complexité accrue de production est également caduque, les offres existantes pour les entreprises montrant la viabilité de proposition du choix. En fait il s’agit surtout de préserver des monopoles établis, ceux d’une entreprise américaine bien connue pour avoir été sanctionnée par la Commission européenne pour cette même raison.

Pourtant le choix du système d’exploitation est important à plusieurs titres, même en laissant l’éthique de côté, ayant même des conséquences sur la relocalisation d’emplois.

Ainsi par exemple le choix d’un SE libre permet, en plus de répondre aux questions d’indépendance, d’interopérabilité, et d’adaptabilité, de générer une activité de développement logiciel locale nécessaire à une adaptation au plus près des besoins, adaptation impossible avec du logiciel propriétaire qui dépend entièrement du bon vouloir de l’éditeur. En effet, le logiciel libre, par essence, est distribué avec son code source et la liberté de modification, permettant ainsi la création et la mise en concurrence d’expertises non subordonnées à l’éditeur original. La mutualisation des coûts de production des logiciels libres participe aussi de la création de biens communs. Comme nombre de sujets connexes liés au numérique, le logiciel libre transcende donc le bipartisme.

Certains d’entre vous ont d’ailleurs signé le Pacte Logiciel Libre lors de la campagne, d’autres lors de précédentes législatures ont voté pour ou contre certains projets de loi dommageables au logiciel libre, comme DADVSI ou HADOPI, créant ainsi du tracas y compris à des universitaires français, comme les auteurs du logiciel de lecture vidéo VLC, obligés de demander à la HADOPI comment contourner les DRM^[3] du BluRay. La HADOPI n’a d’ailleurs pas été d’une grande utilité pour résoudre la violation de la licence de FFmpeg/LibAV, logiciel libre auquel j’ai modestement contribué, commise par un sous-traitant d’Orange4 pendant plus d’un an. Il s’agit pourtant ici également de protection des auteurs. Il est intéressant de plus de noter qu’Orange comptait parmi les fiers sponsors officiels de l’inutile sommet « eG8 » où la question de la protection des auteurs a été abordée. La Commission européenne n’étant d’ailleurs pas en reste, tant par sa tentative de faire adopter le traité ACTA^[4] que la directive sur le brevet unitaire qui bien qu’utile sur le principe laisse entrer le logiciel dans le champ de la brevetabilité, ce qui ne saurait être plus grotesque puisque le logiciel est une expression de la pensée humaine et donc naturellement sous le régime du droit d’auteur.

Tous ces problèmes ont en commun le manque de considération des « acteurs », entreprises – pourtant grandes utilisatrices de logiciel libre – comme législateur. Ceci vient autant de la perception erronée de l’informatique comme un sujet purement technique et économique, que des effets de la vente liée, effets devenant rétroactivement causes de renforcement des monopoles. Le grand public est en effet gardé dans l’ignorance, croyant que le choix qui est fait pour lui est dans son intérêt, que « ça marche comme ça », et que « Linux ça marche pas », ce qui dans la plupart des cas est dû au manque de support matériel, lui-même résultant de l’indisponibilité des spécifications techniques du matériel, puisque bien sûr les fabricants préfèrent distribuer plutôt des pilotes pour Windows que les spécifications, qui sont pourtant le « manuel utilisateur » du matériel par le logiciel et devraient être publiques, ceci étant justement la conséquence du monopole déjà évoqué.

L’ironie de la situation étant que même Microsoft a été victime de cet état de fait, puisque lors de la sortie de Windows Vista, certains périphériques fournis uniquement avec des pilotes pour les versions précédentes de Windows n’étaient plus utilisables, mettant ainsi en colère les utilisateurs devant néanmoins acheter Windows Vista avec leur nouvelle machine, sans toutefois pouvoir utiliser certains périphériques pourtant neufs mais dont le fabricant refusait de fournir un pilote mis à jour.

Quand aux très rares matériels « certifiés Linux » disponibles, ils sont généralement seulement sommairement testés une fois pour toute certification, et de plus vraiment un « luxe » au vu des prix pratiqués.

Malgré des campagnes d’information au public de la part d’associations de promotion du logiciel libre comme l’April ou l’AFUL, ainsi que plusieurs procès gagnés par des particuliers, l’inaction de la DGCCRF est manifeste, et le status quo demeure depuis maintenant plus d’une décennie.

En effet, le problème de la vente liée, loin d’être récent, est par exemple une des causes majeures de la fermeture en 2001 de Be, Inc., éditeur du système d’exploitation BeOS, que j’ai utilisé pendant 10 ans. Déjà à l’époque Microsoft s’imposait sur les ordinateurs PC par le verrouillage du processus de démarrage, et en interdisant aux revendeurs par des contrats secrets d’installer un autre SE, la seule tentative de Be, Inc. de fournir des ordinateurs pré-installés avec son système ayant été torpillée, Hitachi se contentant alors de laisser BeOS sur le disque dur mais sans le rendre disponible au démarrage, ni même documenté et donc de facto inaccessible.

Plus tard, un éditeur de logiciel allemand ayant tenté de reprendre le développement de ce même système a également dû fermer, toujours par manque de ventes et à cause du monopole de fait de Microsoft sur le marché, me causant au passage un licenciement économique.

C’est d’ailleurs l’échec commercial de BeOS qui a conduit à la création du système d’exploitation libre Haiku auquel je contribue actuellement, dans l’idée de perpétuer son originalité, comme on tenterait de préserver une espèce nécessaire à la technodiversité. Pourtant, même si c’est un projet plus ludique que commercial à l’heure actuelle, la vente liée nous pose problème tout comme aux auteurs de Linux. En effet, la non disponibilité des spécifications matérielles chez certains fabricants et de nombreux constructeurs rend impossible l’écriture des pilotes de périphériques pourtant nécessaire à leur utilisation.

Cet état de fait est d’ailleurs une régression. En effet à une certaine époque la plupart des machines électroniques (téléviseurs, électrophones, mais aussi ordinateurs) étaient livrées avec les schémas complets. J’ai ainsi par exemple, dans le manuel utilisateur de mon premier ordinateur (un ORIC Atmos), la description de son fonctionnement interne et toute la documentation permettant d’interfacer du matériel, et l’importateur avait même publié les plans. L’obsolescence programmée a pris le pas depuis lors.

Ce luxe donc, auquel vous avez droit, m’a été refusé à l’achat de mon dernier ordinateur portable. Non seulement le fabricant refuse de rembourser la licence de Windows 7 que je n’ai jamais demandée, mais il ne m’a toujours pas communiqué les spécifications nécessaires à l’adaptation du système que je désire utiliser et auquel je contribue. J’en suis donc réduit lorsque je tente de l’utiliser actuellement à une résolution graphique inférieure à ce que l’écran permet et sans aucune accélération matérielle, pas de connexion réseau, et l’impossibilité de produire du son, sans parler des fonctions moins essentielles, que pourtant j’ai payées. Pourtant, ainsi que je l’ai dit, ces spécifications constituent le « manuel utilisateur » du matériel par le logiciel, et forment donc en ce qui me concerne, des «caractéristiques essentielles »^[5]. D’ailleurs, cette même machine avec GNU/Linux que j’utilise également cause régulièrement des problèmes pour la même raison, à savoir la non disponibilité des spécifications qui empêche la correction d’un bogue du pilote vidéo pourtant documenté depuis plus d’un an.

La vente liée cause du tort également à des éditeurs français, comme Mandriva, qui publiait une distribution de GNU/Linux depuis 1998, initialement appelée « Mandrake Linux », que j’ai d’ailleurs un temps utilisée, mais n’a pas réussi à s’imposer et a donc disparu récemment. On ne peu que déplorer le résultat de cette concurrence pas vraiment libre et certainement faussée.

Et pourtant le logiciel libre permet de développer de nombreux [modèles économiques différents|http://www.april.org/livre-blanc-des-modele-economiques-du-logiciel-libre], ouvrant des perspectives d’emploi pour des PME innovantes, si la loi ne le défavorise pas.

Par ces temps de crise, il ne serait d’ailleurs pas inutile de s’intéresser aux optimisations fiscales, pour ne pas parler d’évasion, que certaines entreprises multinationales pratiquent, Microsoft en premier mais également Apple. L’absence de détail des prix lors de la vente liée pose d’ailleurs des questions légitimes quand à la répartition de la TVA.

La pratique par Microsoft du verrouillage du processus de démarrage, que j’évoquais plus haut à propos des PC, est d’ailleurs toujours d’actualité puisque bien évidemment les prochaines tablettes « compatibles Windows 8 » devront implémenter obligatoirement le mécanisme dit « SecureBoot », qui au prétexte de limiter les virus rendra totalement impossible l’installation d’un système libre. Et donc alors même que le combat contre la vente liée s’éternise sur les PC, il est presque déjà perdu sur les machines qui les remplaceront bientôt, alors même que ce sont toujours des ordinateurs malgré tout, dont l’utilisateur devrait garder le contrôle, contrôle qui s’exprime en premier sur le choix des logiciels qu’il voudra pouvoir utiliser ou non.

Le choix d’installer Windows s’apparente ainsi plus au non-choix, à un blanc-seing laissé à Microsoft quand au contrôle de votre machine, avec la sécurité qu’on lui connaît. C’est aussi un choix de facilité, au vu de la situation actuelle, mais également la caution d’une situation inacceptable.

Le choix d’installer GNU/Linux, sur une machine de bureau, est avant tout moral et éthique avant d’être pragmatique, alors que sur un serveur il s’impose plus logiquement. C’est pourtant tout autant un choix de sécurité, puisque le code source ouvert garantit le contrôle que l’on a sur le système, comme l’absence de porte dérobée. C’est aussi un choix courageux et téméraire, par l’entrée dans ce qui reste encore une minorité technologiquement discriminée. Mais ce serait aussi un signal fort envers les développeurs qui créent ces logiciels, les utilisateurs confortés dans leur choix difficile, et enfin les fabricants de matériels qui pour certains encore n’ont pas compris qu’il était de leur devoir et de leur intérêt de considérer tous les utilisateurs.

Ne vous y trompez pas, la majorité des problèmes qui pourraient survenir lors de l’utilisation de GNU/Linux ne sont pas de son fait ou des développeurs qui l’ont écrit, mais bien de Microsoft, Apple, et d’autres éditeurs, qui par leur politique de fermeture compliquent inutilement l’interopérabilité entre leur système et les autres, à dessein bien sûr, puisque leur but est le monopole. D’ailleurs il est à prévoir des incompatibilités entre GNU/Linux et l’infrastructure choisie par la questure pour la gestion des courriels, à savoir Microsoft Exchange, bien connu pour ne respecter aucun standard hormis le sien, c’est à dire donc aucun, puisque les formats et protocoles d’Exchange ne sont en rien normalisés ni donc standard (de jure). Alors même que les logiciels de courriel de GNU/Linux respectent de nombreux standards et normes. Pour résumer, dire que GNU/Linux pose problème serait simplement inverser la situation causée par ces monopoles.

Une métaphore que j’utilise depuis des années sans succès, mais pourtant découverte aussi récemment par un juge, s’énonce ainsi :

« La vente liée d’un système d’exploitation avec un ordinateur revient à l’obligation d’embauche d’un chauffeur à l’achat d’une voiture. »

Ceci vous semble absurde ? À moi aussi. C’est pourtant la pratique actuelle.

En tant qu’ingénieur, auteur de logiciels libres, citoyen et électeur, ce sujet me tient à cœur, et il me semble nécessaire qu’au moins la législation actuelle soit appliquée, à défaut d’évoluer. J’espère vous avoir éclairé sur ce choix important qui vous incombe, non dénué de symbole, et qui je le rappelle est un luxe pour le particulier même informé. Je reste à votre disposition pour toute discussion.

Je vous prie d’agréer, Madame, Monsieur le Député, l’expression de ma considération la plus distinguée.

François Revol

Crédit photo : Takato Marui (Creative Commons By-Sa)

La technologie a fait faire à la santé d’extraordinaires progrès. Mais libre ou propriétaire ? Dans le domaine des appareils médicaux pilotés par des logiciels ce choix peut avoir de très lourdes conséquences.

Ici plus qu’ailleurs, sacrifier l’humain sur l’autel du business model ne peut plus être une solution durable dans le temps^[1].

Lorsque le code peut tuer ou guérir

When code can kill or cure

Technology Quarterly – 2 juin 2012 – The Economist
(Traduction : balsamic, moala, Isammoc, Otourly, Mnyo, HgO, elquan)

Appliquer le modèle open source à la conception d’appareils médicaux permet d’accroitre la sécurité et stimule l’innovation.

Les pompes SMART délivrent des médicaments parfaitements dosés pour chaque patient. Des défibrilateurs faciles à utiliser peuvent ramener des victimes d’attaque cardiaque d’entre les morts. Les pacemakers et coeurs artificiels maintiennent les gens en vie en s’assurant que la circulation sanguine se déroule sans problème. Les appareils médicaux sont une merveille du monde moderne.

Alors que ces appareils sont devenus de plus en plus efficients, ils deviennent cependant de plus en plus complexes. Plus de la moitié des appareils médicaux vendus aux Etats-Unis (le plus grand marché de la santé) s’appuient sur du logiciel, et souvent en grande quantité. Ainsi le logiciel dans un pacemaker peut nécessiter plus de 80.000 lignes de code, une pompe à perfusion 170.000 lignes et un scanner à IRM (Imagerie à Résonance Magnétique) plus de 7 millions de lignes.

Cette dépendance grandissante vis à vis du logiciel cause des problèmes bien connus de tous ceux qui ont déjà utilisé un ordinateur : bugs, plantages, et vulnérabilités face aux attaques. Les chercheurs de l’université de Patras en Grèce ont découvert qu’un appareil médical sur trois vendu aux États-Unis entre 1995 et 2005 a été rappelé pour défaillance du logiciel. Kevin Fu, professeur d’informatique à l’université du Massachusetts, estime que ce phénomène a affecté plus de 1,5 millions d’appareils individuels depuis 2002. En avril, les chercheurs de la firme de sécurité informatique McAfee ont annoncé avoir découvert un moyen pour détourner une pompe à insuline installée dans le corps d’un patient en injectant l’équivalent de 45 jours de traitement d’un seul coup. Enfin, en 2008, Dr Fu et ses collègues ont publié un article détaillant la reprogrammation à distance d’un défibrillateur implanté.

Or le disfonctionnement du logiciel d’un appareil médical a des conséquences beaucoup plus désastreuses que d’avoir seulement à faire redémarrer votre ordinateur. Durant les années 1980, un bug dans le logiciel des machines de radiothérapie Therac-25 a provoqué une overdose de radiations administrées à plusieurs patients, en tuant au moins cinq. L’Organisation américaine de l’alimentation et des médicaments, l’America’s Food and Drug Administration (FDA), s’est penchée sur le cas des pompes à perfusion qui ont causé près de 20.000 blessures graves et plus de 700 morts entre 2005 et 2009. Les erreurs logicielles étaient le problème le plus fréquemment cité. Si, par exemple, le programme buggé interprète plusieurs fois le même appui sur une touche, il peut administrer une surdose.

En plus des dysfonctionnements accidentels, les appareils médicaux sans fils ou connectés sont également vulnérables aux attaques de hackers malveillants. Dans le document de 2008 du Dr Fu et de ses collègues, il est prouvé qu’un défibrillateur automatique sous-cutané peut être reprogrammé à distance, bloquer une thérapie en cours, ou bien délivrer des chocs non attendus. Le Dr Fu explique que lors des phases de test de leur logiciel, les fabricants d’appareils manquent de culture de la sécurité, culture que l’on peut trouver dans d’autres industries à haut risque, telle que l’aéronautique. Insup Lee, professeur d’Informatique à l’Université de Pennsylvanie, confirme : « Beaucoup de fabricants n’ont pas l’expertise ou la volonté d’utiliser les mises à jour ou les nouveaux outils offerts par l’informatique ».

Personne ne peut évaluer avec certitude l’étendue réelle des dégâts. Les logiciels utilisés dans la majorité des appareils médicaux sont propriétaires et fermés. Cela empêche les firmes rivales de copier le code d’une autre entreprise, ou simplement de vérifier des infractions à la propriété intellectuelle. Mais cela rend aussi la tâche plus ardue pour les experts en sécurité. La FDA, qui a le pouvoir de demander à voir le code source de chaque appareil qu’elle autorise sur le marché, ne le vérifie pas systématiquement, laissant aux constructeurs la liberté de valider leurs propres logiciels. Il y a deux ans, la FDA offrait gratuitement un logiciel « d’analyse statique » aux constructeurs de pompes à perfusion, dans l’espoir de réduire le nombre de morts et de blessés. Mais aucun constructeur n’a encore accepté l’offre de la FDA.

Ouvert à l’étude

Frustrés par le manque de coopération de la part des fabricants, certains chercheurs veulent maintenant rebooter l’industrie des appareils médicaux en utilisant les techniques et modèles open source. Dans les systèmes libres, le code source est librement partagé et peut être visionné et modifié par quiconque souhaitant savoir comment il fonctionne pour éventuellement en proposer une version améliorée. En exposant la conception à plusieurs mains et à plusieurs paires de yeux, la théorie veut que cela conduise à des produits plus sûrs. Ce qui semble bien être le cas pour les logiciels bureautiques, où les bugs et les failles de sécurité dans les applications open source sont bien souvent corrigés beaucoup plus rapidement que dans les programmes commerciaux propriétaires.

Le projet d’une pompe à perfusion générique et ouverte (Generic Infusion Pump), un effort conjoint de l’Université de Pennsylvanie et de la FDA, reconsidère ces appareils à problèmes depuis la base. Les chercheurs commencent non pas par construire l’appareil ou écrire du code, mais par imaginer tout ce qui peut potentiellement mal fonctionner dans une pompe à perfusion. Les fabricants sont appelés à participer, et ils sont plusieurs à le faire, notamment vTitan, une start-up basée aux Etats-Unis et en Inde « Pour un nouveau fabricant, c’est un bon départ » dit Peri Kasthuri, l’un de ses co-fondateurs. En travaillant ensemble sur une plateforme open source, les fabricants peuvent construire des produits plus sûrs pour tout le monde, tout en gardant la possibilité d’ajouter des fonctionnalités pour se différencier de leur concurrents.

Des modèles mathématiques de designs de pompes à perfusion (existantes ou originales) ont été testés vis à vis des dangers possibles, et les plus performantes ont été utilisées pour générer du code, qui a été installé dans une pompe à perfusion de seconde main achetée en ligne pour 20$. « Mon rêve, dit Dave Arnez, un chercheur participant à ce projet, est qu’un hôpital puisse finalement imprimer une pompe à perfusion utilisant une machine à prototypage rapide, qu’il y télécharge le logiciel open source et que l’appareil fonctionne en quelques heures ».

L’initiative Open Source Medical Device de l’université Wisconsin-Madison est d’ambition comparable. Deux physiciens médicaux (NdT: appelés radiophysiciens ou physiciens d’hôpital), Rock Mackie et Surendra Prajapati, conçoivent ainsi une machine combinant la radiothérapie avec la tomographie haute résolution par ordinateur, et la tomographie par émission de positron. Le but est de fournir, à faible coût, tout le nécessaire pour construire l’appareil à partir de zéro, en incluant les spécifications matérielles, le code source, les instructions d’assemblages, les pièces suggérées — et même des recommandations sur les lieux d’achat et les prix indicatifs. La machine devrait coûter environ le quart d’un scanner commercial, la rendant attractive pour les pays en voie de développement, déclare le Dr Prajapati. « Les appareils existants sont coûteux, autant à l’achat qu’à la maintenance » rappelle-t-il, là ou les modèles libres sont plus durables. « Si vous pouvez le construire vous-même, vous pouvez le réparer vous-même. »

Les appareils open source sont littéralement à la pointe de la science médicale. Un robot chirurgien open source nommé Raven, conçu à l’Université de Washington à Seattle fournit une plateforme d’expérimentation abordable aux chercheurs du monde entier en proposant de nouvelles techniques et technologies pour la chirurgie robotique.

Tous ces systèmes open source travaillent sur des problématiques diverses et variées de la médecine, mais ils ont tous un point commun : ils sont encore tous interdit à l’utilisation sur des patients humains vivants. En effet, pour être utilisés dans des centres cliniques, les appareils open source doivent suivre les mêmes longues et coûteuses procédures d’approbation de la FDA que n’importe quel autre appareil médical. Les réglementations de la FDA n’imposent pas encore que les logiciels soient analysés contre les bugs, mais elles insistent sur le présence d’une documentation rigoureuse détaillant leur développement. Ce n’est pas toujours en adéquation avec la nature collaborative et souvent informelle du développement open source.

Le coût élevé de la certification a forcé quelques projets open source à but non lucratif à modifier leur business model. « Dans les années 90, nous développions un excellent système de planning des traitements de radiothérapie et avions essayé de le donner aux autres cliniques, explique le Dr Mackie, mais lorsque la FDA nous a suggéré de faire approuver notre logiciel, l’hôpital n’a pas voulu nous financer. » Il a fondé une société dérivée uniquement pour obtenir l’approbation de la FDA. Cela a pris quatre ans et a couté des millions de dollars. En conséquence, le logiciel a été vendu en tant qu’un traditionnel produit propriétaire fermé.

D’autres tentent de contourner totalement le système de régulation américain. Le robot chirurgical Raven (Corbeau) est destiné à la recherche sur les animaux et les cadavres, quant au scanner de l’Open Source Medical Device, il est conçu pour supporter des animaux de la taille des rats et des lapins. « Néanmoins, déclare le Dr Mackie, rien n’empêche de reprendre le design et de lui faire passer les procédures de certification dans un autre pays. Il est tout à fait envisageable que l’appareil soit utilisé sur des humains dans d’autres parties du monde où la régulation est moins stricte, avance-t-il. Nous espérons que dans un tel cas de figure, il sera suffisamment bien conçu pour ne blesser personne. »

Changer les règles

La FDA accepte progressivement l’ouverture. Le Programme d’interopérabilité des appareils médicaux Plug-and-Play, une initiative de 10 millions de dollars financé par le NIH (l’Institut National de la Santé) avec le support de la FDA, travaille à établir des standards ouverts pour interconnecter les appareils provenant de différents fabricants. Cela signifierait, par exemple, qu’un brassard de pression artérielle d’un certain fabricant pourrait commander à une pompe à perfusion d’un autre fabricant d’arrêter la délivrance de médicament s’il détecte que le patient souffre d’un effet indésirable.

Le framework de coordination des appareils médicaux (Medical Device Coordination Framework), en cours de développement par John Hatcliff à l’Université de l’État du Kansas, est plus intrigant encore. Il a pour but de construire une plateforme matérielle open source comprenant des éléments communs à beaucoup d’appareils médicaux, tels que les écrans, les boutons, les processeurs, les interfaces réseaux ainsi que les logiciels pour les piloter. En connectant différents capteurs ou actionneurs, ce cœur générique pourrait être transformé en des dizaines d’appareils médicaux différents, avec les fonctionnalités pertinentes programmées en tant qu’applications (ou apps) téléchargeables.

À terme, les appareils médicaux devraient évoluer vers des ensembles d’accessoires spécialisés (libres ou propriétaires), dont les composants primaires et les fonctionnalités de sécurité seraient gérés par une plateforme open source. La FDA travaille avec le Dr Hatcliff pour développer des processus de création et de validation des applications médicales critiques.

Dans le même temps, on tend à améliorer la sécurité globale et la fiabilité des logiciels dans les appareils médicaux. Le NIST (Institut national des États-Unis des normes et de la technologie) vient juste de recommander qu’une seule agence, probablement la FDA, soit responsable de l’approbation et de la vérification de la cyber-sécurité des appareils médicaux, et la FDA est en train de réévaluer ses capacités à gérer l’utilisation croissante de logiciels.

De tels changements ne peuvent plus attendre. « Quand un avion s’écrase, les gens le remarquent », dit le Dr Fu. « Mais quand une ou deux personnes sont blessées par un appareil médical, ou même si des centaines sont blessées dans des régions différentes du pays, personne n’y fait attention. » Avec des appareils plus complexes, des hackers plus actifs et des patients plus curieux et impliqués, ouvrir le cœur caché de la technologie médicale prend vraiment ici tout son sens.

Tout libriste digne de ce nom connaît le classique débat entre le logiciel libre et le logiciel Open Source (cf ce lien qui marque notre préférence : Pourquoi l’expression « logiciel libre » est meilleure qu’« open source »)^[1].

Va-t-on assister à la même foire d’empoigne pour le secteur en plein développement actuellement du matériel libre ? ou ouvert, ou les deux à la fois, enfin c’est vous qui voyez…

Du matériel ouvert ou du matériel libre ?

Open hardware, or open source hardware?

Andrew Katz – 22 août 2011 – Commons Law (ComputerWorld.uk)
(Traduction Framalang : Lamessen, Loïc, Penguin, kabaka, Antoine)

Allons nous assister à une réédition des débats sémantiques qui traversent le monde logiciel ?

Bruce Perens (co-fondateur de l’Open Source Initiative) s’est récemment interrogé lors d’une conférence sur les différences qu’il pouvait y avoir entre le matériel libre (Open Source Hardware) et le matériel ouvert (Open Hardware). De nombreuses personnes ont comparé ce débat à la classique nuance (ou opposition, c’est selon) entre le logiciel libre (free software) et le logiciel Open Source, en s’inquiétant qu’il puisse diviser tout autant. Je n’en suis pas si sûr. Je pense que les deux sont différents et qu’ils peuvent co-exister pacifiquement.

Selon mon point de vue, un matériel libre est un matériel fourni avec les schémas pour qu’on puisse le reproduire nous-même, alors qu’un matériel ouvert est un matériel qui est fourni avec des spécifications complètes de manière à ce que vous puissiez interagir avec lui sans mauvaises surprises mais sans nécessairement savoir ce qui se passe à l’intérieur.

Le matériel libre est meilleur (du point de vue de l’utilisateur), mais le matériel ouvert est sans aucun doute une avancée dans la bonne direction.

Le matériel libre dépend la plupart du temps inévitablement de matériel ouvert : par exemple, vous pouvez avoir toutes les spécifications d’un circuit intégré simple comme un NE555, sans avoir besoin de toutes les informations nécessaires à sa construction.

Pour du matériel plus complexe, les spécifications d’un boulon (pas de vis, diamètre, longueur, type de tête, résistance à la traction, résistance générale à la corrosion…) peuvent être disponibles, mais il est peu probable que la composition exacte de l’alliage utilisé pour le fabriquer, sa trempe, etc… le soient. La plupart des composants électroniques simples seront donc du matériel ouvert.

Le seul point sur lequel il faut être un peu plus prudent quand on parle de matériel libre est que, contrairement au logiciel, il est plus difficile de tracer la frontière entre la source et l’objet. Par exemple, je dirais qu’une voiture est libre si la documentation complète sur sa conception est disponible tant que les spécifications des moteurs sont suffisantes pour l’utilisation qu’on souhaite en faire et qu’elles font ce qu’elles sont censées faire sans mauvaises surprises, quand bien même certaines pièces soient individuellement propriétaires ou non sourcées.

Si vous suivez une approche maximaliste, et que vous voulez les instructions nécessaires et suffisantes à la fabrication complète d’une voiture à partir d’un amas d’atomes, alors vous serez malheureusement déçus la plupart du temps. Heureusement, je n’ai rencontré personne d’aussi extrêmiste dans le monde du logiciel Open Source, oups, pardon, dans celui du logiciel libre 🙂

Qu’on les aime ou qu’on les déteste, les suites bureautiques se sont imposées ces derniers lustres comme indispensables dans le paysage logiciel. La suite numéro un, Microsoft Office, est devenue une référence et un incontournable. En langage courant, on ne parle plus de présentations ou de transparents, on dit tout simplement « un PowerPoint ».

Microsoft Office n’étant pas disponible sur les systèmes libres comme Linux, il est évident qu’une alternative viable se devait d’exister. Vous la connaissez certainement, il s’agit d’OpenOffice. Et, depuis quelques mois, on entend parler de LibreOffice. Mais n’est-ce pas juste un changement de nom ? Tout cela est un peu confus.

J’avais déjà tenté de faire une courte clarification. Essayons de voir en détail ce qu’il en est.

Les débuts de StarDivision

Nous sommes en 1984. Un très jeune programmeur allemand fonde la société StarDivision afin de vendre son logiciel de traitement de texte StarWriter. Celui-ci est destiné principalement aux ordinateurs Zilog Z80 et Amstrad CPC. Nous sommes dans les tous débuts de l’informatique à destination du grand public. Ni Microsoft Office ni même Windows n’existent encore.

Après quelque temps, StarDivision adapte son logiciel aux systèmes DOS, OS/2. D’autres composants se rajoutent à StarWriter : StarBase, un logiciel de base de données, StarDraw, un logiciel de dessin vectoriel. Le tout est empaqueté sous le nom global de StarOffice, en faisant une des premières suites bureautiques.

Avec le support de Windows 3.1, StarOffice gagne un nouveau composant, StarCalc, un tableur.

StarOffice dans le giron de Sun

Faisons un bond en avant et propulsons nous en 1999. À cette époque, Microsoft règne sans partage sur les ordinateurs individuels grâce à Windows 95 et Windows 98, sans oublier Windows NT dans les entreprises. Dans ces dernières, Microsoft Office 97 s’est imposé comme la suite office indispensable. Son plus gros concurrent est… Microsoft Works ! Eh oui, Microsoft se paie le luxe d’être son propre concurrent et d’avoir deux suites bureautiques qui sont difficilement interopérables (utilisant des formats propriétaires différents).

Sun travaille sur son système d’exploitation Solaris et espère en faire un concurrent à Windows. Le problème est que Solaris ne dispose pas d’une suite bureautique et que chacun des 42.000 employés de Sun doit garder deux ordinateurs : un sous Solaris et un sous Windows pour faire tourner Microsoft Office.

Stratégiquement, avoir une suite bureautique sous Solaris est indispensable. Sun se met en chasse et rachète StarDivision pour 73.5 millions de dollars. Rien que le prix économisé dans les licences Microsoft (42.000 licences Windows + 42.000 licences Office) permettrait de rentabiliser l’achat en quelques années.

Sun travaille donc à partir de la suite StarOffice et la porte sous Solaris.

Naissance d’OpenOffice

À peine un an plus tard, en 2000, Sun se rend compte que le seul ennemi capable d’affaiblir la toute-puissance de Microsoft, alors à son apogée, est le monde Open Source. Et selon l’adage « Les ennemis de mes ennemis sont mes amis », Sun décide de doter la communauté OpenSource d’un concurrent à Microsoft Office.

Une version Open Source de StarOffice est donc libérée sous le nom OpenOffice, qui deviendra OpenOffice.org, le nom OpenOffice étant déjà déposé dans certains pays.

Derrière ce mouvement se cache bien entendu une stratégie marketing. Sun espère qu’OpenOffice gagnera le cœur des étudiants, des particuliers, des hackers mais que les entreprises souhaitant un support professionnel se tournent vers StarOffice. Certaines fonctionnalités de StarOffice ne sont d’ailleurs pas présente dans OpenOffice.

Cela a pour conséquence que toute personne souhaitant contribuer au code d’OpenOffice doit céder ses droits à Sun, afin que celui-ci puisse le réutiliser dans StarOffice.

Sun OpenOffice, l’incontournable

De 2001 à 2010, OpenOffice va devenir incontournable chez les libristes et les utilisateurs de système Linux. Sa gratuité est également un atout indéniable dans les entreprises et les services publics. Certains évangélistes du libre y voient un cheval de Troie pour introduire le libre un peu partout et en font une promotion éhontée.

Cependant, tout n’est pas rose. Le développement n’est pas très rapide. Les contributions ne sont pas toujours acceptées par Sun. Le logiciel, vieillissant, acquiert une réputation de lenteur et de non-ergonomie.

Microsoft Office, de son côté, fait des progrès fulgurants avec les éditions 2003 et 2007. Malgré un succès d’estime, OpenOffice peine à sortir du cadre des geeks barbus.

Lotus Symphony, IBM rentre dans la danse

IBM, géant de l’informatique, est célèbre pour n’avoir jamais compris l’importance du logiciel et de la micro-informatique. Inventeur du PC, ils n’ont pas perçu le marché pour ce type de machine et ont laissé Microsoft fournir le système d’exploitation DOS. Se rendant compte de leur erreur, ils tenteront d’imposer OS/2 sans jamais y parvenir.

La même histoire se répète avec les suites bureautiques. Se rendant compte de l’importance de ce type de logiciel, IBM produira Lotus Symphony, une suite bureautique pour DOS. Cette suite sera complètement abandonnée en 1992.

Ce n’est qu’en 2007, à la mode des carabiniers d’Offenbach, qu’IBM décidera de relancer dans une suite de productivité qui comportera son client mail Lotus Notes, très populaire en entreprise et détenteur du titre de logiciel le plus haï par ses utilisateurs. IBM va donc reprendre OpenOffice et en modifier l’interface afin de créer IBM Lotus Symphony.

IBM Lotus Symphony est synchronisé avec OpenOffice mais aucun code n’est contribué au projet. En ce sens, IBM est vu comme un mauvais joueur par la communauté.

Oracle Open Office, la fin d’une époque

Sun ne va pas très bien. Solaris n’a jamais réellement percé. Le matériel Sun, d’excellente facture mais extrêmement cher, voit une concurrence rude tirer les prix vers le bas. Beaucoup d’investissements ont été faits comme le rachat de MySQL. Des questions se posent. C’est alors qu’arrive Oracle.

Oracle est un géant de l’informatique qui a fait sa fortune sur la gestion des bases de données. Ils aimeraient avoir un peu plus d’expertises dans le matériel (afin de vendre des serveurs liés à leurs bases de données) et contrôler un dangereux concurrent OpenSource qui est de plus en plus populaire : MySQL, justement racheté par Sun.

En 2009, Oracle rachète donc Sun pour 7,4 milliards de dollars. Seulement, Oracle n’a que faire de StarOffice ou d’OpenOffice. C’est le cadeau bonus venu avec l’achat et ça les ennuie plus qu’autre chose. De plus, contrairement à Sun, Oracle a montré de nombreuses fois qu’il se poste en ennemi acharné du logiciel libre.

En 2010, inquiets, les membres de la communauté OpenOffice créent donc la Document Foundation, une fondation sans but lucratif dont le but est de promouvoir et de continuer le développement d’OpenOffice, sans dépendre d’Oracle.

LibreOffice, la première suite communautaire

Il ne reste qu’un petit détail à régler : le nom, OpenOffice, appartient toujours à Oracle. La fondation fait une demande officielle à Oracle, Ô Oracle, vous qui êtes si puissant, si beau, si fort et qui n’avez que faire de ce misérable nom, cédez le nous et vous serez mille fois béni.

C’est à ce moment que les requins de chez Oracle lèvent les sourcils. Si ce nom est demandé, il a peut-être une certaine valeur. IBM met son grain de sel : si Oracle cède le nom à la fondation, IBM peut très bien ne plus pouvoir intégrer le code d’OpenOffice dans son Lotus Symphony qui est propriétaire, la Document Foundation soutenant des licences cancérigènes comme la LGPL !

Oracle refuse donc de céder le nom. La mort dans l’âme, la Document Foundation décide d’accepter la mort d’OpenOffice et de faire renaître le projet sous le nom LibreOffice.

Au final, ce changement de nom se révèle bénéfique. Comme le passage de XFree86 à X.org, il marque la transition. L’engouement communautaire est tel qu’en moins d’une année LibreOffice gagne des dizaines de contributeurs, un nombre impressionnant de lignes de code est changé et une première conférence rassemblant la communauté à lieu à Paris en octobre 2011. Conférence au cours de laquelle il est annoncé notamment le désir de porter LibreOffice sur Androïd. Les participants assistent également à une première démonstration de LibreOffice Online, une version web de la suite bureautique.

Apache Open Office, papy fait de la résistance

Mais il serait faux de penser qu’Oracle en resterait là. Tout aurait pu être tellement simple. Mais il ne faut jamais sous-estimer la nuisance qu’une confusion dans l’esprit du public peut apporter.

Peu après l’annonce de la création de LibreOffice, Oracle décide de donner le projet OpenOffice, y compris le nom, à la fondation Apache. À charge pour elle de continuer le développement de ce projet.

À la Document Foundation, tout le monde est un peu surpris. Surtout que la licence Apache choisie permet à LibreOffice de reprendre du code de chez Apache OpenOffice mais le contraire n’est lui pas possible. En juillet 2011, IBM annonce sa volonté de contribuer au projet Apache OpenOffice et, début 2012, annonce même arrêter complètement IBM Lotus Symphony pour se concentrer uniquement sur Apache OpenOffice.

OpenOffice ou LibreOffice, lequel choisir ?

Pour beaucoup, Apache OpenOffice n’est donc qu’un homme de paille, un projet IBM, qui sert les intérêts d’IBM et non ceux de la communauté. Après quelques mois, il faut se rendre à l’évidence: le projet Apache OpenOffice dispose de dix fois moins de contributeurs. Comparer le nombre de modifications du code entre les deux projets est également sans appel : LibreOffice est un projet libre, communautaire et OpenOffice est une anecdote poussée à contre-cœur.

La majorité des distributions Linux sont d’ailleurs passées à LibreOffice. Des grands projets se mettent en place: la région Île-de-France travaille à offrir un LibreOffice intégré avec sa solution Cloud à tous ses étudiants. Un écosystème de sociétés a rejoint la Document Foundation afin d’offrir du support professionnel sur LibreOffice, depuis les grands pontes comme Suse, partie de Novell, au petites structures comme Lanedo, employeur de votre serviteur.

Si l’offre est là, la demande est elle en pleine confusion. Des clients de Sun, payant pour le support d’OpenOffice, se sont retrouvés sans maintenance du jour au lendemain. Le changement de nom fait craindre une migration lente et coûteuse, beaucoup ne comprenant pas qu’il s’agit essentiellement du même logiciel.

Si l’avenir de LibreOffice semble radieux, beaucoup ne le saisissent pas encore. Mais, maintenant, si jamais on vous pose la question de savoir la différence entre OpenOffice et LibreOffice, vous pourrez répondre : « Assieds-toi, je vais te raconter une histoire… ».

Les règles d’un jeu, les règles du jeu, ne sont pas inscrites dans le marbre. Et il est toujours possible, pour les plus audacieux, de faire un pas de côté pour les améliorer.

Telle est l’expérience fondatrice de Jeremy enfant au contact de son ami Bruce, véritable petit hacker en herbe^[1].

On pourra certes objecter que cet état d’esprit bidouilleur et inventif n’a pas attendu l’open source pour exister mais il s’en trouve fortement stimulé par les potentialités nouvelles qu’offre Internet.

Le jour où mon esprit devint open source

The day my mind became open sourced

Phil Shapiro – 20 avril 2012 – OpenSource.com
(Traduction Framalang : Adrien Dorsaz, e-Jim et Goofy)

Je me souviens très bien du jour exact où mon esprit est devenu open source. C’était un jour frais et ensoleillé de novembre 1973. Après les cours de l’école primaire, j’ai appelé mon meilleur ami, Bruce Jordan, et je lui ai demandé : « Est-ce que je peux passer jouer maintenant ? ». Bruce m’a répondu : « Bien sûr ! ». J’ai chevauché ma bicyclette rouge Schwinn (qui n’avait qu’une vitesse) et j’ai roulé comme un fou sur les trois kilomètres jusque chez Bruce. Je suis arrivé avec le souffle coupé, mais très heureux.

C’était plaisant de jouer avec Bruce, parce qu’il était toujours en train d’inventer de nouveaux jeux à jouer à l’intérieur et également à l’extérieur. Chez lui, on ne s’ennuyait jamais une seconde. C’est ainsi que, quand nous nous sommes assis pour jouer au Scrabble ce jour-là, Bruce a spontanément suggéré : « Prenons chacun 10 lettres au lieu de 7. Ça va beaucoup améliorer le jeu ». J’ai protesté : « Mais les règles écrites sur la boîte du jeu disent qu’on est censé prendre 7 lettres. »

Bruce a rapidement répondu : « Ce qui est imprimé sur la boîte, c’est pas des règles. C’est juste des suggestions de règles du jeu. Toi et moi, on est libres de les améliorer ». J’étais un peu stupéfait. Je n’avais jamais entendu une telle idée auparavant. Je lui ai rétorqué : « Mais les règles sur la boîte ont été écrites par les adultes qui sont plus intelligents que nous, non ? ».

Bruce m’a alors expliqué avec aplomb : « Ceux qui ont inventé ce jeu ne sont pas plus intelligents que toi ou moi, même si ce sont des adultes. Nous pouvons trouver de meilleures règles qu’eux pour ce jeu. De bien meilleures règles. »

J’étais un peu sceptique, jusqu’à que Bruce me dise « écoute, si ce jeu n’est pas beaucoup plus amusant dès les 5 premières minutes, nous retournons aux règles écrites sur la boîte ». Cela m’a semblé un bon moyen de procéder.

Et les règles du Scrabble de Bruce rendaient effectivement le jeu bien plus amusant. En pleine partie, je ne pus m’empêcher de lui demander : « si les règles du Scrabble peuvent être améliorées, est-ce que les règles d’autres jeux peuvent aussi être améliorées ? ».

Bruce me répondit « Les règles de tous les jeux peuvent être améliorées. Mais ce n’est pas tout. Tout ce que tu vois autour de toi et qui a été conçu par l’esprit humain peut être amélioré. Tout peut être amélioré ! »

À ces mots, un éclair m’a traversé l’esprit. En quelques secondes, mon esprit a basculé vers l’open source. À ce moment précis, j’ai su quels étaient le but de ma vie et ma destinée : chercher autour de moi les choses qui peuvent être améliorées, puis les améliorer.

Lorsque je suis remonté sur mon vélo Schwinn pour rentrer à la maison ce soir-là, mon esprit était enivré d’idées et de possibilités. J’ai plus appris de Bruce ce jour-là que je n’avais appris durant toute une année d’école. Vingt-cinq ans avant que l’expression Open Source ne soit formulée pour la première fois, Bruce Jordan a ouvert les sources de mon esprit. Je lui en serai éternellement reconnaissant.

Et alors que je roulais vers chez moi, je pris la résolution que durant ma vie, je concentrerai mon énergie à élargir les possibilités d’apprendre en dehors du cadre scolaire, parce que les apprentissages et les réalisations les plus significatives surviennent hors de l’enceinte de l’école.

Actuellement, je travaille dans une bibliothèque publique dans la région de Washington DC, et chaque jour, je discute avec des enfants. De temps en temps, je croise des élèves dont l’esprit est réceptif aux grandes idées. Lorsque cela m’arrive, je plante de petites graines dans leur esprit, et les laisse tracer leur route. Il leur revient de cultiver ces graines. Mon rôle se limite à planter des graines d’idées dans leur esprit. Le leur, c’est d’observer les germinations de ces graines, et de choisir de les arroser ou non.

Bruce Jordan m’a enseigné une autre leçon importante. La même année, il m’a demandé si je voulais jouer au Frisbee Baseball. « C’est quoi le Frisbee Baseball ? » demandai-je avec curiosité. Bruce répondit alors : « je ne sais pas, mais ça a l’air d’être un jeu génial. Nous allons créer les règles en marchant vers le terrain de baseball ».

Sans surprise, Bruce inventa les règles du Frisbee Baseball alors que nous parcourions le bloc qui nous séparait du terrain. Et nous avons joué avec grand plaisir, jusqu’à ce que l’obscurité nous empêche de voir le Frisbee. Ce que j’ai appris de Bruce ce jour-là, c’est de ne pas avoir peur d’aller là où mon instinct me dit qu’il y a de bonnes choses. Bruce était persuadé que nous allions nous éclater en jouant au Frisbee Baseball. Et il avait raison.

Le mouvement Open Source concerne les logiciels, mais il est loin de se limiter à ce domaine. Il s’agit de considérer les créations et les idées qui naissent du génie humain avec optimisme. Tout peut être amélioré, de fond en comble. Tout ce qu’il nous faut, c’est une dose de créativité et la volonté de consacrer notre esprit à une tâche donnée.

On se lance ? Au départ, les règles de tous les jeux sont imprimées sur la boîte, mais ces règles ne sont que des suggestions. On peut les améliorer, et il faudrait les améliorer à chaque fois que c’est possible.

Le Népal n’est pas forcément en avance dans le développement numérique du pays^[1].

Raison de plus pour adopter d’emblée le logiciel libre…

L’impact de l’open source au Népal

Nepal and the impact of open source

Carolyn Fox – 8 mai 2012 – OpenSource.com
(Traduction framalang : Slystone, Cédric Corazza, Goofy et Kabaka)

Le Népal est l’un des pays les plus pauvres au monde. Il fait face à de nombreux problèmes liés à l’inégalité entre les sexes, à l’éducation, ou au retard des technologies numériques. Et pourtant le Népal se transforme peu à peu grâce à l’open source et aux technologies numériques. Mais à mesure que le Népal cherche à intégrer ses citoyens dans l’économie mondiale numérique, de nombreux obstacles se dressent en travers de son chemin : instabilité politique, difficulté d’accès physique, infrastructures déficientes et pauvreté rurale. En avril 2012, le Forum Economique Mondial a publié un rapport qui a caractérisé le Népal comme l’un des pays les moins connectés au monde, tout en bas du classement mondial.

L’accès à l’éducation secondaire continue d’être un gros problème au Népal, particulièrement pour les filles. Environ la moitié des enfants du pays souffre de malnutrition chronique. Un enfant sur trois travaille et on estime qu’ils sont 2,6 millions à travailler entre cinq et quatorze ans.

La situation des jeunes Népalaises est plus que difficile. Le taux d’alphabétisation pour les filles va ainsi de 28 à 42%, comparé au 65 à 87% pour les garçons. La plupart des filles sont humiliées, opprimées et exploitées dans leur vie quotidienne. Les écoles publiques népalaises requièrent des frais de scolarité et beaucoup de parents ne peuvent se permettre d’y envoyer leurs filles ; on attend souvent des filles qu’elles abandonnent leurs études pour aller travailler.

L’impact direct des logiciels libres et des technologies numériques peut sembler à des années-lumières pour beaucoup, mais le gouvernement népalais et les organisations non gouvernementales (ONG) commencent à apporter un peu de changements dans la vie quotidienne des enfants ruraux et pauvres, et particulièrement des filles. Le Plan pour l’éducation du gouvernement népalais, le Plan de réforme du secteur scolaire, l’Open Learning Exchange (OLE) Népal, le projet One Laptop Per Child (OLPC) et d’autres initiatives font de grands progrès pour résorber la fracture numérique — en dépit du récent rapport du Forum économique mondial. Le gouvernement népalais, OLE Népal et d’autres organisations aident à réduire la fracture numérique en mettant à disposition des technologies numériques et des supports open source qui sont absolument nécessaires au Népal pour accomplir un progrès significatif, ce que le Sommet mondial pour la société de l’information (SMSI) a souligné.

Depuis 2009, OLE Népal a distribué plus de 2500 ordinateurs portables dans 26 écoles népalaises et a œuvré à créer des supports libres pour éduquer et encourager les enfants népalais, particulièrement les filles. Les objectifs principaux de OLE Népal sont d’améliorer l’éducation publique et de réduire la disparité de l’accès à l’éducation. La distribution d’équipements n’était pas suffisante pour résoudre le sous-équipement numérique du pays selon OLE Népal. La création de supports éducatifs libres, avec l’aide des développeurs et programmeurs népalais locaux, a été la clé de voûte de la résolution du problème numérique du pays. En 2011, OLE Népal a collaboré avec le British Council pour créer « Learn English Kids », un programme ayant pour but d’enseigner gratuitement les fondamentaux de l’anglais aux enfants et adultes népalais . Environ 3400 étudiants dans 34 écoles à travers le pays ont utilisé l’application Learn English Kids. Auparavant, les possibilités et supports nécessaires pour apprendre l’anglais étaient rares.

Des initiatives comme celles de OLE Népal et de OLPC donnent aux filles rurales pauvres, en particulier, une chance d’accéder aux études et d’échapper à une vie de pauvreté. Le rôle des femmes népalaises et l’utilisation des technologies sont les clés du potentiel et de l’avenir du pays. OLE Népal s’est rendu compte de la nécessité d’une bibliothèque numérique libre et fondée sur un objectif d’éducation pour aider les citoyens à franchir la fracture numérique et à améliorer la qualité et l’accès à l’éducation. E-Pustakayla peut être installé à l’école ou dans un centre communautaire sans accès à Internet, offrant ainsi à tous une source d’informations et d’éducation ouverte et gratuite.

Ces initiatives ont contribué à augmenter le taux d’alphabétisation et ont encouragé la création de communautés numériques au Népal. Sambad par exemple, est un projet de recherche sur la façon dont la technologie peut bénéficier aux analphabètes et illettrés du Népal. Une des possibilités consiste à créer des communautés numériques basées sur des communications audio ou visuelles, plutôt que sur du texte. Ces initiatives permettent aux Népalais de participer pleinement à la société numérique et sont une source d’émancipation et de changement social.

ALISON montre comment le monde du libre a un impact direct sur la vie des gens ordinaires au Népal. ALISON est une ressource en ligne gratuite pour l’apprentissage des bases et fondamentaux du monde du travail, proposant des cours numériques, des certificats ou des diplômes gratuitement aux citoyens népalais. Ce projet a le soutien du gouvernement népalais.

Le gouvernement du Népal est conscient de l’importance de l’alphabétisation numérique et du pouvoir du e-learning dans l’amélioration de la vie de ses citoyens. Celui-ci considère ALISON et d’autres programmes comme un moyen d’émancipation pour les Népalais et une source d’espoir en un développement durable avec l’aide du monde du libre et des technologies numériques.

Facebook est-il « libre » ? Gmail est-il « libre » ? Le nébuleux « cloud computing » est-il « libre » ?

Lorsqu’il s’agit de services en ligne la question est mal posée et mérite d’être précisée, nous affirme ici Richard Stallman en passant en revue les différents et complexes cas de figure^[1].

Les services en ligne ne sont ni libres ni privateurs ; ils posent d’autres problèmes

URL d’origine du document (GNU.org)

Richard Stallman – version du 15 mai 2012 – Gnu.org – Creative Commons By-Nd
(Traduction : Céline Libéral, Mathieu Adoutte, Caner, pour Framalang)

Les programmes et les services sont deux choses différentes. Un programme est une œuvre que vous pouvez exécuter, un service est une activité avec laquelle vous pouvez interagir.

Pour les programmes, nous établissons une distinction entre libre et non libre (privateur, ou propriétaire). Plus précisément, cette distinction s’applique à un programme dont vous avez une copie : soit vous disposez des quatre libertés, soit vous n’en disposez pas.

Une activité (telle qu’un service) n’existe pas sous forme de copies. Il n’est donc pas possible d’en avoir une ni d’en faire. Ainsi, les quatre libertés qui définissent un logiciel libre n’ont pas de sens pour les services.

Pour utiliser une analogie culinaire, même si j’ai appris à cuisiner en vous regardant, ma cuisine ne peut pas être une copie de la vôtre. Il se peut que j’aie une copie de la recette que vous utilisez pour cuisiner, et que je m’en serve, car les recettes, comme les programmes, sont des œuvres qui peuvent exister en plusieurs exemplaires. Mais la recette et la manière de cuisiner sont deux choses différentes (et les plats obtenus en sont une troisième).

Avec la technologie actuelle, les services sont souvent implémentés en faisant tourner des programmes sur des ordinateurs mais ce n’est pas le seul moyen (en fait, il existe des services en ligne qui sont implémentés en demandant à des êtres humains en chair et en os de saisir des réponses à des questions). Dans tous les cas, l’implémentation n’est pas visible par les utilisateurs du service, donc cela n’a aucun impact sur eux.

Un service en ligne peut poser aux utilisateurs le problème du recours à un logiciel libre ou non libre, par le biais du client requis pour l’utiliser. Si le service nécessite l’utilisation d’un programme client non libre, recourir à ce service suppose que vous abandonniez votre liberté à ce programme. Pour beaucoup de services web, ce logiciel non libre est du code JavaScript, installé discrètement dans le navigateur de l’utilisateur. Le programme GNU LibreJS permet de refuser facilement d’exécuter ce code JavaScript non libre. Mais le problème du logiciel client est selon toute logique distinct de celui du service lui-même.

Il existe un cas où un service est directement comparable à un programme : celui où le service revient à avoir une copie d’un programme donné et à l’exécuter vous-même. On appelle cela SaaS, ou « logiciel en tant que service », et un tel service constitue toujours une régression au plan éthique. Si vous disposiez du programme équivalent, vous auriez le contrôle sur votre informatique, à supposer que le programme soit libre. Mais lorsque vous utilisez le service de quelqu’un d’autre pour faire la même chose, vous ne contrôlez plus rien.

Recourir au SaaS revient à utiliser un programme non libre avec des fonctionnalités de surveillance et une porte dérobée (backdoor) universelle. Donc vous devriez le refuser, et le remplacer par un logiciel libre qui fait la même chose.

En revanche, les fonctions principales de la plupart des services sont de communiquer et de publier des informations. Ils n’ont rien en commun avec un logiciel que vous exécuteriez vous-même, ce ne sont donc pas du SaaS. Ils ne peuvent pas non plus être remplacés par votre copie d’un programme, car un programme s’exécutant sur vos propres ordinateurs, utilisé uniquement par vous, n’est pas suffisant en lui-même pour communiquer avec d’autres personnes.

Les services non SaaS peuvent nuire à leurs utilisateurs d’autres manières. Les problèmes qui leur sont liés peuvent être aussi bien la mauvaise utilisation des données que vous leur avez envoyées, que la collecte d’autres données (surveillance). Le Franklin Street Statement^[2] a tenté d’aborder cette question, mais nous n’avons pas de position bien établie pour le moment. Ce qui est clair, c’est que les problèmes liés aux services sont différents de ceux qui concernent les programmes. Ainsi, par souci de clarté, il est préférable de ne pas appliquer les termes « libre » et « non libre » à un service.

Supposons qu’un service soit fourni par le biais d’un logiciel : l’opérateur du serveur a des copies de nombreux programmes, et les exécute pour fournir le service. Ces copies peuvent être des logiciels libres, ou non. Si c’est l’opérateur qui a développé les programmes, et qu’il les utilise sans en distribuer de copie, alors ils sont libres (sans que cela signifie grand chose) puisque tout utilisateur (il n’y en a qu’un) détient les quatre libertés.

Si certains programmes ne sont pas libres, cela n’affectera pas directement les utilisateurs du service. Ce ne sont pas eux qui exécutent ces programmes, c’est l’opérateur. Dans certaines situations bien particulières, ces programmes peuvent indirectement affecter les utilisateurs : si le service détient des informations confidentielles, ses utilisateurs peuvent s’inquiéter de la présence de portes dérobées dans les programmes non libres, permettant à d’autres d’accéder à leurs données. En fait, les programmes non libres du serveur obligent les utilisateurs à faire confiance à leurs développeurs ainsi qu’à l’opérateur du service. Le risque concret dépend de chaque cas particulier, et notamment de ce que font ces programmes non libres.

Cependant, il y a une personne qui est certainement affectée par les programmes non libres qui fournissent le service, c’est l’opérateur du serveur lui-même. Nous ne lui reprochons pas d’être à la merci de logiciels non libres, et nous n’allons certainement pas le boycotter pour ça. Au contraire, nous nous faisons du souci pour sa liberté, comme pour celle de tout utilisateur de logiciel non libre. Quand nous en avons l’occasion, nous essayons de lui expliquer qu’il met en péril sa liberté, en espérant qu’il bascule vers le logiciel libre.

Inversement, si un opérateur de service utilise GNU/Linux ou d’autres logiciels libres, ce n’est pas une bonne action, c’est tout simplement dans son intérêt. Nous n’allons pas l’encenser, ni le remercier, simplement nous le félicitons d’avoir fait le choix le plus avisé. S’il publie certains de ses logiciels libres, contribuant ainsi à faire avancer la communauté, là nous avons une raison de le remercier. Nous lui suggérons de diffuser ces programmes sous la GNU Affero GPL (Licence publique générale Affero de GNU), puisqu’ils sont destinés à des serveurs.

Pourquoi la GPL Affero ?

Ainsi, nous n’avons pas de règle qui dise que des systèmes libres ne devraient pas utiliser (ou s’appuyer sur) des services (ou des sites) fournis par le biais de logiciels non libres. Cependant, ils ne devraient pas dépendre de services de type SaaS, ni inciter à les utiliser. Les Saas doivent être remplacés par des logiciels libres. Et, toutes choses égales par ailleurs, il est préférable de privilégier les fournisseurs de service qui apportent leur contribution à la communauté en publiant des logiciels libres utiles. Il est également souhaitable de privilégier les architectures pair-à-pair plutôt que les communications centralisées reposant sur un serveur.

Parmi les nombreux front où est engagé le Libre il y a celui complexe, épineux et crucial des brevets logiciels (dossier suivi notamment chez nous par l’April).

Voici la position de Richard Stallman^[1], donnée lors d’une conférence en Nouvelle-Zélande.

Le danger des brevets logiciels

URL d’origine du document (GNU.org)

Richard Stallman – version du 24 avril 2012 – Gnu.org – Creative Commons By-Nd
(Traduction : Mathieu Adoutte en collaboration avec Framalang)

Retranscription de la conférence donnée par Richard M. Stallman le 8 octobre 2009 à l’Université Victoria de Wellington

SF : Je m’appelle Susy Frankel, et je tiens à vous souhaiter la bienvenue, en mon nom et en celui de Meredith Kolsky Lewis, à cette conférence organisée par le Centre de droit international des affaires de Nouvelle-Zélande. C’est à Brenda Chawner, membre de l’École de gestion de l’information de l’Université de Wellington (plutôt que du Centre que je viens de nommer, qui fait partie de la Faculté de droit) que revient le mérite d’avoir fait revenir Richard Stallman en Nouvelle-Zélande et d’avoir organisé son programme, notamment son étape de ce soir, ici à Wellington. Malheureusement, retenue par ses activités d’enseignement universitaire, elle n’a pu se joindre à nous.

C’est donc à moi que revient le plaisir de vous accueillir à cette conférence sur « Le danger des brevets logiciels ». Richard Stallman propose une série d’interventions sur différents sujets, et si nous avons choisi celui-ci, avec Brenda, c’est parce que pour la première fois dans l’histoire de la Nouvelle-Zélande, nous avons un débat qui tire un peu en longueur, mais qui est important, sur la réforme du droit des brevets, et vous êtes nombreux dans la salle à y participer. Cela nous a donc semblé particulièrement de circonstance. Merci, Richard, de nous avoir fait cette proposition.

On ne présente plus Richard Stallman. Néanmoins, pour ceux d’entre vous qui n’ont jamais entendu parler de lui, il a lancé le développement du système d’exploitation GNU. Je ne savais pas comment prononcer GNU, alors je suis allé sur Youtube (que ferions-nous sans Youtube)…

RMS : Oh, vous ne devriez pas promouvoir YouTube, ils diffusent leurs vidéos dans un format breveté.

SF : C’est vrai. Je l’évoquais seulement pour aborder ce point : doit-on prononcer G N U ou GNU ?

RMS : C’est sur Wikipedia. (GNU se prononce comme « gnou » en français)

SF : Oui, mais sur YouTube j’ai pu vous entendre le prononcer en direct. Le plus important néanmoins, c’est qu’il n’est pas propriétaire. Mais ce qui nous intéresse le plus, c’est que Richard a reçu de nombreuses distinctions pour son travail. Celle que je préfère, et par conséquent la seule que je mentionnerai, est le prix Takeda pour le progrès social et économique, et j’imagine que c’est bien de cela que nous allons parler ce soir. Je vous demande donc de vous joindre à moi pour accueillir Richard.

RMS : Avant tout, je voudrais préciser que l’une des raisons qui me poussent à boire ceci (une canette ou une bouteille de cola qui n’est pas du Coca-Cola) est qu’il y a un boycott mondial de la société Coca-Cola pour avoir assassiné des représentants syndicaux en Colombie. Consultez le site killercoke.org. Il ne s’agit pas des conséquences de la consommation du produit ; après tout, il en va de même pour beaucoup d’autres produits. Il s’agit de meurtre pur et simple. C’est pourquoi, avant d’acheter une boisson, lisez le texte en petits caractères pour vérifier si elle est fabriquée par Coca-Cola.

Je suis connu avant tout pour avoir initié le mouvement du logiciel libre et dirigé le développement du système d’exploitation GNU – bien que la plupart des personnes qui utilisent ce système croient à tort qu’il s’agit de Linux et pensent qu’il a été inventé par quelqu’un d’autre dix ans plus tard. Mais ce n’est pas de cela que je vais parler aujourd’hui. Je suis ici pour vous parler d’une menace juridique qui plane sur tous les développeurs, les utilisateurs et les éditeurs de logiciels : la menace des brevets – sur des idées informatiques, ou des techniques informatiques, c’est-à-dire des idées portant sur quelque chose de réalisable par un ordinateur.

Pour comprendre le problème, il faut tout d’abord prendre conscience du fait que le droit des brevets n’a rien à voir avec le copyright ; ce sont deux champs complètement différents. Vous pouvez être sûr que rien de ce que vous savez sur l’un ne s’applique à l’autre.

Par exemple, chaque fois que quelqu’un utilise le terme « propriété intellectuelle », il renforce la confusion, car ce terme mélange non seulement ces deux branches du droit, mais également une douzaine d’autres. Ces branches sont toutes différentes, et il en résulte que tout énoncé qui porte sur la « propriété intellectuelle » est parfaitement confus – soit parce que l’auteur de l’énoncé est lui-même confus, soit parce qu’il souhaite embrouiller les autres. Mais au final, que ce soit accidentel ou malveillant, cela accroît la confusion.

Vous pouvez échapper à cette confusion en refusant toute affirmation qui utilise ce terme. Pour porter le moindre jugement utile sur ces lois, il faut commencer par bien les distinguer, et les aborder séparément afin de comprendre quels sont réellement les effets de chacune, puis d’en tirer des conclusions. Je vais donc parler de brevets logiciels, et de ce qui se passe dans les pays qui ont autorisé le droit des brevets à restreindre les logiciels.

A quoi sert un brevet ? Un brevet est un monopole explicite sur l’utilisation d’une idée, attribué par un État. Tout brevet contient une partie intitulée les revendications, qui décrit précisément ce que vous n’avez pas le droit de faire (bien qu’elles soient généralement rédigées en des termes que vous ne pouvez probablement pas comprendre). Il faut lutter pour trouver ce que signifient exactement ces interdictions, et il peut y en avoir plusieurs pages en petits caractères.

Un brevet dure habituellement 20 ans, ce qui représente une durée relativement longue dans notre domaine. Il y a 20 ans, le World Wide Web n’existait pas – le secteur qui concentre aujourd’hui l’essentiel des usages de l’ordinateur n’existait pas il y a 20 ans. Et évidemment, si l’on compare avec l’informatique d’il y a 20 ans, tout ce que les gens y font est nouveau, au moins partiellement. Si des brevets avaient été déposés à l’époque, nous n’aurions pas le droit de faire toutes ces choses que nous faisons aujourd’hui ; elles pourraient toutes nous être interdites, dans les pays qui ont été suffisamment stupides pour mettre en place ce système.

La plupart du temps, ceux qui décrivent le fonctionnement du système de brevet sont aussi ceux qui en tirent profit. Qu’il s’agisse d’avocats spécialisés dans le droit des brevets, ou de personnes travaillant pour l’Office des brevets ou pour une mégacorporation, ils veulent vous convaincre que ce système est bon.

The Economist a un jour décrit le système de brevet comme « une loterie chronophage ». Si vous avez déjà vu une publicité pour une loterie, vous comprenez comment ça marche : ils s’attardent sur les infimes chances de gain, et ils passent sous silence l’immense probabilité de perdre. De cette manière, ils donnent systématiquement une représentation faussée de la réalité, sans pour autant mentir explicitement.

Il en va de même pour le discours sur le système des brevets : on vous parle de ce qui se passe lorsque vous avez un brevet dans la poche, et que de temps en temps vous pouvez le mettre sous le nez de quelqu’un en lui disant : « File-moi ton argent. »

Pour rectifier cette distorsion, je vais vous décrire l’envers du décor, le point de vue de la victime – ce qui se passe pour ceux qui veulent développer ou publier ou utiliser un logiciel. Vous vivez dans la crainte qu’un jour quelqu’un vienne et brandisse un brevet en vous disant : « File-moi ton argent. »

Si vous voulez développer des logiciels dans un pays qui reconnaît les brevets logiciels, et que vous souhaitez respecter le droit des brevets, que devez-vous faire ?

Vous pourriez tenter de faire une liste de toutes les idées qu’on peut trouver dans le programme que vous allez écrire. Mais évidemment, lorsque vous commencez juste à écrire le programme, vous n’avez aucune idée de ce qui va y figurer. Et même après avoir terminé le programme, vous seriez bien incapable de dresser une telle liste.

Cela tient au fait que vous avez conçu le programme avec une approche bien spécifique. Votre approche est déterminée par votre structure mentale, et de ce fait vous n’êtes pas capable de percevoir les structures mentales qui permettraient à d’autres personnes de comprendre le même programme ; il vous manque un œil neuf. Vous avez conçu le programme avec une structure spécifique à l’esprit ; quelqu’un d’autre qui découvre le programme pourrait l’aborder avec une structure différente, reposant sur d’autres idées, et vous n’êtes pas en mesure de dire quelles pourraient être ces idées. Il n’en reste pas moins que ces idées sont mises en œuvre dans votre programme, et que si l’une d’entre elles est brevetée, votre programme peut être interdit.

Imaginons par exemple qu’il existe des brevets sur les idées graphiques, et que vous vouliez dessiner un carré. Il est facile de comprendre que s’il existe un brevet sur les traits horizontaux, vous ne pouvez pas dessiner un carré. Le trait horizontal fait partie des idées mises en œuvre dans votre dessin. Mais vous n’avez peut-être pas pensé au fait que quelqu’un avec un brevet sur les coins pointant vers le bas peut aussi vous poursuivre, parce qu’il peut prendre votre dessin, et le tourner de 45 degrés. Et maintenant, votre carré a un coin vers le bas.

Vous ne pourrez donc jamais faire une liste de toutes les idées qui, si elles étaient brevetées, vous empêcheraient de réaliser votre programme.

Ce que vous pouvez faire, c’est tenter de lister toutes les idées déjà brevetées qui pourraient figurer dans votre programme. En fait non, vous ne pouvez pas, car les demandes de brevet sont gardées secrètes pendant au moins 18 mois, il est donc possible qu’un brevet ait été déposé à l’Office des brevets sans que personne n’en sache rien. Et il ne s’agit pas d’une hypothèse théorique.

Par exemple, en 1984 a été écrit compress, un programme permettant de compresser des fichiers en utilisant l’algorithme de compression de données LZW. À l’époque, il n’y avait pas de brevet sur cet algorithme de compression. L’auteur du programme avait récupéré l’algorithme dans un article de revue. C’était l’époque où nous pensions encore que les revues de recherche informatique servaient à publier des algorithmes pour que tout le monde puisse les utiliser.

Il a écrit ce programme, l’a publié, et en 1985 un brevet a été accordé pour cet algorithme. Le titulaire du brevet a été malin, il n’est pas allé tout de suite voir les gens pour leur dire de cesser d’utiliser le brevet. Il s’est dit : « Laissons-les creuser leur tombe un peu plus. » Quelques années plus tard, il a commencé à menacer les gens. Il est devenu évident que nous ne pouvions plus utiliser compress, j’ai donc demandé à tout le monde de proposer d’autres algorithmes que nous pourrions utiliser pour compresser des fichiers.

Quelqu’un m’a écrit pour me dire : « J’ai conçu un autre algorithme de compression qui marche encore mieux, j’ai écrit un programme, j’aimerais t’en faire cadeau. » Une semaine avant de le publier, je tombe sur la rubrique « brevets » du New-York Times, que je consulte rarement – je ne la regarde pas plus de deux fois par an – et je peux y lire que quelqu’un a obtenu un brevet pour une « nouvelle méthode de compression des données ». Je me suis donc dit qu’il valait mieux vérifier, et en effet le brevet prohibait le programme que nous nous apprêtions à publier. Mais cela aurait pu être pire : le brevet aurait pu être accordé un an plus tard, ou deux, ou trois, ou cinq.

Toujours est-il que quelqu’un a fini par trouver un algorithme de compression encore meilleur, qui a servi pour le programme gzip, et tous ceux qui avaient besoin de compresser des fichiers sont passés à gzip. Ça pourrait ressembler à un happy end, mais comme je vous l’expliquerai tout à l’heure, tout n’est pas si parfait.

Il n’est donc pas possible de savoir quels sont les brevets en cours d’examen, même si l’un d’eux peut entraîner l’interdiction de votre travail lorsqu’il sera publié. Mais il est toutefois possible de connaître les brevets déjà attribués. Ils sont tous publiés par l’Office des brevets. Le seul problème, c’est que vous ne pourrez jamais les lire tous, il y en a beaucoup trop.

Il doit y avoir des centaines de milliers de brevets logiciels aux États-Unis, les suivre tous constituerait une tâche écrasante. Vous allez donc devoir vous restreindre aux brevets pertinents. Et vous allez sans doute trouver de très nombreux brevets pertinents. Mais rien ne dit que vous allez les trouver tous.

Par exemple, dans les années 80 et 90, il existait un brevet sur le « recalcul dans l’ordre naturel » dans les tableurs. Quelqu’un m’en a demandé une copie un jour, j’ai donc regardé dans notre fichier qui liste les numéros de brevets. Puis j’ai ouvert le tiroir correspondant, j’ai récupéré la version papier du brevet, et je l’ai photocopiée pour la lui envoyer. Quand il l’a reçue, il m’a dit : « Je pense que tu t’es trompé de brevet, tu m’as envoyé un truc concernant les compilateurs. » Je me suis dit que peut-être le numéro de brevet était faux. J’ai vérifié, et de manière surprenante il faisait référence à une « méthode pour compiler des formules en code objet ». J’ai commencé à lire, pour voir s’il s’agissait du bon brevet. J’ai lu les revendications, et il s’agissait bien du brevet sur le recalcul dans l’ordre naturel, mais il n’utilisait jamais ce terme. Il n’utilisait jamais le mot « tableur ». En fait, ce que le brevet interdisait, c’était une douzaine de manières différentes d’implémenter un tri topologique – toutes les manières auxquelles ils avaient pu penser. Mais le terme « tri topologique » n’était pas utilisé.

Donc, si vous étiez par exemple en train de développer un tableur, et que vous ayez recherché les brevets pertinents, vous en auriez sans doute trouvé un certain nombre, mais pas celui-ci. Jusqu’à ce qu’un jour, au cours d’une conversation, vous disiez « Oh, je travaille sur un tableur », et que la personne vous réponde « Ah bon ? Tu es au courant que plusieurs autres entreprises qui font des tableurs sont en procès ? » C’est à ce moment-là que vous l’auriez découvert.

Certes, il est impossible de trouver tous les brevets en cherchant, mais on peut en trouver un bon nombre. Encore faut-il comprendre ce qu’ils veulent dire, ce qui n’a rien d’évident, car les brevets sont écrits dans un langage obscur dont il est difficile de saisir le véritable sens. Il va donc falloir passer beaucoup de temps à discuter avec un avocat hors de prix, à expliquer ce que vous voulez faire, afin que l’avocat puisse vous dire si vous avez le droit ou non.

Les détenteurs de brevets eux-mêmes sont bien souvent incapables de savoir ce que recouvrent leurs brevets. Par exemple, un certain Paul Heckel a conçu un programme pour afficher beaucoup de données sur un petit écran, et en s’appuyant sur une paire d’idées utilisées dans ce programme, il a obtenu deux brevets.

J’ai essayé un jour de trouver une manière simple d’exprimer ce que recouvrait la revendication numéro 1 de l’un de ces brevets. Je me suis rendu compte que je ne pouvais trouver d’autre formulation que celle du brevet lui-même. Or, j’avais beau tenter, il m’était impossible de me mettre cette formulation entièrement en tête.

Heckel non plus n’arrivait pas à suivre. Lorsqu’il a découvert HyperCard, il n’y a vu qu’un programme très différent du sien. Il ne s’est pas rendu compte que la formulation utilisée dans son propre brevet pouvait lui permettre d’interdire HyperCard. Mais ça n’a pas échappé à son avocat. Il a donc menacé Apple de poursuites. Puis il a menacé les clients d’Apple. Et finalement, Apple a conclu un arrangement avec lui, et comme cet arrangement est secret, il nous est impossible de savoir qui a vraiment gagné. Et ceci est juste un exemple parmi d’autres de la difficulté à comprendre ce qu’un brevet interdit ou non.

Lors d’une de mes précédentes conférences sur ce sujet, il se trouve qu’Heckel était présent dans le public. Arrivé à ce point de la conférence, il a bondi en s’écriant : « Tout ceci est faux ! C’est juste que j’ignorais l’étendue de ma protection. » Ce à quoi j’ai répondu : « Oui, c’est exactement ce que j’ai dit. » Il s’est rassis, mais si j’avais répondu non il aurait sans doute trouvé moyen de continuer la dispute.

Toujours est-il que si vous consultez un avocat, à l’issue d’une longue et coûteuse conversation il vous répondra sans doute quelque chose du genre :

Si vous faites quelque chose dans ce domaine-ci, vous êtes presque certain de perdre un procès, si vous faites quelque chose dans ce domaine-là, il y a une chance considérable de perdre un procès, et si vous voulez vraiment vous mettre à l’abri, ne touchez pas à tel et tel domaine. Ceci dit, en cas de procès, l’issue est largement aléatoire.

Alors, maintenant que vous avez des règles claires et prévisibles pour conduire vos affaires, que pouvez-vous vraiment faire ? En définitive, face à un brevet, il n’y a que trois actions possibles : soit vous l’évitez, soit vous obtenez une licence, soit vous le faites annuler. Je vais aborder ces points un par un.

Tout d’abord, il y a la possibilité d’éviter le brevet, ce qui signifie en clair : ne pas mettre en œuvre ce qu’il interdit. Bien sûr, comme il est difficile de dire ce qu’il interdit, il sera presque impossible de déterminer ce qu’il faut faire pour l’éviter.

Il y a quelques années, Kodak a poursuivi Sun pour infraction à l’un de ses brevets relatifs à la programmation orientée objet, et Sun contestait cette infraction. Le tribunal a fini par trancher qu’il y avait bel et bien infraction. Mais lorsqu’on examine le brevet, il est totalement impossible de dire si cette décision est fondée ou non. Personne ne peut vraiment dire ce que le brevet recouvre, mais Sun a quand même dû payer des centaines de millions de dollars pour avoir enfreint une règle complètement incompréhensible.

Parfois, cependant, il est possible de déterminer ce qui est interdit. Et il peut d’agir d’un algorithme.

J’ai ainsi vu un brevet sur quelque chose ressemblant à la « transformée de Fourier rapide », mais deux fois plus rapide. Si la TFR classique est suffisamment rapide pour vos besoins, vous pouvez facilement vous passer de ce brevet. La plupart du temps il n’y aura donc pas de problème. Mais il se peut qu’à l’occasion, vous souhaitiez faire un programme qui utilise constamment des TFR, et qui ne peut fonctionner qu’en utilisant l’algorithme le plus rapide. Là, vous ne pouvez pas l’éviter, ou alors vous pourriez attendre quelques années que les ordinateurs soient plus puissants. Mais bon, l’hypothèse reste exceptionnelle. La plupart du temps il est facile d’esquiver ce type de brevet.

Parfois, en revanche, il est impossible de contourner un brevet sur un algorithme. Prenez par exemple l’algorithme de compression de données LZW. Comme je vous l’ai dit, nous avons fini par trouver un meilleur algorithme de compression, et tous ceux qui veulent compresser des fichiers se sont mis à utiliser le programme gzip qui repose sur ce meilleur algorithme. Si vous voulez juste compresser un fichier et le décompresser plus tard, vous pouvez indiquer aux gens qu’ils doivent utiliser tel ou tel programme pour le décompresser ; au final vous pouvez utiliser n’importe quel programme basé sur n’importe quel algorithme, la seule chose qui vous importe c’est qu’il soit efficace

Mais LZW sert aussi à d’autres choses. Par exemple, le langage PostScript fait appel à des opérateurs de compression et de décompression LZW. Il serait inutile de faire appel à un autre algorithme, même plus efficace, car le format de données ne serait plus le même. Ces algorithmes ne sont pas interopérables. Si vous compressez avec l’algorithme utilisé dans gzip, vous ne pouvez pas décompresser avec LZW. En définitive, quel que soit votre algorithme et quelle que soit son efficacité, si ce n’est pas LZW, vous ne pourrez pas implémenter PostScript conformément aux spécifications.

Mais j’ai remarqué que les utilisateurs demandent rarement à leur imprimante de compresser des choses. En général, ils veulent seulement que leur imprimante soit capable de décompresser. Et j’ai aussi remarqué que les deux brevets sur l’algorithme LZW sont écrits de telle manière que si votre système ne fait que décompresser, alors ce n’est pas interdit. Ces brevets ont été formulés de manière à couvrir la compression, et ils contiennent des revendications portant sur la compression et la décompression, mais aucune revendication ne couvre la seule décompression. Je me suis donc rendu compte que si nous implémentions juste la décompression LZW, nous serions à l’abri. Et, bien que cela ne corresponde pas aux spécifications, cela répondrait largement aux besoins des utilisateurs. C’est ainsi que nous nous sommes faufilés entre les deux brevets.

Il y a aussi le format GIF, pour les images. Il fait également appel à l’algorithme LZW. Il n’a pas fallu longtemps pour que les gens élaborent un autre format de fichier, du nom de PNG, ce qui signifie « PNG N’est pas GIF ». Je crois qu’il utilise l’algorithme gzip. Et nous avons commencé à dire à tout le monde : « N’utilisez pas le format GIF, c’est dangereux. Passez à PNG. » Et les utilisateurs nous ont dit : « D’accord, on y pensera, mais pour l’instant les navigateurs ne l’implémentent pas. » Ce à quoi les développeurs de navigateurs ont répondu : « On l’implémentera un jour, mais pour l’instant il n’y a pas de demande forte de la part des utilisateurs. »

Il est facile de comprendre ce qui s’était passé : GIF était devenu un standard de fait. En pratique, demander aux gens d’abandonner leur standard de fait en faveur d’un autre format revient à demander à tout le monde en Nouvelle-Zélande de parler hongrois. Les gens vont vous dire : « Pas de problème, je m’y mets dès que tout le monde le parle. » Et au final nous ne sommes jamais parvenus à convaincre les gens d’arrêter d’utiliser GIF, en dépit du fait que l’un des détenteurs de brevets passe son temps à faire le tour des administrateurs de sites web en les menaçant de poursuites s’ils ne peuvent prouver que tous les GIF du site ont été réalisés avec un programme sous licence.

GIF était donc un piège dangereux menaçant une large part de notre communauté. Nous pensions avoir trouvé une alternative au format GIF, à savoir JPEG, mais quelqu’un – je crois qu’il s’agissait d’une personne ayant tout juste acheté des brevets dans le but d’exercer des menaces – nous a dit : « En regardant mon portefeuille de brevets, j’en ai trouvé un qui couvre le format JPEG. »

JPEG n’était pas un standard de fait. Il s’agissait d’un standard officiel, élaboré par un organisme de standardisation. Et cet organisme avait lui aussi un avocat, qui a dit qu’il ne pensait pas que le brevet couvre le format JPEG.

Alors, qui a raison ? Eh bien, le titulaire du brevet a poursuivi un groupe de sociétés, et s’il y avait eu une décision, on aurait pu savoir ce qu’il en était. Mais je n’ai jamais entendu parler de décision, et je ne suis pas sûr qu’il y en ait jamais eu. Je pense qu’ils ont conclu un règlement amiable, et ce règlement est probablement secret, ce qui signifie que nous ne saurons jamais qui avait raison.

Les cas dont j’ai parlé ici sont relativement modestes : un seul brevet en ce qui concerne JPEG, deux pour l’algorithme LZW utilisé pour GIF. Vous vous demandez peut-être pourquoi il y avait deux brevets sur le même algorithme. Normalement, cela n’est pas possible, pourtant c’est arrivé. Cela tient au fait que les personnes examinant les brevets n’ont pas le temps d’étudier et de comparer tout ce qui devrait l’être, parce que les délais sont très courts. Et comme les algorithmes ne sont au final que des mathématiques, il est impossible de limiter le choix de brevets et de demandes de brevets à comparer.

Vous voyez, dans le domaine industriel, ils peuvent se référer à ce qui se passe réellement dans le monde physique pour circonscrire les choses. Par exemple dans le domaine de l’ingénierie chimique, on peut se demander : « Quelles sont les substances utilisées ? Quelles sont les produits obtenus ? » Si deux demandes de brevet diffèrent sur ce point, il s’agit donc de deux inventions différentes, et il n’y a pas de problème. Mais en mathématiques, des choses identiques peuvent être présentées de manière très différentes, et à moins de les comparer en détail vous ne vous rendrez jamais compte qu’il s’agit d’une seule et même chose. Et, de ce fait, il n’est pas rare de voir la même chose être brevetée à plusieurs reprises dans le domaine du logiciel.

Vous vous souvenez de l’histoire de ce programme qui a été tué par un brevet avant même que nous ne l’ayons publié ? Eh bien, cet algorithme était également breveté deux fois. Donc, dans un domaine extrêmement réduit, nous avons déjà vu ce phénomène se produire à plusieurs reprises. Je pense vous avoir expliqué pourquoi.

Mais un ou deux brevets constituent une situation plutôt simple. Prenons MPEG-2, le format vidéo. J’ai vu une liste de plus de 70 brevets couvrant ce format, et les négociations pour permettre à quelqu’un d’obtenir une licence ont pris plus de temps que le développement du standard lui-même. Le comité JPEG voulait développer un nouveau standard plus moderne, ils ont fini par abandonner. Ce n’est pas faisable, ont-ils dit. Il y a trop de brevets.

Parfois, c’est carrément une fonctionnalité qui est brevetée, et la seule façon d’éviter le brevet consiste à ne pas implémenter cette fonctionnalité. Ainsi, les utilisateurs du logiciel de traitement de texte XyWrite ont une fois reçu par la poste une mise à jour supprimant une fonctionnalité. Il s’agissait de la possibilité de définir une liste d’abréviations. Par exemple, si vous définissiez qu’« exp » était l’abréviation d’« expérience », il suffisait de taper « exp-espace », ou « exp-virgule », pour qu’« exp » soit automatiquement remplacé par « expérience ».

Mais quelqu’un disposant d’un brevet sur cette fonctionnalité les a menacés, et ils ont conclu que la seule solution consistait à retirer cette fonctionnalité. Et ils ont envoyé à tous les utilisateurs une mise à jour la retirant.

Mais ils m’ont également contacté, car mon éditeur de texte Emacs proposait ce type de fonctionnalité depuis la fin des années 70. Et comme elle était décrite dans le manuel d’Emacs, ils espéraient que je pourrais les aider à faire tomber ce brevet. Je suis heureux de savoir que j’ai eu au moins une fois dans ma vie une idée qui soit brevetable, je regrette juste que ce soit quelqu’un d’autre qui l’ait brevetée.

Par chance, ce brevet fut finalement invalidé, en partie grâce au fait que j’avais publiquement annoncé un usage antérieur de cette fonctionnalité. Mais en attendant, ils ont dû retirer la fonctionnalité.

Retirer une ou deux fonctionnalités, ce n’est pas une catastrophe. Mais quand il s’agit de 50 fonctionnalités, les gens vont finir par dire : « Ce programme n’est pas bon, il lui manque toutes les fonctionnalités qui m’intéressent. » Ce n’est donc pas une solution viable. Et parfois un brevet est si général qu’il balaie un champ entier, comme par exemple le brevet sur le chiffrement par clé publique, qui interdit de fait tout chiffrement par clé publique pendant 10 ans.

Voilà pour la possibilité d’esquiver un brevet. C’est souvent possible, mais pas toujours, et il y a une limite au nombre de brevets qu’il est possible d’éviter.

Qu’en est-il de la deuxième solution, obtenir une licence pour le brevet ?

Le titulaire du brevet n’est pas tenu de vous accorder une licence. Cela ne dépend que de lui. Il peut très bien dire : « Je veux juste vous couler. » Une fois, j’ai reçu une lettre de quelqu’un dont l’entreprise familiale avait pour activité la création de jeux de casino, qui étaient bien sûr informatisés, et il avait été menacé par un titulaire de brevet qui voulait lui faire mettre la clé sous la porte. Il m’a envoyé le brevet. La revendication numéro 1 ressemblait à quelque chose du genre « un réseau de plusieurs ordinateurs contenant chacun plusieurs jeux et qui permet plusieurs parties simultanément ».

Je suis à peu près sûr que dans les années 80, il existait une université avec des stations de travail en réseau, dotées d’un quelconque système de fenêtrage. Il aurait suffi qu’ils installent plusieurs jeux pour qu’il soit possible d’afficher plusieurs parties simultanément. Il s’agit de quelque chose de tellement trivial et d’inintéressant que jamais personne ne se serait donné la peine d’écrire un article à ce sujet. Ce n’était pas assez intéressant pour constituer un article, mais ça l’était suffisamment pour constituer un brevet. Si vous avez compris que vous pouvez obtenir un monopole sur cette opération triviale, vous pouvez faire fermer vos concurrents.

Mais pourquoi est-ce que l’Office des brevets accorde tant de brevets qui nous semblent absurdes et triviaux ?

Ce n’est pas parce que les examinateurs de brevets sont stupides. C’est parce qu’ils suivent un processus, que ce processus est régi par des règles, et que ces règles aboutissent à ce résultat.

Vous voyez, si quelqu’un a construit une machine qui fait quelque chose une seule fois, et que quelqu’un d’autre construit une machine qui fait la même chose, mais N fois, pour nous il s’agit juste d’une boucle for, mais pour l’Office des brevets il s’agit d’une invention. S’il y a des machines qui peuvent faire A, et des machines qui peuvent faire B, et que quelqu’un conçoit une machine qui peut faire A ou B, pour nous il s’agit d’une condition if-then-else (si-alors-sinon), mais pour l’Office des brevets, il s’agit d’une invention. Ils ont des conditions très peu restrictives, et ils s’en tiennent à ces conditions, et il en découle des brevets qui, pour nous, semblent absurdes et triviaux. Qu’ils soient juridiquement valides, je n’en sais rien. Mais n’importe quel programmeur rigole en les voyant.

Toujours est-il que je n’ai rien pu lui proposer pour se défendre, il a donc dû fermer boutique. Mais la plupart des détenteurs de brevets vous proposeront une licence, qui est susceptible de vous coûter très cher.

Cependant certains développeurs de logiciels n’ont pas grand mal à obtenir des licences, la plupart du temps. Il s’agit des mégacorporations. Quel que soit le domaine, les mégacorporations possèdent en général la moitié des brevets, elles s’accordent entre elles des licences croisées, et elles peuvent contraindre qui que ce soit d’autre à leur accorder des licences croisées. Au final, elles obtiennent sans trop de mal des licences pour quasiment tous les brevets.

IBM a écrit un article à ce sujet dans son magazine interne, Think – dans le numéro 5 de 1990, je crois – décrivant les avantages qu’IBM tirait de son portefeuille de près de 9 000 brevets américains (c’était à l’époque, maintenant ils en ont plus de 45 000). L’un de ces avantages, disaient-ils, est qu’ils en tiraient des revenus, mais ils soulignaient que le principal avantage – d’un ordre de grandeur supérieur – était « l’accès aux brevets des autres », par le biais des licences croisées.

Cela veut dire que puisque qu’IBM, avec sa pléthore de brevets, peut contraindre n’importe qui à lui accorder des licences croisées, cette entreprise échappe à tous les problèmes que le système de brevets cause à toutes les autres. Et c’est pour cela qu’IBM est favorable aux brevets logiciels. C’est pour cela que les mégacorporations sont dans leur ensemble favorable aux brevets logiciels : parce qu’elles savent que par le jeu des licences croisées, elles feront partie d’un petit club très fermé, assis au sommet de la montagne. Et nous, nous serons tout en bas, et il n’y aura aucun moyen de grimper. Vous savez, si vous êtes un génie, vous pouvez fonder votre petite entreprise, et obtenir quelques brevets, mais vous ne jouerez jamais dans la même catégorie qu’IBM, quels que soient vos efforts.

Beaucoup d’entreprises disent à leurs salariés : « Décrochez-nous des brevets, c’est juste pour que nous puissions nous défendre. » Et ce qu’elles veulent dire, c’est : « Nous les utiliserons pour obtenir des licences croisées. » Mais en fait ça ne marche pas. Ce n’est pas une stratégie efficace si vous n’avez qu’un petit nombre de brevets.

Imaginons par exemple que vous ayez trois brevets. L’un concerne ceci, l’autre concerne cela, et soudain quelqu’un vous brandit son brevet sous le nez. Vos trois brevets ne vont servir à rien, car aucun d’entre eux ne concerne cette personne. En revanche, tôt ou tard, quelqu’un dans votre entreprise va se rendre compte que votre brevet concerne d’autres entreprises, et va l’utiliser pour les menacer et leur extorquer de l’argent, quand bien même ces entreprises n’ont pas attaqué la vôtre.

Donc, si votre employeur vous dit « Nous avons besoin de brevets pour nous défendre, aidez-nous à en obtenir », je vous conseille de répondre ceci :

Chef, je vous fais confiance, et je suis certain que vous n’utiliserez ces brevets que pour défendre l’entreprise en cas d’attaque. Mais je ne sais pas qui sera à la tête de l’entreprise dans 5 ans. Pour autant que je sache, elle peut se faire racheter par Microsoft. Je ne peux donc pas compter sur la promesse de l’entreprise de n’utiliser ces brevets que de manière défensive, sauf si elle s’engage par écrit. Commencez par vous engager par écrit à ce que tout brevet que je fournis à l’entreprise ne soit utilisé qu’en cas de légitime défense, et jamais de manière agressive, et alors je serai en mesure d’apporter des brevets à l’entreprise en ayant la conscience tranquille.

Il serait intéressant d’aborder ce problème sur la liste de diffusion de l’entreprise, et pas seulement en privé avec votre patron.

L’autre chose qui peut arriver, c’est que la société fasse faillite et que ses actifs soient liquidés, brevets compris, et que ces brevets soient rachetés par quelqu’un qui les utilise à des fins peu scrupuleuses.

Il est fondamental de comprendre cette pratique des licences croisées, car c’est elle qui permet de détruire l’argument des promoteurs du brevet logiciel selon lequel les brevets sont nécessaires pour protéger les pauvres petits génies. Ils vous présentent une histoire cousue d’invraisemblances.

Jetons-y un œil. Dans leur histoire, un brillant concepteur de ce-que-vous-voulez, qui a travaillé des années tout seul dans son grenier, a découvert une meilleure technique pour faire un-truc-important. Et maintenant que cette technique est au point, il veut se lancer dans les affaires et produire ce-truc-important en série, et comme son idée est géniale, son entreprise va forcément réussir. Problème : les grandes entreprises vont lui faire une concurrence acharnée et lui voler tout son marché. Et du coup, son entreprise va couler et il se retrouvera sur la paille.

Examinons les hypothèses fantaisistes que l’on trouve ici.

Tout d’abord, il est peu probable qu’il ait eu son idée géniale tout seul. Dans le domaine des hautes technologies, la plupart des innovations reposent sur une équipe travaillant dans un même domaine, et échangeant avec des gens de ce domaine. Mais pour autant, ce n’est pas impossible en soi.

L’hypothèse suivante est qu’il va se lancer dans les affaires, et qu’elles vont bien marcher. Le fait qu’il soit un ingénieur brillant n’implique en rien que ce soit un bon homme d’affaire. La plupart des entreprises – 95%, je crois – font faillite au cours des premières années. Donc peu importe le reste, c’est ce qui risque de lui arriver.

Bon, mais imaginons qu’en plus d’être un ingénieur brillant, qui a découvert quelque chose de génial tout seul dans son coin, ce soit aussi un homme d’affaire de génie. S’il est doué pour les affaires, son entreprise s’en sortira peut-être. Après tout, toutes les nouvelles entreprises ne coulent pas, un certain nombre prospèrent. S’il a le sens des affaires, peut-être qu’au lieu d’affronter les grandes entreprises sur leur terrain, il tentera de se placer là où les petites entreprises sont plus performantes et peuvent réussir. Il y parviendra peut-être. Mais supposons qu’il finisse par échouer. S’il est vraiment brillant, et qu’il est doué pour les affaires, je suis certain qu’il ne mourra pas de faim, parce que quelqu’un voudra l’embaucher.

Tout ceci ne tient pas debout. Mais poursuivons.

On arrive au moment où le système des brevets va « protéger » notre pauvre petit génie, parce qu’il va pouvoir breveter sa technique. Et quand IBM va venir lui faire concurrence, il va dire : « IBM, vous n’avez pas le droit de me faire concurrence, j’ai un brevet. » Et IBM va dire : « Oh non, encore un brevet ! »

Voilà ce qui va vraiment se passer :

IBM va dire : « Oh, comme c’est mignon, vous avez un brevet. Eh bien nous, nous avons celui-ci, et celui-ci, et celui-ci, et celui-ci, et ils couvrent tous d’autres idées implémentées dans votre produit, et si vous pensez que vous pouvez vous battre avec nous sur tous ceux-là, nous en sortirons d’autres. Donc, nous allons signer un accord de licences croisées, et personne ne sera lésé. » Comme notre génie est doué pour les affaires, il va vite se rendre compte qu’il n’a pas le choix. Il va signer un accord de licences croisées, comme le font tous ceux à qui IBM le demande. Ce qui veut dire qu’IBM va avoir « accès » à son brevet, et pourra donc lui faire librement concurrence comme si le brevet n’existait pas, ce qui signifie au final que l’hypothétique protection dont il bénéficie au travers de son brevet n’est qu’un leurre. Il ne pourra jamais en bénéficier.

Le brevet le « protégera » peut-être de concurrents comme vous et moi, mais pas d’IBM, pas des mégacorporations qui, dans la fable, sont justement celles qui le menacent. De toute façon, lorsque des mégacorporations envoient leurs lobbyistes défendre une législation qui est censée protéger leurs petits concurrents contre leur influence, vous pouvez être sûr que l’argumentation va être biaisée. Si c’était vraiment ce qui allait se passer, elles seraient contre. Mais ça permet de comprendre pourquoi les brevets logiciels ne marchent pas.

Même IBM ne peut pas toujours se comporter ainsi. Certaines entreprises, que l’on appelle parfois des « trolls des brevets », ont pour seul modèle économique d’utiliser les brevets pour soutirer de l’argent à ceux qui produisent réellement quelque chose.

Les avocats spécialisés en droit des brevets nous expliquent à quel point il est merveilleux que notre domaine ait des brevets. Mais il n’y a pas de brevet dans le leur. Il n’y a pas de brevet sur la manière d’envoyer ou de rédiger une lettre de menaces, pas de brevet sur comment déposer un recours, pas de brevet sur comment convaincre un juge ou un jury. Ainsi donc, même IBM ne peut contraindre un troll des brevets à accepter des licences croisées. Mais IBM se dit : « Nos concurrents vont devoir payer eux aussi, cela fait partie des charges incompressibles, on peut s’en accommoder. » IBM et les autres mégacorporations considèrent que la suprématie qu’elles retirent de leurs brevets sur l’ensemble de leur activité vaut bien d’avoir à payer quelques parasites. C’est pour cela qu’elles défendent les brevets logiciels.

Il existe aussi certains développeurs de logiciels qui ont beaucoup de mal à obtenir des licences, ce sont les développeurs de logiciels libres. Cela tient au fait que les licences contiennent généralement des conditions que nous sommes dans l’impossibilité de remplir, comme par exemple le paiement pour chaque exemplaire distribué. Lorsque les utilisateurs sont libres de copier le logiciel et de distribuer les copies, personne ne peut connaître le nombre de copies en circulation.

Si quelqu’un me propose une licence pour un brevet au prix d’un millionième de dollar par exemplaire distribué, il se peut que j’aie de quoi payer. Mais je n’ai aucun moyen de savoir si cela représente 50 dollars, ou 49, ou un autre montant, car je n’ai aucun moyen de compter le nombre de copies que les gens ont faites.

Un titulaire de brevet n’est pas obligé de demander le paiement en fonction du nombre d’exemplaires distribués. Il peut très bien proposer une licence pour un montant fixe, mais ce montant a tendance à être très élevé, du type 100 000 $.

Or, si nous avons pu développer tant de logiciels respectueux des libertés, c’est parce que nous pouvons développer des logiciels sans argent. Mais nous ne pouvons pas payer sans argent. Si nous sommes obligés de payer pour avoir le privilège d’écrire des logiciels pour le public, nous risquons de ne pas en faire beaucoup.

Voilà pour la possibilité d’obtenir une licence pour un brevet. La dernière solution consiste à faire annuler le brevet. Si le pays reconnaît les brevets logiciels et les autorise, la seule question est de savoir si tel ou tel brevet respecte bien les conditions de validité. Aller devant les juges ne sert à rien si vous n’avez pas un argument solide qui vous permettra de l’emporter.

De quel argument peut-il s’agir ? Il faut apporter la preuve que, bien avant que le brevet ne soit déposé, d’autres personnes avaient eu la même idée. Et il faut trouver des preuves aujourd’hui qui montrent que l’idée était publique à l’époque. Ainsi, les dés ont été jetés des années plus tôt, et s’ils vous sont favorables, et si vous êtes en mesure d’apporter cette preuve aujourd’hui, alors vous disposez d’un argument qui peut vous permettre de contester le brevet et d’obtenir son annulation. Ça peut marcher.

Ce genre d’affaire peut coûter cher. De ce fait, un brevet probablement invalide constitue malgré tout un moyen de pression très efficace si vous n’avez pas beaucoup d’argent. Beaucoup de gens n’ont pas les moyens de défendre leurs droit. Ceux qui peuvent se le permettre constituent l’exception.

Voilà les trois possibilités qui peuvent se présenter à vous, chaque fois qu’un brevet interdit quelque chose dans votre programme. Toutes ne sont pas toujours ouvertes, cela dépend de chaque cas particulier, et parfois aucune d’entre elles n’est envisageable. Lorsque cela se produit, votre projet est condamné.

Mais dans la plupart des pays les avocats nous conseillent de « ne pas rechercher d’avance les brevets », la raison étant que les sanctions pour infraction à un brevet sont plus importantes s’il est établi que l’on avait connaissance de l’existence du brevet. Ce qu’ils nous disent, c’est : « Gardez les yeux fermés. N’essayez pas de vous renseigner sur les brevets, décidez de la conception de votre programme en aveugle, et priez. »

Évidemment, vous ne marchez pas sur un brevet à chaque étape de la conception. Il ne va probablement rien vous arriver. Mais il y a tellement de pas à faire pour traverser le champ de mines qu’au final il est peu probable que vous y arriviez sans encombre. Et bien sûr, les titulaires de brevet ne se présentent pas tous au même moment, de sorte que vous ne pouvez jamais savoir combien il y en aura.

Le titulaire du brevet sur le recalcul dans l’ordre naturel demandait 5% du montant brut de chaque tableur vendu. Il n’est pas inconcevable de payer quelques licences de ce type, mais que faire quand le titulaire de brevet n° 20 se présente, et vous demande les 5 derniers pourcent ? Ou le titulaire du brevet n° 21 ?

Les professionnels du secteur trouvent cette histoire amusante, mais absurde, car dans la réalité votre activité s’écroule bien avant d’en arriver là. Il suffit de deux ou trois licences de ce type pour couler votre entreprise. Vous n’arriveriez jamais à 20. Mais comme ils se présentent un par un, vous ne pourrez jamais savoir combien il y en aura.

Les brevets logiciels sont un immense gâchis. Non seulement ils constituent une jungle pour les développeurs de logiciels, mais en plus ils restreignent la liberté de chaque utilisateur d’ordinateur, car chaque brevet logiciel restreint ce que vous pouvez faire avec un ordinateur.

La situation est très différente de celle des brevets sur les moteurs de voiture, par exemple. Ces brevets n’affectent que les entreprises qui fabriquent des voitures, ils ne restreignent pas votre liberté ni la mienne. Mais les brevets logiciels touchent tous ceux qui utilisent un ordinateur. Il est donc impossible de les examiner sous un angle purement économique. Cette question ne peut pas être tranchée en termes purement économiques. Quelque chose de plus fondamental est en jeu.

Mais même sur le plan purement économique, le système est contre-performant, car sa raison d’être originelle est de promouvoir l’innovation. L’idée était qu’en créant une incitation artificielle à rendre une idée publique, cela stimulerait l’innovation. Au final c’est exactement l’inverse qui se produit, car l’essentiel du travail de fabrication d’un logiciel n’est pas d’inventer des idées nouvelles, mais de mettre en œuvre, conjointement dans un seul programme, des milliers d’idées différentes. Et c’est ce que les brevets logiciels empêchent de faire, et en cela ils sont économiquement contre-performants.

Il existe même des études économiques qui le prouvent, et qui montrent comment, dans un domaine où la plupart des innovations sont incrémentales, un système de brevets peut en réalité diminuer les investissements en recherche et développement. Et ils entravent l’innovation de bien d’autres manières. Donc, même si on laisse de côté le fait que les brevets logiciels sont injustes, même si l’on s’en tient à une approche purement économique, les brevets restent néfastes.

Parfois, les gens nous répondent : « Les autres disciplines vivent avec les brevets depuis des décennies et elles s’y sont faites, pourquoi faudrait-il faire une exception pour vous ? »

Cette question repose sur un présupposé absurde. Cela revient à dire « D’autres personnes ont un cancer, pourquoi pas vous ? » De mon point de vue, chaque fois qu’une personne évite un cancer, c’est une bonne chose, quel que soit le sort des autres. Cette question est absurde, parce qu’elle sous-entend qu’il faudrait que nous souffrions tous des dommages causés par les brevets.

Mais elle contient implicitement une questions qui, elle, est pertinente : « Existe-t-il des différences entre les disciplines telles qu’un bon système de brevets pour l’une peut être mauvais pour l’autre ? »

Or il existe une différence fondamentale entre disciplines, quant au nombre de brevets nécessaires pour bloquer ou couvrir un produit donné.

Je suis en train d’essayer de nous débarrasser d’une représentation simpliste mais fréquente, qui voudrait qu’à chaque produit corresponde un brevet, et que ce brevet couvre la structure générale du produit. Selon cette idée, si vous concevez un nouveau produit, il est impossible qu’il soit déjà breveté, et vous pourrez tenter d’obtenir « le brevet » pour ce produit.

Ce n’est pas ainsi que les choses fonctionnent. Ou peut-être au XIXe siècle, mais plus aujourd’hui. En fait, chaque discipline peut être placée sur une échelle représentant le nombre de brevets par produit. Tout en bas de l’échelle, il suffit d’un brevet pour couvrir un produit, mais il n’existe plus de discipline qui fonctionne ainsi aujourd’hui ; les disciplines sont à divers niveaux de l’échelle.

Le secteur qui serait le plus bas sur l’échelle serait l’industrie pharmaceutique. Il y a quelques dizaines d’années, il y avait réellement un brevet par médicament, à un instant donné tout du moins, car le brevet portait sur l’ensemble de la formule chimique correspondant à une substance donnée. À l’époque, si vous aviez développé un nouveau médicament, vous pouviez être certain qu’il n’était pas déjà breveté par quelqu’un d’autre, et vous pouviez obtenir un brevet correspondant à ce médicament particulier.

Mais ce n’est plus comme ça que ça marche. Il y a désormais des brevets très généraux, de sorte que même si vous mettez au point une nouvelle molécule, il se peut qu’elle soit interdite parce qu’elle est couverte par un brevet plus large.

Il se peut qu’il y ait deux ou trois brevets de ce type qui couvrent votre molécule, mais il n’y en aura pas des centaines. Cela tient au fait que nos capacités dans le domaine de la biochimie sont si limitées que personne n’est capable de combiner autant d’idées différentes dans une seule molécule qui serait utilisable en médecine. Si vous parvenez à en combiner deux, c’est déjà un exploit, pour notre niveau de connaissances. Mais dans les autres disciplines il n’est pas rare de combiner un plus grand nombre d’idées pour réaliser une seule chose.

Les logiciels se situent tout en haut de l’échelle. Un logiciel repose sur la combinaison de plus d’idées que n’importe quel autre produit, du fait essentiellement que notre discipline est plus simple que les autres. Je prends pour hypothèse que l’intelligence des gens travaillant dans notre domaine vaut celle de ceux travaillant sur le monde physique. Nous ne sommes pas meilleurs qu’eux, c’est juste que notre discipline est fondamentalement plus simple que la leur, car nous travaillons avec les mathématiques.

Un programme est fait d’éléments mathématiques, qui ont tous une définition, alors que les objets physiques n’ont pas de définition. La matière se comporte comme elle se comporte, et parfois elle est perverse, et votre invention ne fonctionne pas comme elle était « censée » fonctionner. Pas de chance. Vous ne pouvez pas prétendre que c’est parce que la matière est boguée, et qu’il faudrait patcher l’univers physique. Alors que nous, les programmeurs, nous pouvons construire un édifice qui repose sur une ligne mathématique d’épaisseur nulle, et il tiendra debout car rien ne pèse rien.

Nous n’avons pas à affronter toutes les complications du monde physique.

Par exemple, quand je mets une condition if (si) à l’intérieur d’une boucle while (tant que),

• je n’ai pas à craindre que si cette boucle while se répète à la mauvaise fréquence, la condition if entre en résonance et se brise ;
• je n’ai pas à me préoccuper du fait que si elle boucle trop rapidement (disons des millions de fois par seconde), elle est susceptible de générer des signaux électromagnétiques qui pourraient fausser les valeurs ailleurs dans le programme ;
• je n’ai pas à craindre que des fluides corrosifs présents dans l’environnement s’infiltrent entre le if et le while, et commencent à les ronger, jusqu’à ce que le signal ne passe plus.
• je n’ai pas à me demander comment la chaleur générée par mon if va pouvoir s’évacuer via mon while pour ne pas qu’il grille ; et
• je n’ai pas à me demander comment je vais pouvoir démonter et remplacer le if, s’il fini par se briser, par griller ou par se corroder, afin de remettre le programme en état de marche.

Je n’ai même pas à me demander comment je vais pouvoir insérer le if dans le while pour chaque exemplaire du programme. Je n’ai pas besoin de concevoir une usine pour fabriquer des copies de mon programme, car il existe un certain nombre de commandes générales qui permettent de copier tout et n’importe quoi.

Si je veux graver des copies sur CD, il me suffit de préparer une image, et il existe pour ce faire un programme, qui me permet de réaliser une image à partir de n’importe quelles données. Je peux graver un CD et l’envoyer à une usine, qui se chargera de dupliquer ce que je lui envoie. Je n’ai pas besoin de concevoir une usine différente pour chaque chose que je veux reproduire.

Or, dans l’ingénierie physique, c’est bien souvent ce que vous devez faire. Vous devez concevoir vos produits de sorte qu’ils puissent être fabriqués. Et il est encore plus compliqué de concevoir l’usine que de concevoir le produit, et il faut ensuite dépenser des millions de dollars pour construire l’usine. Avec toutes ces contraintes, vous n’allez pas pouvoir concevoir un produit qui réunisse beaucoup d’idées différentes et qui fonctionne.

Un objet physique composé d’un million d’éléments uniques représente un projet titanesque. Un programme composé d’un million d’éléments différents, ce n’est rien. Cela représente quelques centaines de milliers de lignes de code, soit quelques années de travail pour un petit groupe de personnes, donc ce n’est pas énorme. En conséquence, le système de brevets pèse beaucoup plus lourdement sur notre discipline que sur toutes celles qui sont freinées par la perversité de la matière.

Un avocat a réalisé une étude portant sur un programme particulièrement volumineux, à savoir le noyau Linux, qui est utilisé conjointement au système d’exploitation GNU que j’ai lancé. C’était il y a 5 ans ; il a trouvé 283 brevets américains qui apparemment interdisent chacun un type de calcul présent quelque part dans le code de Linux. A l’époque, j’ai lu quelque part que Linux représentait 0,25% de l’ensemble du système. Donc, si vous multipliez ce chiffre par 300 ou 400, vous obtenez une estimation du nombre de brevets qui sont susceptibles d’interdire quelque chose dans l’ensemble du système, soit à peu près 100 000. Il s’agit d’une estimation très approximative, mais nous n’avons aucune information plus précise, car le seul fait de chercher à savoir représenterait une tâche titanesque.

Cet avocat n’a pas publié la liste des brevets, de peur que cela n’expose les développeurs du noyau Linux à des sanctions plus importantes en cas de litige. Il ne cherchait pas à les mettre en difficulté, il voulait juste démontrer la gravité du problème que représente l’inflation des brevets.

Les programmeurs comprennent tout de suite de quoi il s’agit, mais les politiciens ne comprennent pas grand chose à l’informatique. Ils s’imaginent que les brevets ressemblent à une version renforcée du droit d’auteur. Ils s’imaginent que puisque les développeurs ne sont pas menacés par le droit d’auteur sur leur travail, ils ne seront pas menacés non plus par les brevets. Ils s’imaginent que puisque vous obtenez un droit d’auteur lorsque vous écrivez un programme, vous pourriez aussi bien obtenir un brevet. C’est complètement faux. Comment leur faire comprendre l’effet qu’auraient les brevets ? L’effet qu’ils ont, dans des pays comme les États-Unis ?

J’ai souvent recours à une analogie entre les programmes et les symphonies. Voici pourquoi :

Une symphonie, comme un programme, combine de nombreuses idées. Une symphonie combine de nombreuses idées musicales. Mais il ne suffit pas de choisir une série d’idées et de dire : « Voilà ma combinaison d’idées, ça vous plaît ? » Pour que cela fonctionne, il faut les implémenter. Vous ne pouvez pas juste dresser une liste d’idées musicales, et demander « Ça vous plaît ? », car on ne peut pas entendre cette liste. Il faut écrire des notes, qui représentent la conjonction de ces idées.

Le plus difficile est de choisir des notes qui donnent un résultat final harmonieux ; la plupart d’entre nous en est incapable. Bien sûr, nous sommes tous capables de choisir des idées musicales dans une liste, mais nous serions bien en peine d’écrire une symphonie qui rassemble harmonieusement ces idées. Seuls quelques-uns d’entre nous ont ce talent. C’est cela qui nous limite. Je pourrais probablement inventer quelques idées musicales, mais je ne saurais pas comment en tirer quoi que ce soit.

Imaginez que nous sommes au XVIIIe siècle, et que les gouvernements européens décident de mettre en place un système de brevets sur les idées musicales pour promouvoir l’innovation dans le domaine de la musique symphonique, et que n’importe quelle idée musicale décrite sous forme de mots puisse être brevetée.

Par exemple, le fait d’utiliser comme motif une suite de notes donnée pourra être breveté, de même qu’une progression d’accords, ou une trame rythmique, ou l’utilisation de certains instruments, ou un format de répétitions dans un mouvement. N’importe quelle idée musicale qui pourrait être traduite en mots serait brevetable.

Imaginez maintenant que nous sommes en 1800, vous êtes Beethoven, et vous voulez écrire une symphonie. Vous allez vous rendre compte qu’il est beaucoup plus difficile d’écrire une symphonie pour laquelle vous n’aurez pas de procès que d’écrire une symphonie qui soit belle, car il faudra vous tailler un chemin dans la jungle des brevets existants. Et si vous vous plaignez de cet état de fait, les titulaires de brevets vous répondront : « Oh Beethoven, tu es jaloux parce que c’est nous qui avons eu ces idées en premier. Tu n’as qu’a chercher un peu et trouver des idées originales. »

Beethoven avait beaucoup d’idées originales. La raison pour laquelle il est considéré comme un grand compositeur, c’est justement parce qu’il a eu beaucoup d’idées originales, et qu’il a su les mettre en musique de manière efficace, c’est-à-dire en les combinant avec beaucoup d’autres idées très répandues. En introduisant dans une composition quelques idées nouvelles, au milieu de beaucoup d’idées plus anciennes et plus classiques, il obtenait des morceaux novateurs, mais pas au point que les gens ne puissent plus les comprendre.

À nos oreilles, la musique de Beethoven n’a rien de révolutionnaire. Apparemment c’était le cas au XIXe, mais comme il a su mêler ses idées nouvelles à d’autres mieux acceptées, il a pu donner aux gens une chance de s’y adapter. Et c’est ce qu’ils ont fait, c’est pourquoi aujourd’hui cette musique ne nous pose aucun problème. Mais personne, pas même un génie comme Beethoven, n’est capable de réinventer la musique à partir de rien, sans faire appel à aucune des idées de son temps, tout en aboutissant à quelque chose que les gens ont envie d’écouter. Et personne n’est assez génial pour réinventer l’informatique à partir de zéro, sans faire appel à aucune idée de son temps, tout en obtenant quelque chose que les gens ont envie d’utiliser.

Quand le contexte technologique change très rapidement, vous finissez par vous retrouver dans une situation où ce qui a été fait il y a vingt ans ne correspond plus à rien. Il y a vingt ans le World Wide Web n’existait pas. Bien sûr, on pouvait faire plein de choses avec un ordinateur, à l’époque, mais ce que les gens veulent aujourd’hui, ce sont des choses qui fonctionnent avec le World Wide Web. Et il n’est pas possible de faire cela en utilisant seulement des idées qui datent d’il y a vingt ans. Et j’imagine que le contexte technologique va continuer à évoluer, offrant de nouvelles occasions à certains d’obtenir des brevets qui nuisent à l’ensemble de la discipline.

Les grandes entreprises elles-mêmes le font. Par exemple, il y a quelques années, Microsoft a décidé de créer un faux standard ouvert pour les documents, et a obtenu son approbation en corrompant l’ISO (Organisation internationale de normalisation). Le format était conçu à partir d’un brevet que Microsoft avait déposé. Microsoft est suffisamment puissante pour pouvoir partir d’un brevet, et concevoir un format ou un protocole qui utilise ce brevet (que ce soit utile ou non), de telle manière qu’il n’existe aucun moyen d’être compatible, sauf à utiliser la même idée. Ensuite, avec ou sans l’aide d’organismes de normalisation corrompus, Microsoft peut en faire un standard de fait. Par son seul poids, elle peut inciter les utilisateurs à recourir à ce format, ce qui lui donne une mainmise au niveau mondial. Il faut montrer aux hommes politiques ce qui se passe réellement dans ces domaines. Il faut leur expliquer pourquoi cela n’est pas bon.

J’ai entendu dire que la raison pour laquelle la Nouvelle-Zélande veut mettre en place des brevets logiciels est qu’une grande entreprise cherche à obtenir des monopoles. Limiter les libertés de chacun afin qu’une seule entreprise puisse augmenter ses profits, c’est être l’antithèse absolue d’un homme d’Etat.

J’aimerais maintenant passer aux questions-réponses.

Q : Quelle est l’alternative ?

RMS : Pas de brevets logiciels. Je sais que cela fonctionne bien. Je travaillais dans cette discipline avant l’apparition des brevets logiciels. Les gens développaient des logiciels et les distribuaient de différentes manières, sans avoir à craindre un procès de la part d’un titulaire de brevet. Les brevets logiciels sont une réponse à un faux problème, il n’y a donc pas à rechercher d’autres solutions.

Q : Comment les développeurs sont-ils récompensés ?

RMS : Il existe de nombreux moyens. Mais les brevets logiciels n’ont rien à voir avec cela. N’oubliez pas que si vous êtes un développeur de logiciels, les brevets logiciels ne vous aideront pas à obtenir ce que vous cherchez à obtenir.

Il existe différents types de développeurs de logiciels, qui recherchent des choses différentes. Dans les années 80, j’ai développé certains logiciels importants, et la récompense que je recherchais était de voir plus de gens utiliser un ordinateur en toute liberté. J’ai obtenu cette récompense, au moins partiellement – tout le monde ne dispose pas de cette liberté. Mais les brevets logiciels n’auraient fait que m’en empêcher.

D’autres personnes développent des programmes parce qu’ils veulent gagner de l’argent. Pour eux aussi, les brevets logiciels sont une menace, car vous n’allez rien gagner si le titulaire d’un brevet vous oblige à tout lui donner ou vous fait fermer.

Q : Comment faire pour lutter contre le plagiat et…

RMS : Le plagiat n’a rien à voir là-dedans. Absolument rien à voir.

Le plagiat représente le fait de copier le texte d’une œuvre en prétendant l’avoir écrit soi-même. Mais les brevets ne concernent en rien le texte d’une œuvre. Ils n’ont aucun lien avec le plagiat.

Si vous écrivez une œuvre, et que cette œuvre contient certaines idées (ce qui est toujours le cas), il n’y a aucune raison de supposer que les brevets concernant ces idées vous appartiennent. Plus vraisemblablement, ils appartiennent à beaucoup d’autres personnes, la plupart étant des mégacorporations, et elles sont toutes en position de vous poursuivre. Vous n’avez même pas à vous soucier du risque de plagiat. Avant même d’en être arrivé au point où quelqu’un d’autre pourrait vous copier, vous vous serez fait plumer.

Vous confondez brevets et droit d’auteur, j’en ai peur. Les deux n’ont rien à voir. Je vous ai expliqué ce que le système de brevets faisait au logiciel, mais je pense que vous ne me croyez pas parce que vous mélangez droit d’auteur et brevet. Vous supposez que ce que fait l’un, l’autre le fait aussi ; or ce n’est pas le cas. Si vous écrivez du code, le droit d’auteur sur ce code vous appartient, mais si ce code met en œuvre des idées, et que certaines d’entre elles sont brevetées par d’autres, ces derniers peuvent vous poursuivre.

Avec le droit d’auteur, lorsque vous écrivez le code vous-même, vous n’avez pas à craindre que quelqu’un d’autre vienne vous poursuivre, car le droit d’auteur n’interdit que la copie. En fait, même si vous écrivez du code totalement identique au code de quelqu’un d’autre, si vous prouvez que vous ne l’avez pas recopié, ce sera un moyen de défense car le droit d’auteur ne restreint que le fait de recopier. Il ne s’intéresse qu’à la paternité d’une œuvre et non aux idées qui y sont développées, donc son objet est fondamentalement distinct de celui des brevets, et ses conséquences sont radicalement différentes.

Je ne suis pas toujours d’accord avec la manière dont les gens utilisent le droit d’auteur, et je me suis exprimé à ce sujet. Mais c’est une question totalement différente, sans aucun lien avec celle d’aujourd’hui. Si vous pensez que le droit des brevets aide ceux qui développent des logiciels, cela veut dire que vous avez une image complètement fausse de ce que fait le droit des brevets.

Q : Ne vous méprenez pas. Je suis de votre côté.

RMS : OK, mais vous avez quand même une image faussée. Je ne vous le reproche pas, car vous avez été victime de désinformation.

Q : J’écris des logiciels à des fins commerciales ; suis-je protégé si je les considère comme des boites noires et que je les garde secrets ?

RMS : Je ne veux pas discuter de ce problème, car je suis contre ces pratiques, je pense qu’elles sont contraires à l’éthique, mais il s’agit d’un problème distinct.

Q : Je comprends.

RMS : Je ne veux pas changer de sujet, et faire l’éloge de quelque chose que je désapprouve. Mais comme il s’agit d’un sujet différent, je préfère ne pas l’aborder.

Q : Notre Fondation pour la recherche, la science et la technologie, qui doit probablement être l’équivalent de votre Fondation nationale pour la science, offre des bourses de recherche et développement, et l’un des points sur lesquels elle insiste particulièrement est que les idées qu’elle a contribué à financer devraient faire l’objet de brevets.

RMS : Cela ne devrait pas être le cas dans le domaine des logiciels, car les idées informatiques ne devraient pas pouvoir être brevetées par qui que ce soit. Mais ce que vous voyez ici, plus généralement, n’est qu’un exemple de plus de la corruption généralisée de notre société, qui place les fins commerciales au-dessus de toutes les autres. Je ne suis pas communiste, et je ne souhaite pas abolir le commerce, mais lorsqu’on en arrive au commerce par-dessus tout, dans tous les domaines de l’existence, cela me semble dangereux.

Q : Richard, si vous vous adressiez à la Fondation, peut-être pourriez-vous leur proposer d’autres solutions pour qu’un petit pays comme la Nouvelle-Zélande puisse gagner de l’argent au travers des logiciels ?

RMS : Les brevets logiciels n’aident personne à gagner de l’argent avec des logiciels. Ce qu’ils signifient, c’est que vous risquez un procès si vous essayez.

Q : Et cela empêche la Nouvelle-Zélande de construire son économie en s’appuyant sur les logiciels.

RMS : Désolé, mais quand vous dites « cela », je ne comprends pas bien à quoi vous faites référence. Avec les brevets logiciels, ce que vous décrivez devient compliqué pour tout le monde. Si la Nouvelle-Zélande autorise les brevets logiciels, il sera difficile pour qui que ce soit dans le pays de développer des programmes et de les distribuer, à cause du risque de procès. Les brevets logiciels n’ont rien à voir avec le fait de développer un logiciel et de s’en servir.

Q : Donc, en terme de développement économique, la Nouvelle-Zélande serait mieux protégée en n’ayant pas de droit des brevets.

RMS : Oui. Vous voyez, chaque pays a son propre système de brevets, et ils fonctionnent tous de manière indépendante, sauf entre les pays qui ont signé des traités qui disent : « Si vous avez un brevet dans tel pays, vous pouvez venir chez nous avec votre demande de brevet, et nous la prendront en compte à la date à laquelle vous l’avez faite là-bas. » Mais à part ça, chaque pays a ses propres critères concernant ce qui est brevetable, et possède ses propres séries de brevets.

Il en découle que, dans la mesure où les États-Unis autorisent les brevets logiciels et pas la Nouvelle-Zélande, n’importe qui dans le monde, y compris des Néo-Zélandais, peut obtenir des brevets américains et poursuivre de pauvres Américains chez eux. Mais personne ne peut obtenir de brevet permettant de poursuivre un Néo-Zélandais chez lui. Vous pouvez être certain que (si la Nouvelle-Zélande les autorise) presque tous les brevets logiciels appartiendront à des étrangers qui les utiliseront pour matraquer n’importe quel développeur néo-zélandais dès que l’occasion se présentera.

Q : Depuis l’affaire Hughes Aircraft, je crois que c’était dans les années 1990…

RMS : Je ne connais pas cette affaire.

Q : Eh bien en fait la Nouvelle-Zélande autorise les brevets logiciels. Ce n’est pas comme si nous entrions dans un territoire vierge, cela existe déjà.

RMS : Je ne sais pas, mais j’avais cru comprendre qu’il allait y avoir une décision au niveau législatif sur l’opportunité ou non d’autoriser les brevets logiciels. Ceci dit, les offices de brevets se montrent souvent réceptifs au lobbying que les mégacorporations exercent au travers de l’OMPI.

L’OMPI, comme le nom le laisse supposer, œuvre dans le mauvais sens, car l’usage du terme « propriété intellectuelle » ne fait qu’accroître la confusion. L’OMPI tire une grande partie de ses ressources des mégacorporations et utilise ces ressources pour inviter les responsables des offices de brevets à des séminaires dans des destinations paradisiaques. Ce qu’on leur apprend dans ces séminaires, c’est à contourner la loi pour accorder des brevets dans des domaines où ils sont normalement interdits.

Dans de nombreux pays, il existe des lois et une jurisprudence qui posent que les logiciels en tant que tels ne peuvent être brevetés, que les algorithmes ne peuvent être brevetés, ou que les algorithmes « mathématiques » (personne ne sait exactement ce qui rend un algorithme mathématique ou non) ne peuvent être brevetés, et il existe divers autres critères qui, interprétés normalement, devraient exclure les logiciels du champ des brevets. Mais les offices de brevets tordent la loi pour les autoriser malgré tout.

Par exemple, de nombreuses inventions sont en réalité des brevets logiciels, mais sont décrites comme un système incluant un processeur, de la mémoire, des interfaces d’entrée/sortie et d’acquisition des instructions, ainsi que des moyens d’effectuer un calcul particulier. Au final, ce qui est décrit dans le brevet, ce sont les différents éléments d’un ordinateur classique, mais cela leur permet de dire : « C’est un système physique que nous souhaitons breveter. » En réalité, cela revient à breveter un logiciel installé sur un ordinateur. Les subterfuges utilisés sont légion.

Les offices de brevets cherchent généralement à détourner la loi pour accorder plus de brevets. Aux États-Unis, les brevets logiciels ont été créés en 1982 par une décision de la Cour d’appel compétente pour les affaires de brevets, qui a mal interprété une décision de la Cour suprême rendue l’année précédente et l’a appliquée à mauvais escient. Dans une décision récente, il semble que la Cour d’appel ait enfin admis qu’elle s’est trompée depuis le début, et il est possible que cette décision nous débarrasse de tous les brevets logiciels, à moins qu’elle ne soit renversée par la Cour suprême. La Cour suprême est en train de l’examiner, et nous devrions savoir dans moins d’un an si nous avons gagné ou perdu.

Q : Dans l’hypothèse où cette affaire se terminerait en faveur des brevets, existe-t-il aux États-Unis un mouvement pour promouvoir une solution législative ?

RMS : Oui, et cela fait à peu près 19 ans que je milite en faveur de cette solution. C’est un combat que nous menons dans de nombreux pays.

Q : Où placeriez-vous dans votre univers le cas de I4i ?

RMS : Je n’ai aucune idée de ce dont il s’agit.

Q : Il s’agit de l’affaire dans laquelle Microsoft a presque dû cesser de commercialiser Word, parce que le logiciel enfreignait un brevet canadien.

RMS : Ah oui, ça. C’est juste un exemple qui illustre le danger que représentent les brevets logiciels pour tous les développeurs. Je n’aime pas ce que fait Microsoft, mais c’est un autre problème. Il n’est pas bon que quelqu’un puisse poursuivre un développeur de logiciels et dire : « Vous ne pouvez pas distribuer tel logiciel. »

Q : Le monde dans lequel nous vivons n’est évidemment pas parfait, et nous nous heurtons quelquefois aux brevets logiciels. Pensez-vous qu’il faudrait accorder un privilège aux chercheurs, leur permettant d’ignorer les brevets logiciels de la même manière que la législation sur le droit d’auteur leur permet d’effectuer des recherches sur des œuvres protégées par ce dernier ?

RMS : Non, chercher une solution partielle est une erreur, car nos chances de mettre en place une solution complète sont bien plus élevées. Toutes les personnes impliquées dans le développement et la distribution de logiciels, à l’exception de celles qui travaillent dans les mégacorporations, vont se rallier au rejet total des brevets logiciels lorsqu’elles verront à quel point ils sont dangereux. En revanche, proposer une exception pour certaines catégories particulières ne ralliera que les membres de cette catégorie. Ces solutions partielles sont des leurres. Les gens disent : « Bon, on ne peut pas résoudre le problème une bonne fois pour toutes, j’abandonne. Je propose une solution partielle. » Mais ces solutions partielles ne mettront pas les développeurs de logiciels à l’abri.

Q : Cependant vous ne vous opposeriez pas à une solution partielle, pas nécessairement limitée aux brevets logiciels, comme par exemple l’utilisation à des fins d’expérimentation qui pourrait être une bonne solution pour les brevets pharmaceutiques ?

RMS : Je ne m’y opposerais pas.

Q : Mais ce que vous dites, juste pour être bien clair, c’est que vous ne pensez pas que ce soit applicable au logiciel.

RMS : Une solution qui ne sauve que certains d’entre nous, ou seulement certaines activités, ou élimine seulement la moitié des brevets logiciels, cela revient à dire : « On pourrait peut-être enlever la moitié des mines du champs de mines. » C’est un progrès, mais ça n’élimine pas le danger pour autant.

Q : Vous avez parlé de ce sujet aux quatre coins de la planète. Quel a été l’impact ? Certains gouvernements ont-ils apporté des changements, ou renoncé aux brevets logiciels ?

RMS : Certains. En Inde, il y a quelques années, il y a eu une tentative pour autoriser explicitement les brevets logiciels dans la loi. Le projet a été abandonné. Il y a quelques années, les États-Unis ont proposé un traité commercial, un traité de « libre-exploitation » à l’Amérique Latine. Ce traité a été bloqué par le président du Brésil, qui s’est opposé aux brevets logiciels et à d’autres dispositions insidieuses concernant l’informatique, et cela a fait capoter l’ensemble du traité. Il semble que c’était le seul point que les États-Unis tenaient à imposer au reste du continent. Mais on ne peut tuer ces projets pour de bon. Certaines entreprises ont des équipes à plein temps qui recherchent des moyens de subvertir tel ou tel pays.

Q : Dispose-t-on de données chiffrées sur ce qui se passe au plan économique dans les communautés innovantes des pays dénués de droit des brevets ?

RMS : Il n’y en a pas. Il est presque impossible de mesurer ce genre de choses. En réalité, je ne devrais pas dire qu’il n’y en a pas. Il y en a un peu. Il est très difficile de mesurer l’effet du système de brevets, car vous allez comparer la réalité avec un monde fictif, et il n’y a aucun moyen de savoir ce qui se passerait vraiment.

Ce que je peux dire, c’est qu’avant l’apparition des brevets logiciels, il y avait beaucoup de développement logiciel. Pas autant qu’aujourd’hui, bien sûr, car il n’y avait pas autant d’utilisateurs d’ordinateurs.

Combien d’utilisateurs d’ordinateurs y avait-il en 1982, même aux États-Unis ? C’était une toute petite partie de la population. Mais il y avait des développeurs de logiciels. Ils ne disaient pas : « Nous avons absolument besoin de brevets. » Ils ne se retrouvaient pas poursuivis pour infraction à un brevet après avoir développé un programme. Mais le peu de recherche économique que j’aie pu voir montre qu’apparemment les brevets logiciels ont entraîné non pas un accroissement de la recherche, mais un transfert de ressources de la recherche vers les brevets.

Q : Pensez-vous qu’il puisse y avoir un regain d’intérêt pour les secrets de fabrication ?

RMS : Non. Avant l’apparition des brevets logiciels, de nombreux développeurs gardaient les détails de leurs programmes secrets. Mais habituellement, ils ne gardaient pas secrètes les idées générales, parce qu’ils se rendaient compte que la majeure partie du travail de développement d’un bon logiciel résidait, non pas dans l’élaboration d’idées générales, mais dans la mise en œuvre conjointe de nombreuses idées. Ils publiaient donc – ou laissaient leurs salariés publier – les nouvelles idées intéressantes qu’ils avaient eues dans des revues universitaires. Maintenant, ils brevètent ces idées nouvelles. Cela n’a rien à voir avec le fait de développer des programmes utiles, et partager certaines idées avec d’autres ne leur donne pas un programme. Par ailleurs, les milliers d’idées que vous avez combinées dans votre programme sont de toute façon bien connues, pour la plupart.

Q : Pour renforcer ce que vous venez de dire, j’ai entendu récemment une interview de l’un des fondateurs de PayPal, qui disait que son succès reposait à 5% sur des idées et à 95% sur leur mise en œuvre, ce qui confirme votre point.

RMS : Je suis d’accord.

SF : Très bien. Richard a ici des autocollants qui sont gratuits (free), je crois.

RMS : Gratis^[2]. Et ceux-là sont à vendre.

SF : Vous êtes les bienvenus si vous souhaitez nous rejoindre. Ce fut un débat très constructif, merci Richard.