Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information

Vous avez demandé le commentaire #781333.

Retourner sur le contenu associé.

concernant les blobs

Posté par baud123 (Jabber id, page perso, ) le 05/12/2006 à 16:17. (lien). Évalué à 2.

Pour préciser un peu ce que tu dis : oui Mandriva a intégré eagle-usb avec le firmware/DSPcode depuis au moins Mandriva 9.2.
C'est depuis ueagle-atm que nous avons commencé à pointer du doigt clairement que le firmware/DSPcode ne faisaient pas un tout avec le pilote et qu'à ce titre ne pouvaient pas bénéficier de la licence libre du pilote, cela reste une interprétation corroborée par le manque de source tout de même (ceci étant facilité par la non inclusion du firmware dans un .h ... chargement par firmware_class... depuis ueagle-atm).

Mandriva avec sa version 2007 a choisi de sortir une version free et une non-free respectant ce principe, le firmware se retrouve donc non distribué sur le CD free (qui signifie libre comme tout le monde a compris).

Concernant Ubuntu, le travail d'intégration n'a pas eu lieu à ma connaissance.
Il n'y a pas de souci pour rajouter un packageur sur notre SVN (s'il peut respecter les DFSG ce serait pas mal aussi pour éviter d'avoir 2 types de paquets .deb).

Pour rappel sur les blobs, ce qui était reproché à raison à Ubuntu c'est de _travailler à rajouter_ des blobs au kernel ET en même temps annoncer "100% free" pour leur CD : c'est induire l'utilisateur en erreur, autant mettre "100% gratis" pour être honnête : en gros respecter la répartition de ce qui est indiqué sur http://www.ubuntu.com/ubuntu/components . Je ne doute pas que cette approche trompeuse soit rectifiée rapidement, tout comme Mandriva a travaillé à clarifier le libre du non libre (ou Debian ou Fedora...). D'autre part, l'aide des distributions pour appuyer les demandes des développeurs libres auprès des constructeurs serait un plus... (les distributions signent bien des contrats de certification de temps en temps).

L'utilisation de dépôts estampillés restricted ou non-free contribue à clarifier et permet d'identifier ce qui est explicitement non libre (après cela signifie regarder la licence au cas par cas pour vérifier que c'est distribuable sans trop de risque pour la distrib'), le jour où cela devient libre (par fourniture du code ou réécriture du code), cela peut sortir de non-free (ou alors, si cela devient interdit au détriment des utilisateurs... au constructeur de faire le choix de ses clients).

[ Répondre ]