avant cette annonce j'en étais plutôt resté à
- l'installateur ne gère pas l'appel à un firmware externe non inclus dans le kernel (sur disquette, CD, clé usb, réseau, dépôt non-free), si c'est dans main l'installateur réussit à se débrouiller (mais main ne devrait pas avoir de non libre...)
- pour les firmwares encore en dur dans les pilotes (tableaux), libre ou non libre cela n'est pas le souci actuel (c'est dans le kernel, cela demande des développements pour les sortir et les adapter à un chargement par le module firmware_class, ce n'est pas l'objet de la demande actuelle il me semble qui concerne bien l'installeur)
- pour les firmwares à l'extérieur des pilotes, ceux qui sont libres ne posent pas de souci (peuvent être fourni avec le kernel éventuellement), ceux qui sont non libres devraient atterrir dans non-free si ce n'est déjà fait (donc sortis du kernel, sortis de main) et donc pas avec le kernel, d'où le souci de l'installeur.
L'histoire du support de matériels est bien lié au fait que l'installeur dispose (par un moyen ou un autre) des firmwares libres ou non libres lors de l'install'. Cela n'est pas forcément évident à développer (cf. 1er lien de la dépêche) et pourrait prendre de l'ordre de 6 mois (soit au-delà de Décembre).
Sinon pour mon exemple d'eagle-usb, c'était surtout parce que je connais un peu et pour illustrer les firmwares directement dans le code (cela nécessite du boulot de les sortir). eagle-usb pour Linux était GPL, mais difficilement maintenable, avant que Damien Bergamini ne fasse le pilote pour *BSD. Matthieu avait aussi proposé un patch de séparation du firmware auparavant, ce qu'il a maintenu lorsqu'il a repris une partie des travaux de Damien pour créer ueagle-atm. bref, comme tu le dis pilote libre + closed-source firmware séparé + DSPcode (au lieu de pilote libre avec un firmware inclus + DSPcode externe), cela réclame du boulot et n'est pas l'objet de ce vote et continuera pendant et après Etch, par les développeurs de ces modules.
Pour Marco d'Itri, je ne remets pas en cause son implication, loin de là, en revanche il aiguillonne régulièrement dans les (longs) threads sur ce sujet, il a peut-être changé de manière dernièrement : sa méthode paraissait un peu moqueuse, un moyen de se détendre sans doute, mais avait la fâcheuse tendance à relancer d'autres threads). Je vais relire ses dernières interventions tiens ;-) Je ne doute pas qu'il préfèrerait des firmwares libres mais ce n'est (n'était ?) jamais le problème du moment, dans ses réponses AFAIR.
Le problème technique n'est pas que à la charge de Debian mais aux développeurs des pilotes (plutôt upstream) : cela devient à la charge de Debian si l'éthique prend le dessus et que le choix d'enlever tous les firmwares non libres est pris (AFAIK, seuls les firmwares déjà séparés du code ont été mis dans non-free ou gardés éventuellement dans main, il n'y a pas eu de pilote libre incluant du firmware libre enlevé, au contraire des pilotes non libres pour lesquels il y a eu un travail de nettoyage). Pour l'aspect juridique, c'est toujours un risque latent tant qu'il n'y a pas au mini une licence correcte de distribution sur les firmwares ou l'exemple que tu cites.
Mon commentaire souhaitait plutôt dire : dommage de continuer à se palucher des firmwares non libres non clairement identifiés en tant que non-free, parce qu'un problème de délai prend le dessus : c'est reporter à plus tard un point important côté éthique d'une part et conserver les conséquences du risque juridique d'autre part (qui se statuerait par l'éradication pure et simple du firmware, tant du kernel que des dépôts non-free d'ailleurs mais sans doute aussi du pilote s'appuyant dessus, sans solution à disposition dans l'immédiat). L'intérêt d'étiquetter clairement les firmwares non libres en les séparant est bien d'identifier plus facilement ce qui reste à remplacer par du libre (par ceux qui s'en sentirai ent capables) et conserver des pilotes libres clairement distincts de leur firmware.
[^] # Re: Pondération
Posté par BAud (site web personnel) . En réponse à la dépêche Le projet Debian lance une consultation sur les firmwares non-libres. Évalué à 5.
- l'installateur ne gère pas l'appel à un firmware externe non inclus dans le kernel (sur disquette, CD, clé usb, réseau, dépôt non-free), si c'est dans main l'installateur réussit à se débrouiller (mais main ne devrait pas avoir de non libre...)
- pour les firmwares encore en dur dans les pilotes (tableaux), libre ou non libre cela n'est pas le souci actuel (c'est dans le kernel, cela demande des développements pour les sortir et les adapter à un chargement par le module firmware_class, ce n'est pas l'objet de la demande actuelle il me semble qui concerne bien l'installeur)
- pour les firmwares à l'extérieur des pilotes, ceux qui sont libres ne posent pas de souci (peuvent être fourni avec le kernel éventuellement), ceux qui sont non libres devraient atterrir dans non-free si ce n'est déjà fait (donc sortis du kernel, sortis de main) et donc pas avec le kernel, d'où le souci de l'installeur.
L'histoire du support de matériels est bien lié au fait que l'installeur dispose (par un moyen ou un autre) des firmwares libres ou non libres lors de l'install'. Cela n'est pas forcément évident à développer (cf. 1er lien de la dépêche) et pourrait prendre de l'ordre de 6 mois (soit au-delà de Décembre).
Sinon pour mon exemple d'eagle-usb, c'était surtout parce que je connais un peu et pour illustrer les firmwares directement dans le code (cela nécessite du boulot de les sortir). eagle-usb pour Linux était GPL, mais difficilement maintenable, avant que Damien Bergamini ne fasse le pilote pour *BSD. Matthieu avait aussi proposé un patch de séparation du firmware auparavant, ce qu'il a maintenu lorsqu'il a repris une partie des travaux de Damien pour créer ueagle-atm. bref, comme tu le dis pilote libre + closed-source firmware séparé + DSPcode (au lieu de pilote libre avec un firmware inclus + DSPcode externe), cela réclame du boulot et n'est pas l'objet de ce vote et continuera pendant et après Etch, par les développeurs de ces modules.
Pour Marco d'Itri, je ne remets pas en cause son implication, loin de là, en revanche il aiguillonne régulièrement dans les (longs) threads sur ce sujet, il a peut-être changé de manière dernièrement : sa méthode paraissait un peu moqueuse, un moyen de se détendre sans doute, mais avait la fâcheuse tendance à relancer d'autres threads). Je vais relire ses dernières interventions tiens ;-) Je ne doute pas qu'il préfèrerait des firmwares libres mais ce n'est (n'était ?) jamais le problème du moment, dans ses réponses AFAIR.
Le problème technique n'est pas que à la charge de Debian mais aux développeurs des pilotes (plutôt upstream) : cela devient à la charge de Debian si l'éthique prend le dessus et que le choix d'enlever tous les firmwares non libres est pris (AFAIK, seuls les firmwares déjà séparés du code ont été mis dans non-free ou gardés éventuellement dans main, il n'y a pas eu de pilote libre incluant du firmware libre enlevé, au contraire des pilotes non libres pour lesquels il y a eu un travail de nettoyage). Pour l'aspect juridique, c'est toujours un risque latent tant qu'il n'y a pas au mini une licence correcte de distribution sur les firmwares ou l'exemple que tu cites.
Mon commentaire souhaitait plutôt dire : dommage de continuer à se palucher des firmwares non libres non clairement identifiés en tant que non-free, parce qu'un problème de délai prend le dessus : c'est reporter à plus tard un point important côté éthique d'une part et conserver les conséquences du risque juridique d'autre part (qui se statuerait par l'éradication pure et simple du firmware, tant du kernel que des dépôts non-free d'ailleurs mais sans doute aussi du pilote s'appuyant dessus, sans solution à disposition dans l'immédiat). L'intérêt d'étiquetter clairement les firmwares non libres en les séparant est bien d'identifier plus facilement ce qui reste à remplacer par du libre (par ceux qui s'en sentirai ent capables) et conserver des pilotes libres clairement distincts de leur firmware.