Et si l’on ouvrait de force le code source des logiciels qui ne sont plus mis à jour ?

Lorsqu’un logiciel ne reçoit plus de mise à jour, son éditeur devrait-il avoir l’obligation d’en ouvrir le code source pour permettre à des tiers de continuer à le développer et, le cas échéant, corriger des failles de sécurité qui seraient découvertes au fil de l’eau ? C’est ce que propose un amendement qui a été déposé le 18 novembre à l’Assemblée nationale par un groupe de quatre députés.

Cette suggestion, soutenue notamment par Paula Forteza et Matthieu Orphelin, entend modifier le Code de la consommation et, plus précisément, son article L217‑19 qui traite des mises à jour. La mesure, relayée sur Twitter par le journaliste Émile Marzolf, viendrait ainsi compléter plusieurs dispositions que le vendeur doit suivre, dans le cadre de la garantie légale de conformité pour les biens.

Un système d’exploitation comme Windows est concerné par ce type d’amendement. Il s’agit d’un logiciel propriétaire, dont le support est limité dans le temps. // Source : Melvyn Dadure pour Numerama

Adossé à la proposition de loi visant à renforcer les pouvoirs du régulateur des télécoms en matière d’environnement, qui est en cours d’examen au Parlement, l’amendement propose que « dès lors que le vendeur ne fournit plus de mises à jour, il diffuse gratuitement, sous format électronique et dans un standard ouvert librement réutilisable, les codes sources afférents au produit concerné ».

Dans l’exposé des motifs, les quatre élus considèrent que cette ouverture forcée serait bénéfique à la fois en termes de sécurité informatique (l’ouverture « permettrait aux informaticiens de colmater d’éventuelles failles de sécurité ») et de longévité des produits, car les particuliers seraient moins enclins à les remplacer si des évolutions logicielles sont toujours proposées.

Pour enfoncer le clou, les parlementaires estiment que « le passage en open source n’aurait aucun impact économique pour les constructeurs », parce que la bascule ne toucherait que des terminaux dont la commercialisation a pris fin. En somme, cette piste serait un bon moyen de lutter contre « l’obsolescence logicielle » sur des appareils qui sont encore fonctionnels.

Ouvrir de force le code source des logiciels qui ne sont plus mis à jour ? Pas si simple

Mais en l’état, cette initiative entraîne un certain nombre de questions que l’amendement n’aborde pas. Comment savoir, par exemple, que le vendeur d’un logiciel ne fournit plus de mise à jour, s’il ne communique pas particulièrement dessus ? Le cas échéant, au bout de combien de temps après la dernière mise à jour ce passage en open source doit-il se faire ? Faut-il attendre une période minimale ? Et si oui, de quelle durée ?

Au-delà du tempo à donner à l’ouverture, d’autres problématiques se posent : en premier lieu, l’applicabilité de la mesure. Quelle contrainte en cas de refus de l’éditeur ? Il n’est pas fait mention de sanctions éventuelles si le code source n’est pas ouvert et pour des raisons de protection de la propriété intellectuelle, les éditeurs, notamment étrangers, pourraient se montrer très récalcitrants à ouvrir quoi que ce soit.

Une deuxième question, plus pratique, se pose : à supposer que les éditeurs jouent le jeu, comment s’assurer de la qualité des mises à jour que d’autres produisent, que ce soit pour colmater des brèches ou pour ajouter des fonctionnalités ? Comment, de plus, pousser ces correctifs tiers vers le public, pour qu’il s’en empare, si ceux qui les conçoivent n’ont pas accès aux canaux de distribution des éditeurs ?

Windows Update mai 2020

En grossissant le trait, l’amendement pourrait possiblement engendrer un comportement indésirable chez les vendeurs ne voulant pas libérer le code source : l’invention de fausses mises à jour, ou anecdotiques, pour retarder aussi longtemps que possible l’échéance de l’open source. C’est un scénario certes particulier, mais qui n’est pas impossible, surtout si le vendeur estime avoir de gros enjeux de propriété intellectuelle.

Enfin, il se pose aussi la question du risque informatique — qui existe déjà pour n’importe quel OS ou logiciel, que le code source soit fermé ou non.

D’aucuns pourraient arguer qu’en ouvrant le code source, les pirates auraient plus de facilité à attaquer un système. Il faudrait alors compter sur l’open source pour faire barrage avec des patchs, mais, à supposer que ce milieu ait la disponibilité et les ressources adéquates pour gérer tous les logiciels propriétaires entrant dans l’open source, la question de la diffusion des patchs vers le public se repose de nouveau.

Le sujet soulevé dans l’amendement existe depuis des années dans le milieu des logiciels. Elle se posait par exemple en 2014, lorsque Windows XP a vu expirer son support étendu le 8 avril 2014, plus de treize ans après sa commercialisation. Microsoft n’a toutefois jamais ouvert ce code source — du moins pas encore. Peut-être le fera-t-il des années plus tard, à l’image de ce qu’il a fait avec MS-DOS.

L’ouverture, des années plus tard, d’un code comme MS-DOS apparait toutefois assez peu pertinente au regard des buts poursuivis par l’amendement ; rendre le code source vite disponible pour le maintenir à jour, afin que cela profite à assez de personnes. Dans le cas de MS-DOS, ce sont les versions 1.0 et 2.0 qui ont été libérées et elles datent d’avant 1985. Or ici, il a fallu attendre 30 ans.

Quelles pourraient être les alternatives à l’ouverture forcée du code source, si cette piste ne mène à rien ? Pour reprendre le cas de Microsoft, l’éditeur américain a parfois procédé à une mise à jour d’un logiciel même si le support de l’OS a expiré. Il a aussi lancé un service payant pour une maintenance personnalisée. Mais cela s’adresse avant tout à un secteur très professionnel. Le public suivrait-il ?