Nous sommes extrêmement chanceux de vivre à une époque où du matériel doté de capacités étonnantes peut être obtenu pour seulement quelques dollars. Les systèmes qui nécessitaient autrefois une pile coûteuse de puces et de composants discrets avec des mois de développement à assembler sont maintenant intégrés sur du silicium de base. Qu’il s’agisse d’un système sur puce compatible Linux ou d’un microcontrôleur, des périphériques tels que le WiFi, les GPU, le Bluetooth ou les piles USB font désormais partie de la puce, juste une autre bibliothèque de logiciels plutôt qu’une tonne de matériel supplémentaire.
Méfiez-vous du Blob!
S’il y a un prix à payer pour cette commodité, cela se présente sous la forme du blob. Un logiciel binaire pré-compilé qui fait le travail acharné de parler au matériel et qui présente une API unifiée au logiciel. Que vous parliez au WiFi ESP32 via une bibliothèque Arduino ou que vous démarriez un Raspberry Pi avec une distribution Linux, alors que votre code peut être disponible ou même peut-être open source, le blob sur lequel il repose pour fonctionner est une source fermée et propriétaire. Cela représente un défi non seulement pour les passionnés de Software Libre à la recherche d’un ordinateur véritablement open source, mais aussi pour le reste d’entre nous, car nous sommes dépendants de la volonté du fabricant de matériel de mettre à jour et de corriger leurs blobs.
Un défenseur de l’open-source dirait que la solution est simple, les fabricants devraient simplement rendre leurs blobs open-source. Et c’est vrai, si tous les blobs étaient open-source, la foule des logiciels libres serait heureuse et leur nature open-source faciliterait la génération de ces mises à jour et correctifs. Alors pourquoi les fabricants ne publient-ils pas leurs blobs en open source? Dans certains cas, cela peut bien être dû à un état d’esprit de source fermée de ne jamais rien divulguer au monde pour protéger la propriété intellectuelle de l’entreprise, mais en rester là n’est pas une réponse complète. Pour bien comprendre pourquoi c’est le cas, il vaut la peine d’examiner comment nos puces multifonctionnelles sont fabriquées.
Les puces ne sont plus fabriquées comme avant
Il y a des décennies, un nouveau micro-ordinateur et sa gamme de puces périphériques auraient été entièrement conçus en interne par une équipe d’ingénieurs employés par l’entreprise. Des puces telles que Intel 8086 ou Motorola 68000 ont été produites de cette manière et auraient même dans de nombreux cas été placées sur du silicium par des fabricants de puces internes. L’industrie actuelle des semi-conducteurs est beaucoup plus fragmentée et fonctionne d’une manière totalement différente. Bien que certaines grandes entreprises puissent encore faire tout le travail en interne, il est beaucoup plus probable qu’elles achèteront plutôt les composants de leurs nouveaux produits sous forme d’IP, sous forme de logiciel sous la forme de VHDL ou de langages de description de matériel similaires. Il est tout à fait possible de concevoir un SoC complet de cette manière sans posséder vous-même la propriété intellectuelle, et des sociétés telles que ARM sont devenues des acteurs dominants de l’industrie en vendant leurs cœurs aux développeurs de puces. Une telle puce assemblée à partir d’IP standard peut ensuite être envoyée à une fabrique de puces tierce pour la production, ce qui signifie qu’une gamme complète de puces peut être commercialisée sans la propriété directe de l’IP ou de l’usine.
Une puce assemblée à partir de plusieurs éléments de propriété intellectuelle commerciale sera bien entendu soumise à tous les accords de licence individuels pour ses composants. Les propriétaires individuels de propriété intellectuelle auront une multitude de raisons pour insérer des clauses restrictives dans leurs accords, mais au niveau le plus élémentaire, ils sont soucieux de ne pas révéler de secrets commerciaux à leurs concurrents dans une industrie acharnée. Il est donc acquis que le blob contrôlant un périphérique sur cette puce sera lié par une clause de l’accord de licence limitant la diffusion des informations relatives à son matériel. Le blob reste un binaire précompilé à source fermée, et aucune ruse du fabricant de puces à propos de l’open source ne changera cela. Même les puces qui contiennent des composants open-source tels qu’un cœur RISC-V ne sont pas à l’abri de contenir également des IP périphériques fermés, comme c’est le cas par exemple avec le Bouffalo Labs BL602 WiFi SOC.
Tout est dans les mises à jour
Les partisans de l’open source ont donc une réponse à la question de savoir pourquoi les blobs existent et pourquoi ils ne disparaîtront pas de si tôt, alors que ce n’est peut-être pas du goût de tout le monde, c’est au moins valide. Mais le problème des blobs ne s’arrête pas là, et peut-être que notre communauté doit aussi y réfléchir un peu. Parce que même si vous n’avez aucun problème avec votre matériel nécessitant un blob, sa présence peut toujours revenir vous mordre. La raison peut avoir autant à voir avec le monde open source qu’avec le détenteur de la propriété intellectuelle ou le fabricant.
Si vous possédez un Raspberry Pi, vous avez peut-être mis à jour plusieurs fois votre copie du système d’exploitation Raspbian ou Raspberry Pi avec de nouvelles versions incluant des mises à jour majeures de leur noyau Linux. Le Broadcom SoC du Raspberry Pi est comme toutes les autres puces en ce sens qu’il est livré avec un blob, et quand ils publieront un nouveau noyau, il sera dans un package de micrologiciel personnalisé pour une utilisation avec ce blob et sera également livré avec toutes les mises à jour de blob appropriées. Les gens de Raspberry Pi auront les sources des bits de source fermée, mais ils sont empêchés de les libérer par leur accord avec Broadcom qui leur a accordé un accès à la source blob. Ainsi, le Raspberry Pi dispose d’un logiciel à jour, mais il s’agit d’un mélange difficile d’un système d’exploitation open source qui repose sur un composant à source fermée pour fonctionner.
Maintenant, comparez le Raspberry Pi à un ordinateur monocarte moins connu, disons une carte à dix dollars avec un nom qui suit le schéma de dénomination {SomeFruit} Pi. Le Raspberry Pi a peut-être une spécification moins excitante, mais si vous examinez le système d’exploitation fourni avec la carte hors marque, vous constaterez qu’il a un noyau personnalisé très similaire qui repose sur un blob. La différence viendra au fur et à mesure que vous continuez à l’utiliser, avec le temps, il se peut qu’aucun nouveau noyau ne soit publié et après un certain temps, vous utiliserez une ancienne version du noyau sans aucune perspective de mise à niveau.
Même si vous n’avez pas de tableau sans nom, vous reconnaîtrez le même problème si vous avez un téléphone Android. C’est un ordinateur puissant compatible Linux exécutant une distribution Linux personnalisée, mais après quelques années, vos chances d’obtenir une nouvelle version d’Android sont très minces et vous aurez pratiquement aucune chance d’installer une autre distribution Linux dessus sans astuces impliquant l’utilisateur. chroot et quel que soit l’ancien noyau Android qu’il a installé.
Ces deux exemples ont le blob à la racine de leurs problèmes, en ce que les deux proviennent de fabricants qui n’ont aucun intérêt à publier de nouveaux noyaux personnalisés pour leurs blobs, de sorte que les deux sombrent lentement dans l’obsolescence.
À votre avis, à quoi sert l’Open Source?
En demandant ce qui peut être fait pour remédier à cette situation, il vaut la peine d’examiner le rôle que les logiciels open source peuvent jouer. Nous avons établi la propriété intellectuelle de l’industrie des semi-conducteurs comme la raison pour laquelle il n’y a aucune chance pour les fabricants de rendre leur code blob open-source, mais comment le monde de l’open source peut-il réagir à cela? Cela revient à une question de philosophie open source qui se reflète probablement dans le choix de la licence; L’open-source existe-t-il pour créer des logiciels qui fonctionnent avec des composants à code source fermé, ou existe-t-il pour étendre l’open-source à tous les coins de l’informatique et exclure la source fermée? Dans le cas de Linux, il s’oriente vers ce dernier car l’interface à laquelle le blob doit parler change avec chaque version du noyau, forçant un développeur de blob à mettre à jour ou à laisser sa distribution vieillir sans pertinence. Les développeurs de Raspberry Pi font de leurs efforts une caractéristique clé de leurs produits, mais ce n’est pas une priorité pour de nombreux fournisseurs de matériel. Si d’autres systèmes d’exploitation tels que Microsoft Windows peuvent conserver une certaine compatibilité de pilote de bas niveau dans leurs versions, pourquoi leurs alternatives open source ne le peuvent-elles pas?
Il y a bien sûr un autre résultat potentiel. Les fabricants de semi-conducteurs préfèrent les choses qui leur coûtent moins cher, et comme on peut le voir avec la lente apparition actuelle des cœurs RISC-V, ils montrent des signes de volonté de plonger leurs orteils dans l’eau en ce qui concerne les composants de puces matérielles open-source . Un rapide coup d’œil à OpenCores ou LibreCores révélera une multitude de pièces qui peuvent être librement ajoutées aux conceptions, il y a donc au moins une possibilité d’un SoC sans IP propriétaire qui aurait besoin d’un blob. Il faudra plus que la simple existence de telles ressources pour persuader un fabricant de franchir le pas, cependant, pour qu’une puce entièrement open-source soit une proposition pratique, il ne doit pas seulement y avoir des composants pour toutes les fonctions sur puce, mais ils doivent également être assez fiable pour la production. Même avec les meilleures intentions du monde, ces deux choses peuvent prendre un peu de temps.
J’espère que cet article donne matière à réflexion sur le rôle du blob sur les puces modernes et sur sa relation avec les logiciels open source. Cela va au-delà d’un simple argument selon lequel les fabricants devraient simplement publier leurs sources d’objets blob, mais si la situation blob ne peut pas être modifiée, le monde open source devrait-il s’adapter pour faire face à cela? Comme toujours, nous aimerions connaître votre point de vue dans les commentaires.
