Politique Debian pour les firmwares propriétaires ?

Salut,

Je viens de fourrer mon nez dans le dépôt git des firmwares du kernel et je suis effaré du nombre de firmwares qui ne sont pas packagés dans Debian malgré leur présence dans le kernel.

Je comprends bien (et j’approuve totalement) la politique globale de Debian consistant à séparer clairement les firmwares (ou même tous les logiciels) libres et ceux propriétaires, mais ce que je ne comprends pas c’est pourquoi autant de firmwares propriétaires (sans sources mais librement distribuables, donc éligibles pour non-free) sont absents des dépôts Debian. Je trouve ça dommage d’avoir à télécharger/installer des firmwares manuellement depuis un paquet Ubuntu (ou depuis kernel.org, mais c’est moins facile à trouver) alors qu’il serait si simple de les packager. :confused:

J’ai cherché la réponse sur internet mais je ne trouve rien de pertinent concernant la raison de cet état de faits.
Quelqu’un sait où trouver cette info (si elle existe) ?

Du coté de Debian et la possible reconnaissance par la FSF en tant que système libre ??? (chaipa mais ça date un peu :mrgreen: )

/usr/src/linux-3.5/firmware/README.AddingFirmware

[code]
DO NOT ADD FIRMWARE TO THIS DIRECTORY.
======================================

This directory is only here to contain firmware images extracted from old
device drivers which predate the common use of request_firmware().

As we update those drivers to use request_firmware() and keep a clean
separation between code and firmware, we put the extracted firmware
here.

This directory is NOT for adding arbitrary new firmware images. The
place to add those is the separate linux-firmware repository:

git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

That repository contains all these firmware images which have been
extracted from older drivers, as well various new firmware images which
we were never permitted to include in a GPL’d work, but which we have
been permitted to redistribute under separate cover.

To submit firmware to that repository, please send either a git binary
diff or preferably a git pull request to:
David Woodhouse dwmw2@infradead.org
Ben Hutchings ben@decadent.org.uk

Your commit should include an update to the WHENCE file clearly
identifying the licence under which the firmware is available, and
that it is redistributable. If the licence is long and involved, it’s
permitted to include it in a separate file and refer to it from the
WHENCE file.

Ideally, your commit should contain a Signed-Off-By: from someone
authoritative on the licensing of the firmware in question (i.e. from
within the company that owns the code).[/code]

Pour ce que j’en interprète,les mainteneurs de linux renvoient les firmwares en quarantaine,en git, pour ne pas condammner tout le reste.

Une question de licences de ces firmwares empêcherait la distribution des binaires prêts à l’emploi.
On ne t’interdit pas de compiler un noyau avec firmware, on t’interdit de distribuer le fruit de ces compilations sans le consentement des propriétaires du code, l’autorité qui demande que le firmware soit distribué sous ses conditions.

Le linux de debian n’est pas délesté à 100 % des blobs propriétaires.
Celui qui tend vers cet objectif est linux libre.
fsfla.org/svnwiki/selibre/linux-libre/

Firmwares en debian
packages.debian.org/squeeze/firmware-linux-free

Voir du côté de non-free
packages.debian.org/squeeze/firm … ux-nonfree

Je n’ai pas comparé la liste du git et celle de ce paquet car il ne regroupe pas tous les firmwares.
Témoignant d’une confiance aveugle envers debian, je pense que ceux qui ne sont pas compris dans ce paquet sont censés se trouver dans des paquets indépendants … ou sont tellement cadenassés qu’on ne les trouve qu’en blobs chez les constructeurs.

Toujours aussi Pro! Pour toi :wink:

Allez, [size=85]j’retourne [/size] [size=65] dans [/size] [size=55]ma [/size] [size=45]grotte[/size]

Bon de toute évidence mon explication n’était pas aussi claire que je le pensais… :blush:

[quote=“etxeberrizahar”]/usr/src/linux-3.5/firmware/README.AddingFirmware
[…]
Pour ce que j’en interprète,les mainteneurs de linux renvoient les firmwares en quarantaine,en git, pour ne pas condammner tout le reste.
Une question de licences de ces firmwares empêcherait la distribution des binaires prêts à l’emploi.[/quote]
Ce que dit ce document c’est justement que tous les firmwares disponibles sur le git linux-firmware de kernel.org (git.kernel.org/?p=linux/kernel/ … git;a=tree) sont librement distribuables ; même si pour la plupart on ne dispose pas des sources, le constructeur autorise tout de même la distribution des binaires (d’ailleurs dans le cas contraire les binaires ne seraient pas sur kernel.org).

[quote=“etxeberrizahar”]Je n’ai pas comparé la liste du git et celle de ce paquet car il ne regroupe pas tous les firmwares.
Témoignant d’une confiance aveugle envers debian, je pense que ceux qui ne sont pas compris dans ce paquet sont censés se trouver dans des paquets indépendants … ou sont tellement cadenassés qu’on ne les trouve qu’en blobs chez les constructeurs.[/quote]
C’est précisément le point sur lequel je formule ma critique : parmi les firmwares librement distribuables disponibles sur kernel.org, tous ne sont pas présents dans Debian.

Prenons l’exemple du firmware pour le lecteur de carte SD des Acer Aspire One (ENE UB6250). Ce firmware est clairement considéré “propriétaire” car on ne dispose pas des sources, mais il est librement distribuable (licence de type BSD : git.kernel.org/?p=linux/kernel/ … f8;hb=HEAD). Étant donné qu’il est librement distribuable, ce firmware est éligible pour la section non-free des dépôts Debian. Or il n’est trouvable dans aucun paquet Debian (vérifié avec apt-file dans stable/testing/unstable/experimental, sections main/contrib/non-free) bien qu’il soit disponible depuis fin juillet 2011 !

À côté de ça, un firmware tel que iwlwifi ne fournit pas non plus de sources et a une licence identique (git.kernel.org/?p=linux/kernel/ … ee;hb=HEAD), mais il est inclus dans non-free, lui. :confusion-questionmarks:

Et malheureusement ene-ub6250 est loin d’être un cas isolé. :frowning:

D’où ma question : pourquoi cette différence de traitement qui ne me paraît pas justifiée à première vue ?

C’est ce que je croyais aussi, jusqu’à ce que je soulève le lièvre. :wink:

La légendaire avance sur son temps de debian …

Git = ba$tard

Ce qui se trouve en git du noyau est destiné à intégrer le noyau régulier ou à disparaître. ENE_UB6250 semble avoir réussi l’examen.

linux-3.5 dans device drivers -> usb support ->usb ene card reader support

config USB_STORAGE_ENE_UB6250
tristate "USB ENE card reader support"
depends on USB && SCSI
depends on USB_STORAGE
—help—
Say Y here if you wish to control a ENE SD/MS Card reader.
To use SM card, please build driver/staging/keucr/keucr.ko

  This option depends on 'SCSI' support being enabled, but you
  probably also need 'SCSI device support: SCSI disk support'
  (BLK_DEV_SD) for most USB storage devices.

  To compile this driver as a module, choose M here: the
  module will be called ums-eneub6250.

Log du ba$tard

13 months agoAdd ene-ub6250 SD card reader firmware
commit | commitdiff | tree
Cho, Yu-Chen [Mon, 4 Jul 2011 09:16:10 +0000]
Add ene-ub6250 SD card reader firmware

Move ENE UB6250 SD/MS card firmware from driver/staging/keucr, and
convert it from HEX to using request_firmware()
Most for this patch is from huajun.li.lee@gmail.com sent at
2011-03-02,only added the ms card reader firmware and LICENCE of
firmware from ENE.

Deux choses à bien distinguer : le pilote et le firmware.
Aujourd’hui, à de rares exceptions près, la plupart des pilotes sont libres (toujours en prenant l’exemple ENE UB6250, le pilote était keucr tant qu’il était encore dans staging, puis est devenu ums-eneub6250 une fois intégré dans le tronc, mais les deux utilisent le même firmware). Malheureusement beaucoup de pilotes libres ont encore besoin d’un firmware non-libre.

Je ne voudrais pas dire de bêtises, mais je crois que la principale distinction entre les deux c’est l’endroit où le code s’exécute : le pilote fait directement partie du kernel et s’exécute sur le CPU, tandis que le firmware est envoyé au matériel pour que le “coprocesseur” (au sens large) présent sur ledit matériel puisse savoir comment se comporter.

Bref, ça nous avance toujours pas.

Ça pourrait expliquer la chose, mais j’ai toujours du mal à saisir pourquoi il manque des firmwares vieux de plus d’un an alors qu’à côté on a le kernel 3.5 dans experimental. Les deux devraient logiquement être distribués ensemble non, même si c’est dans des paquets différents ? Mon impression, qui m’a conduit à ouvrir ce fil, c’est que dès qu’il s’agit de firmwares l’équipe Debian fait du “cherry-picking” sans réelle logique derrière. :confused:
Un processus de build logique serait de simplement construire un paquet pour chaque firmware librement distribuable. Debian se vante d’être le “système d’exploitation universel” et pourtant ils font l’impasse sur de nombreux firmwares ce qui réduit d’autant le support matériel. :confused: