Retrouvez cet article dans : Linux Magazine 89
Les blobs ne sont pas des monstres mutants dévoreurs de chair, mais la réalité n’est pas loin. Un blob est un objet binaire, et donc obscur, permettant d’utiliser un périphérique (souvent Wifi). Vous aurez compris le problème, un blob est un code binaire propriétaire utilisé via un wrapper GPL dans un noyau en GPL.
Les blobs, ou microcodes, représentent un point sensible pour toutes les distributions, car ils sont nécessaires pour la mise en œuvre de certains périphériques, mais entrent en contradiction avec les termes de la GPL et souvent les guidelines des distributions. Il en va de même pour les firmwares livrés avec certains pilotes. A l’instar des blobs, les firmwares sont des données binaires, mais celles-ci sont chargées dans le périphérique pour en permettre le fonctionnement, un peu à la manière des codes chargés dans la mémoire flash des microcontrôleurs.
Ces problématiques sont de plus en plus présentes dans les distributions GNU/Linux et le projet Debian est directement concerné. Le « contrat social » Debian impose un certain nombre de règles concernant l’intégration de logiciels dans une distribution. Il est dit clairement : « Nous reconnaissons que certains de nos utilisateurs demandent à pouvoir utiliser des travaux qui ne sont pas conformes aux principes du Logiciel libre selon Debian. Les paquets correspondants prennent place dans des sections nommées ‘contrib’ (contributions) et ‘non free’ (non libre). Les paquets de ces sections ne font pas partie du système Debian, bien qu’ils aient été configurés afin d’être utilisés avec lui. »
Si le noyau distribué par Debian inclut des blobs, microcodes ou firmwares, il devrait donc naturellement être déplacé dans non free. Mais, dans ce cas, comment supporter certains périphériques via l’installeur CD (comme les interfaces Ethernet tg3) ? La question se pose également s’il faut considérer l’intégration de versions « nettoyées » dans la distribution.
La résolution générale (GR) sur la question, la position officielle du projet, se fait attendre et la prise de décision est sans cesse reportée. Pour l’heure, l’équipe du noyau considère la solution suivante comme la plus viable. Elle distingue trois types de cas :
1. Les blobs binaires sans source, sans licence et sans autorisation de diffusion explicite : non redistribution et retrait (prune) des blobs en question du paquet linux-*.
2. Les blobs binaires sans source rediffusés sous GPL (blob + wrapper GPL) : c’est une violation évidente des termes de la licence GPL, mais leur suppression poserait un problème technique majeur, aurait un impact très négatif et contredirait l’un des objectif du projet consistant à propager le concept de Logiciel libre. La solution proposée est de tolérer ces pilotes pour Etch en espérant trouver une solution par la suite ; peut-être en amont, puisque les blobs sont clairement un problème pour les développeurs du noyau et Linus s’est clairement exprimé sur le sujet.
3. Les blobs binaires qui violent le contrat social pour d’autres raisons comme du code obfusqué ou avec des limitations concernant sa modification : les pilotes entrant dans cette catégorie sont moins nombreux mais, là encore, tolérer temporairement leur présence est un moindre mal.
Ce n’est toutefois pas la position officielle du projet, puisque aucune résolution générale (découlant d’un vote) n’a été annoncée.
Retrouvez cet article dans : Linux Magazine 89
