euh non pas un poil plus compliqué.
Comme tu le dis, la GPL est claire sur ce point en définissant "The source code for a work means the preferred form of the work for making modifications to it".
Pour un png, cela peut être le fichier dia dont c'est issu.
Ce n'est pas moi qui ait fourni dans un code source GPL une partie obfusquée (tableau de nombres hexa) qui n'est clairement pas la forme préférée pour y faire des modifications (de l'assembleur 8051 serait déjà mieux, voire plutôt le code C - initialement basé sur ezusb d'après nos supputations).
Pour moi, j'ai un bout de binaire compilé, dans du code C, sous GPL, bin je demande le source de cette partie-là aussi, quel que soit l'endroit où elle est exécutée.
En l'externalisant, il y a moyen de mettre une licence différente à ce binaire compilé (cela pourrait être la GPL et dans ce cas nous aurions le source). Ce n'est pas lié à linux comme tu le dis, c'est lié à la relation d'un binaire avec son code source (d'un logiciel particulier qui correspond au firmware).
J'espère avoir été plus clair.
ne perd pas ton temps, juste ne t'en occupe pas, éventuellement teste simplement que sur un système libre ce sera visionnable... ce qui n'est pas gagné.
Bon je crains de te classer dans le même camp que Marco d'Itri :p
J'ai eu l'occasion de faire cette demande des sources du firmware inclus en tableau de nombres hexa, dans un .h ou .c en GPL d'un pilote : je n'ai pas reçu satisfaction, pas de sources fournis.
J'attends de voir que les relations de travail avec cette société s'améliorent côté libre ou au minimum côté licence distribuable (firmware en 2-clause BSD, docs avec une licence correcte, ...). Néanmoins, je garde sous la main tout de même ce mail de réponse, qui va à l'encontre de la GPL. A l'occasion, cela permettra de voir avec http://gpl-violations.org si nous devons en arriver là.
[pourquoi pas] En tout cas, ton idée de dire c'est "librement distribuable" est un argument intéressant : sous GPL, sans la respecter (pas de source) => distribuable, ça se tente... me manquerait plus qu'une licence correcte pour le DSPcode maintenant.... [/pourquoi pas]
Renseigne-toi un peu : un satellite server, j'en ai un dans notre labo au taf', red hat le vend, couplé à Oracle et ce n'est pas une licence libre que j'ai reçue pour le satellite (pour la partie Oracle non plus, mais bon). Tu connais sûrement mieux le site de red hat que moi pour retrouver cette info ;-)
D'autre part, si tu me trouves un accès aux remontées d'infos à la hcl de red hat (hardware compatibility list et son bugzilla associé), cela m'intéresse.
Ton point est valide, il se trompe de cible : ce sont bien les constructeurs qui sont en cause et non Debian, il ne faudrait pas retourner le problème.
L'objectif porte bien sur avoir (ou pas) un installateur qui sait gérer ces firmwares qui relèvent par définition de non-free, permettant ainsi de supporter le matériel en cause. Cela apporterait un cadre clair, permettant de remplacer de façon plus transparente les firmwares proprios par du libre (remplacement de paquet) sans changer le pilote : à l'heure actuelle, bin la logique n'est pas encore implémentée.
pour Fedora effectivement (dans les grandes lignes... je ne vais pas ergoter sur les firmwares non libres en tableaux de nombres hexa trouvables dans tout kernel...).
En revanche, je te laisse me trouver la licence libre du Satellite Server fourni par Red Hat.
Cela ne remet pas en cause l'implication tant de Debian que de Red Hat pour le libre, hein.
Ya des perfections à apporter de partout, ce n'est pas de chance que Red Hat soit dans un pays avec des lois liberticides et qu'il est tout à fait compréhensible qu'une entreprise ne se permette pas d'aller à l'encontre des lois qu'elle doit subire.
heureusement qu'il y a le GPS dans ta batterie ;-)
non, sérieusement, tu pointes du doigt l'abberation de ce FUD des constructeurs qui ne savent pas comment réussir à respecter des législations inapplicables dans les faits, libre ou pas. Un FUD de simili-justification de faire du propriétaire, par manque de bonne raison.
Une réalité plutôt quand même...
à moins que tu ne fasses fi de la ML debian-legal, de tout le travail effectué par debian pour bazarder du kernel les pilotes non libres, de toutes les GR allant dans le sens des libertés ?
Après, c'est bien les utilisateurs qui demandent du non libre non ?
Pour rappel, non-libre c'est pas forcément que la faute de debian non plus, entre les problèmes de licences ou de brevets... et effectivement chaque distrib' est amené à isoler ces "mauvais" élèves :p
Cela a le mérite de trier pragmatiquement le bon grain de l'ivraie quand même, limite à contrecoeur, mais bon.
Cela permettra, par exemple, à des logiciels comme scilab de passer un jour en "main" lorsque la licence aura été changée... et de garder un historique tout de même.
Une liste tout de même pour ceux intéressés : ftp://ftp.fr.debian.org/debian/dists/unstable/non-free/binar(...)
Avoir des firmwares libres permet d'avoir un moyen (espoir) de les corriger s'ils sont buggués.
S'ils sont closed-source, il faut d'abord faire le reverse-engineering avant d'envisager corriger le problème.
Des firmwares libres ne sont pas que satisfaisants pour l'esprit, cela permet de faire des choses concrètes et ne pas se palucher ad vitam aeternam un matériel défaillant alors que l'utilisation d'un firmware permet justement d'avoir un moyen d'agir au niveau logiciel pour rattrapper des défauts de jeunesse :/ Après si tu peux te passer de périphériques au fonctionnement non optimal, libre à toi.
Plus de liberté, c'est mieux que moins non ?
Le firmware est du logiciel, la notion de libre (ou pas) s'y applique AMHA.
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.
J'ai l'impression que tu parles sur le court terme et dans ce cadre je suis d'accord avec toi que ce n'est pas le souci prioritaire d'une distribution Linux.
C'est néanmoins oublier que tout comme GNU, Debian n'a pas comme finalité que de tourner sur x86 / x86_64, ni ne prendre en compte que Linux, ... avec le contrat social j'y vois une logique long terme complémentaire du projet GNU tout de même, d'étendre ce qui est disponible en logiciel libre (que ce soit OS ou firmware, qui sont tous deux du logiciel) et de résorber le propriétaire qui leur reste aujourd'hui obligatoire (les firmwares par exemple).
Et je ne parle même pas des projets de matériel libre qui sont hors scope Debian.... comme OpenGraphics...
Pour la logique de quels firmwares sont à sélectionner pour être en libre et y travailler, c'est un sujet bien trop vaste pour que je me lance dans une quelconque hypothèse. Pour moi, il y aura des gens intéressés par des architectures qui peuvent te sembler ésotériques, ce seront eux qui sélectionneront ce qu'ils pourront mettre en libre (et ce seront effectivement des projets ensuite intégrés par les distributions) et petit à petit il y aura de plus en plus de matériel avec des firmwares libres.
Mais cela est distinct de la problématique d'un installeur capable de prendre en compte un firmware dans un autre dépôt et nous entraîne un peu trop loin :p
Cet installeur serait un maillon pour mixer OS libre et firmware (libre ou pas) et pousser la démarche ensuite plus loin (de plus en plus de firmwares libres aussi) : c'est une méthode d'ingénieur de séparer les problèmes différents pour les attaquer séparément.
Il ne faudrait pas se tromper de cible, ce n'est pas Debian qui est en cause, son approche du logiciel libre est légitime AMHA...
La logique voudrait que
1. le firmware ait une licence de distribution décente, c'est une prise de risque de debian (assumée) de continuer à distribuer de tels firmwares
2. je suppose que l'étape suivante est d'avoir un firmware libre, ce qui résoud le problème
Alors, oui, dans l'intermède il y a un contournement à trouver, merci au constructeur sur l'action :/
et comme dit précédemment, Debian continue néanmoins de distribuer ce qu'il faut, à sa place appropriée, dans non-free.
Ton "aucun problème" pour les closed-source firmware était peut être un peu péremptoire aussi non ? Pas besoin de se braquer, c'est une discussion libre, tu as un peu manqué d'argumentation ;-)
Tu as bien résumé la situation et je suis assez d'accord avec ton approche pragmatique sur les firmwares (notamment ton 3 pour du court terme).
Un bémol néanmoins, si - pour l'instant - il peut être judicieux de "comparer la problématique des firmwares à celle des images plutôt qu'à celle des logiciels" comme tu le dis il ne faut pourtant pas oublier sur le long terme qu' "Il s'agit de code qui ne tournera pas sous l'OS (sous Linux), ni même sur le CPU principal (que j'interprète comme tu le fais : il s'agit bien en fait de logiciel, il n'y a pas trop de raison de le traiter différemment a priori que le logiciel libre).
En effet, il peut tout à fait y avoir des bugs dans ce firmware et il est intéressant d'avoir les sources libres pour avoir quelquechose de fiable (et je ne parle même pas de backdoor dans du firmware de modem...).
Après, tout reste une question de transiger (ou pas) avec la liberté sur le long terme : ce travail de libération des firmwares aura sans doute lieu, la question AMHA revient bien à "maintenant ou dans la prochaine version ?".
Avoir dans Etch l'installeur qui sait faire appel aux firmwares déjà disponibles de manière séparée du pilote, déjà dans non-free, permettra de ne pas trop ralentir les efforts faits pour la liberté.
L'étape saine adoptée sur Debian pour les pilotes non-libres (systématiquement enlevés du kernel pour ceux qui restaient et placés dans non-free) pourra (AMHA en temps utile) être adoptée sur les firmwares : déjà les séparer systématiquement du code des pilotes (utilisation de firmware_class pour le chargement notamment, ce qui permet de placer les fichiers de firmware dans le repository non -free). Il ne faut pas oublier qu'il reste pas mal de pilotes ayant des déclarations de tableaux avec des suites de chiffres hexadécimaux généralement correspondant à un firmware) et que cela réclamera effectivement un peu de boulot (pendant et après Etch) pour scinder en deux ; nous avons eu ce boulot à faire sur eagle-usb, cela a par la suite permis d'avoir ueagle-atm qui est beaucoup plus propre grâce à Matthieu et le pilote de Damien Bergamini pour *BSD.
PS : j'ai réagi à ton post parce que ta distinction du CPU sur lequel tourne le firmware (CPU principal ou pas) me rappelle tout de même fortement l'argument récurrent (et trollesque) de Marco d'Itri (en résumé "on s'en fout, libre ou pas, vu que le firmware ne tourne pas sur le même CPU que le noyau linux") : c'est oublier que le firmware reste du logiciel et que la question de sa licence se pose réellement (notamment pour la distribution vu qu'il se retrouve sur une galette comme tu le dis, mais il est possible d'envisager d'aller plus loin puisqu'un firmware alternatif a son intérêt dans certains cas ; qui a parlé d'utiliser le processeur DSP des fast 800 pour faire de l'analyse de Fourier ;-) ).
quelqu'un aurait des retours d'expérience sur le qtek 2020i aussi connu sous le nom HTC Himalaya je crois... (j'ai un peu de mal à trouver les équivalences dans les noms... si quelqu'un peut confirmer ?)
A moins d'établir le fait qu'aucune imprimante ne fonctionne sous Linux, invoquer la clause d'interopérabilité est contestable dans la mesure où l'on peut se voir répondre "qu'il existe pléthore d'autres marques qui fonctionnent nickel sous Linux"...
heureusement que la clause d'interopérabilité concerne le matériel récalcitrant en question et ne se résume pas, comme tu sembles le faire, à dire "z'avez qu'à acheter un autre modèle qui lui marche" (toute ressemblance avec le discours des constructeurs serait purement fortuite).
dès lors que tu as plus de 128 Mo, la 2006 s'installera.
ce qui est structurant pour une install' c'est la mémoire disponible, pas le processeur.
cela te permettra de disposer d'une distribution supportée (i.e. qui a des mises à jour de sécurité notamment) et avec les versions de logiciels récentes (bon yaura la 2007 bientôt...).
et pourquoi ne pas utiliser une mandriva 2006 qui est bien plus récente et aura ces soucis (ainsi que d'autres...) déjà résolus ?
cf. http://www.mandriva.com/fr/community/mandrivaone pour utiliser le live-cd qui permet une install'
si j'ai bien vu, aucun des deux ne lit le ogg/vorbis pour l'audio ?
pas de matroska ou xvid non plus pour la vidéo ?
quelles seraient les capacités à mettre à jour les codecs sur ces appareils (hormis en racheter un) ? ça évitera de les transformer en jolis dessous de table design.
la réponse comme indiqué plus haut est simple : ce n'est pas libre, mieux vaut promouvoir autre chose.
1. mouais et ?
2. donc ?
3. ah ? stout ? ça servait à quoi d'en parler alors ?
et
1. si, celui qui l'installe à ses dépends par la suite et celui qui voit qu'on lui a vendu du libre et qu'en fait il y a d'autres choses
2. tu emprisonnes potentiellement l'utilisateur, c'est lui rendre service ?
3. et ? l'alternative est directement proposée ?
mais je ne t'en veux pas de le mentionner, au contraire, il y a matière à néanmoins contribuer au libre par la critique évoquée ci-dessus.
à toute fin utile, je te rappelle la charte de tuxfamily.org que tu as accepté http://tuxfamily.org/fr/subscribe ... (ça parle de promotion du libre).
Cela ne me dérange personnellement pas trop qu'il y ait du perso tant que l'objectif principal reste de promouvoir le libre. De même que sur linuxfr, quand nous laissons passer un logiciel propriétaire, il est bon de mettre une NdM rappellant les logiciels libres répondant aux mêmes besoins.
Après faire un comparatif proprio / lbre pour que le libre avance ça m'irait bien... Ensuite ne promouvoir que du proprio (y compris les freeware bien sûr), là ça me gêne.
Merci de corriger en identifiant ce qui se fait en libre et pourquoi cela ne répond pas (encore) au besoin : cela sera bon esprit et bien mieux accepté.
Comme vu plus bas, il n'est pas question de sectarisme mais bien de la contribution au libre qui est possible : faire des critiques est toujours le bienvenu lorsque cela est argumenté, se baser sur du proprio pour le faire passe parfois mal et c'est bien dommage (il n'y a pas que le libre qui a de bonnes idées), promouvoir le proprio en revanche m'a l'air d'aller à l'encontre de l'objectif commun visé. Mieux vaut donc ajouter dans le corps du texte l'équivalent en libre (en pointant du doigt ce qui lui manque et ce qu'il aurait néanmoins en plus outre la liberté, après reporter une wishlist sur les bugzilla appropriés peut être opportun mais pas forcément obligatoire).
N.B. : même si la liste http://linuxetleschoses.tuxfamily.org/rubrique.php3?id_rubri(...) te paraît claire, il me paraît plus opportun de mettre directement dans ton article le concurrent direct en pointant les avantages respectifs de l'un et de l'autre. Cela permettra effectivement à l'utilisateur de choisir en connaissance de cause.
PS : idem pour kiko / google calendar qui ne sont pas libres (impact immédiat : pas d'installation sur son serveur, enfermement des données dans un format hypothétiquement récupérable voire ouvert), promouvoir webcalendar par exemple...
En résumé : bof pour du proprio, si cela permet de mettre en avant une solution libre en identifiant des axes d'amélioration, pourquoi pas ? (la critique a souvent du bon et je crois que ton site s'y prête bien sans donner lieu à de concession avec une approche libre).
bin "juste ça marche maintenant" pour que tu sois obligé de racheter quelquechose dans 3 ans parce que les formats ne sont plus supportés et t'imposent les DRM ce serait tout de même dommage non ?
Autant garder le PC dans ce cas... la facilité d'usage pour moi est beaucoup lié à prendre en compte ce dont je dispose :/
[^] # 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.
Comme tu le dis, la GPL est claire sur ce point en définissant "The source code for a work means the preferred form of the work for making modifications to it".
Pour un png, cela peut être le fichier dia dont c'est issu.
Ce n'est pas moi qui ait fourni dans un code source GPL une partie obfusquée (tableau de nombres hexa) qui n'est clairement pas la forme préférée pour y faire des modifications (de l'assembleur 8051 serait déjà mieux, voire plutôt le code C - initialement basé sur ezusb d'après nos supputations).
Pour moi, j'ai un bout de binaire compilé, dans du code C, sous GPL, bin je demande le source de cette partie-là aussi, quel que soit l'endroit où elle est exécutée.
En l'externalisant, il y a moyen de mettre une licence différente à ce binaire compilé (cela pourrait être la GPL et dans ce cas nous aurions le source). Ce n'est pas lié à linux comme tu le dis, c'est lié à la relation d'un binaire avec son code source (d'un logiciel particulier qui correspond au firmware).
J'espère avoir été plus clair.
# sérieux
Posté par BAud (site web personnel) . En réponse au message Cherche système de DRM libre. Évalué à 2.
[^] # 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é à 3.
J'ai eu l'occasion de faire cette demande des sources du firmware inclus en tableau de nombres hexa, dans un .h ou .c en GPL d'un pilote : je n'ai pas reçu satisfaction, pas de sources fournis.
J'attends de voir que les relations de travail avec cette société s'améliorent côté libre ou au minimum côté licence distribuable (firmware en 2-clause BSD, docs avec une licence correcte, ...). Néanmoins, je garde sous la main tout de même ce mail de réponse, qui va à l'encontre de la GPL. A l'occasion, cela permettra de voir avec http://gpl-violations.org si nous devons en arriver là.
[pourquoi pas] En tout cas, ton idée de dire c'est "librement distribuable" est un argument intéressant : sous GPL, sans la respecter (pas de source) => distribuable, ça se tente... me manquerait plus qu'une licence correcte pour le DSPcode maintenant.... [/pourquoi pas]
[^] # 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é à 2.
bon je te donne la note technique tout de même : http://www.redhat.com/docs/manuals/RHNetwork/fr/release-note(...) (oui : le rhn est distribué, contrairement à launchpad qui n'est pas disponible en libre non plus).
D'autre part, si tu me trouves un accès aux remontées d'infos à la hcl de red hat (hardware compatibility list et son bugzilla associé), cela m'intéresse.
# games
Posté par BAud (site web personnel) . En réponse au message plateforme de jeux réseau gratuite pour mandriva. Évalué à 2.
http://faq.tuxfamily.org/wakka.php?wiki=JeuxTuxFamily
et passer sur irc.freenode.net #nekeme pour prendre des nouvelles du FGS (Free Gaming System) http://freegs.net/ et http://projects.nekeme.net/projects/fgs/wiki
[^] # 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é à 2.
L'objectif porte bien sur avoir (ou pas) un installateur qui sait gérer ces firmwares qui relèvent par définition de non-free, permettant ainsi de supporter le matériel en cause. Cela apporterait un cadre clair, permettant de remplacer de façon plus transparente les firmwares proprios par du libre (remplacement de paquet) sans changer le pilote : à l'heure actuelle, bin la logique n'est pas encore implémentée.
Nous n'allons pas refaire une discussion qui mène à https://linuxfr.org/2005/12/08/20027.html Pilotes binaires dans Linux: quel est le problème ?
[^] # 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é à 2.
En revanche, je te laisse me trouver la licence libre du Satellite Server fourni par Red Hat.
Cela ne remet pas en cause l'implication tant de Debian que de Red Hat pour le libre, hein.
Ya des perfections à apporter de partout, ce n'est pas de chance que Red Hat soit dans un pays avec des lois liberticides et qu'il est tout à fait compréhensible qu'une entreprise ne se permette pas d'aller à l'encontre des lois qu'elle doit subire.
[^] # Re: Question HS sur le wifi...
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é à 4.
non, sérieusement, tu pointes du doigt l'abberation de ce FUD des constructeurs qui ne savent pas comment réussir à respecter des législations inapplicables dans les faits, libre ou pas. Un FUD de simili-justification de faire du propriétaire, par manque de bonne raison.
[^] # Re: Et bien ...
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é à 4.
à moins que tu ne fasses fi de la ML debian-legal, de tout le travail effectué par debian pour bazarder du kernel les pilotes non libres, de toutes les GR allant dans le sens des libertés ?
Après, c'est bien les utilisateurs qui demandent du non libre non ?
Pour rappel, non-libre c'est pas forcément que la faute de debian non plus, entre les problèmes de licences ou de brevets... et effectivement chaque distrib' est amené à isoler ces "mauvais" élèves :p
Cela a le mérite de trier pragmatiquement le bon grain de l'ivraie quand même, limite à contrecoeur, mais bon.
Cela permettra, par exemple, à des logiciels comme scilab de passer un jour en "main" lorsque la licence aura été changée... et de garder un historique tout de même.
Une liste tout de même pour ceux intéressés : ftp://ftp.fr.debian.org/debian/dists/unstable/non-free/binar(...)
[^] # Re: Firmware et systèmes distribués
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é à 4.
S'ils sont closed-source, il faut d'abord faire le reverse-engineering avant d'envisager corriger le problème.
Des firmwares libres ne sont pas que satisfaisants pour l'esprit, cela permet de faire des choses concrètes et ne pas se palucher ad vitam aeternam un matériel défaillant alors que l'utilisation d'un firmware permet justement d'avoir un moyen d'agir au niveau logiciel pour rattrapper des défauts de jeunesse :/ Après si tu peux te passer de périphériques au fonctionnement non optimal, libre à toi.
Plus de liberté, c'est mieux que moins non ?
Le firmware est du logiciel, la notion de libre (ou pas) s'y applique AMHA.
[^] # 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.
[^] # 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é à 2.
C'est néanmoins oublier que tout comme GNU, Debian n'a pas comme finalité que de tourner sur x86 / x86_64, ni ne prendre en compte que Linux, ... avec le contrat social j'y vois une logique long terme complémentaire du projet GNU tout de même, d'étendre ce qui est disponible en logiciel libre (que ce soit OS ou firmware, qui sont tous deux du logiciel) et de résorber le propriétaire qui leur reste aujourd'hui obligatoire (les firmwares par exemple).
Et je ne parle même pas des projets de matériel libre qui sont hors scope Debian.... comme OpenGraphics...
Pour la logique de quels firmwares sont à sélectionner pour être en libre et y travailler, c'est un sujet bien trop vaste pour que je me lance dans une quelconque hypothèse. Pour moi, il y aura des gens intéressés par des architectures qui peuvent te sembler ésotériques, ce seront eux qui sélectionneront ce qu'ils pourront mettre en libre (et ce seront effectivement des projets ensuite intégrés par les distributions) et petit à petit il y aura de plus en plus de matériel avec des firmwares libres.
Mais cela est distinct de la problématique d'un installeur capable de prendre en compte un firmware dans un autre dépôt et nous entraîne un peu trop loin :p
Cet installeur serait un maillon pour mixer OS libre et firmware (libre ou pas) et pousser la démarche ensuite plus loin (de plus en plus de firmwares libres aussi) : c'est une méthode d'ingénieur de séparer les problèmes différents pour les attaquer séparément.
[^] # 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é à 3.
La logique voudrait que
1. le firmware ait une licence de distribution décente, c'est une prise de risque de debian (assumée) de continuer à distribuer de tels firmwares
2. je suppose que l'étape suivante est d'avoir un firmware libre, ce qui résoud le problème
Alors, oui, dans l'intermède il y a un contournement à trouver, merci au constructeur sur l'action :/
et comme dit précédemment, Debian continue néanmoins de distribuer ce qu'il faut, à sa place appropriée, dans non-free.
[^] # Re: Une 4ème option ?
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é à 4.
Une recherche rapide donne
https://linuxfr.org/2004/10/28/17539.html [fr] OpenBSD milite pour un changement des licences des firmwares TI et Intel
http://hardware.slashdot.org/article.pl?sid=04/11/22/1249249(...) [en] Update On OpenBSD Firmware Activism (2004)
http://kerneltrap.org/node/4818 [en] OpenBSD's "Out of the Box" Wireless Support (2005)
http://marc.theaimsgroup.com/?l=openbsd-misc&m=109889560(...) [en] Firmware license - clarification (2004 by Theo)
http://www.google.fr/search?hl=fr&q=license+openbsd+firm(...)
(voilà un peu d'eau au moulin et les soucis que cela peut causer de ne pas avoir de licence correcte)
[^] # 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é à 4.
Un bémol néanmoins, si - pour l'instant - il peut être judicieux de "comparer la problématique des firmwares à celle des images plutôt qu'à celle des logiciels" comme tu le dis il ne faut pourtant pas oublier sur le long terme qu' "Il s'agit de code qui ne tournera pas sous l'OS (sous Linux), ni même sur le CPU principal (que j'interprète comme tu le fais : il s'agit bien en fait de logiciel, il n'y a pas trop de raison de le traiter différemment a priori que le logiciel libre).
En effet, il peut tout à fait y avoir des bugs dans ce firmware et il est intéressant d'avoir les sources libres pour avoir quelquechose de fiable (et je ne parle même pas de backdoor dans du firmware de modem...).
Après, tout reste une question de transiger (ou pas) avec la liberté sur le long terme : ce travail de libération des firmwares aura sans doute lieu, la question AMHA revient bien à "maintenant ou dans la prochaine version ?".
Avoir dans Etch l'installeur qui sait faire appel aux firmwares déjà disponibles de manière séparée du pilote, déjà dans non-free, permettra de ne pas trop ralentir les efforts faits pour la liberté.
L'étape saine adoptée sur Debian pour les pilotes non-libres (systématiquement enlevés du kernel pour ceux qui restaient et placés dans non-free) pourra (AMHA en temps utile) être adoptée sur les firmwares : déjà les séparer systématiquement du code des pilotes (utilisation de firmware_class pour le chargement notamment, ce qui permet de placer les fichiers de firmware dans le repository non -free). Il ne faut pas oublier qu'il reste pas mal de pilotes ayant des déclarations de tableaux avec des suites de chiffres hexadécimaux généralement correspondant à un firmware) et que cela réclamera effectivement un peu de boulot (pendant et après Etch) pour scinder en deux ; nous avons eu ce boulot à faire sur eagle-usb, cela a par la suite permis d'avoir ueagle-atm qui est beaucoup plus propre grâce à Matthieu et le pilote de Damien Bergamini pour *BSD.
PS : j'ai réagi à ton post parce que ta distinction du CPU sur lequel tourne le firmware (CPU principal ou pas) me rappelle tout de même fortement l'argument récurrent (et trollesque) de Marco d'Itri (en résumé "on s'en fout, libre ou pas, vu que le firmware ne tourne pas sur le même CPU que le noyau linux") : c'est oublier que le firmware reste du logiciel et que la question de sa licence se pose réellement (notamment pour la distribution vu qu'il se retrouve sur une galette comme tu le dis, mais il est possible d'envisager d'aller plus loin puisqu'un firmware alternatif a son intérêt dans certains cas ; qui a parlé d'utiliser le processeur DSP des fast 800 pour faire de l'analyse de Fourier ;-) ).
[^] # Re: Si j'ai tout bien compris...
Posté par BAud (site web personnel) . En réponse au journal Recensement des besoins des projets libres. Évalué à 2.
mais effectivement j'avais en tête ces pages :
http://atm.eagle-usb.org/wakka.php?wiki=UeagleAtmDocFr
http://dev.eagle-usb.org/wakka.php?wiki=LocalizationScriptsU(...)
qui ne sont pas foncièrement longues à traduire...
# qtek 2020i
Posté par BAud (site web personnel) . En réponse à la dépêche Sortie de Familiar Linux 0.8.4. Évalué à 2.
d'après http://handhelds.org/moin/moin.cgi/SupportedHandheldSummary
et http://handhelds.org/moin/moin.cgi/Himalaya linux a l'air de booter mais y-a-t-il moyen d'aller un peu plus loin tout de même ? (genre se connecter en ssh au mini par lancement d'un serveur ?).
[^] # Re: Erratum
Posté par BAud (site web personnel) . En réponse à la dépêche Premiers pilotes libres pour les imprimantes Samsung. Évalué à 6.
heureusement que la clause d'interopérabilité concerne le matériel récalcitrant en question et ne se résume pas, comme tu sembles le faire, à dire "z'avez qu'à acheter un autre modèle qui lui marche" (toute ressemblance avec le discours des constructeurs serait purement fortuite).
[^] # Re: 2006
Posté par BAud (site web personnel) . En réponse au message 2 problémes le sons et l'arret de mdk 10.1. Évalué à 2.
ce qui est structurant pour une install' c'est la mémoire disponible, pas le processeur.
cela te permettra de disposer d'une distribution supportée (i.e. qui a des mises à jour de sécurité notamment) et avec les versions de logiciels récentes (bon yaura la 2007 bientôt...).
# 2006
Posté par BAud (site web personnel) . En réponse au message 2 problémes le sons et l'arret de mdk 10.1. Évalué à 2.
cf. http://www.mandriva.com/fr/community/mandrivaone pour utiliser le live-cd qui permet une install'
# redimensionner
Posté par BAud (site web personnel) . En réponse au journal GTK Batch Resizer. Évalué à 2.
sinon ça fait bizarre d'avoir une interface graphique contenant le mot "batch" mais bon ça change des pyphotoresize ;-)
j'espère que tu auras pas mal de testeurs, perso j'ai pas encore d'appareil photo numérique :/
[^] # Re: recherches
Posté par BAud (site web personnel) . En réponse au message Le multi media : doutes persos .. Évalué à 3.
pas de matroska ou xvid non plus pour la vidéo ?
quelles seraient les capacités à mettre à jour les codecs sur ces appareils (hormis en racheter un) ? ça évitera de les transformer en jolis dessous de table design.
[^] # Re: Et la cohérence ?
Posté par BAud (site web personnel) . En réponse à la dépêche Linux et les Choses. Évalué à 4.
1. mouais et ?
2. donc ?
3. ah ? stout ? ça servait à quoi d'en parler alors ?
et
1. si, celui qui l'installe à ses dépends par la suite et celui qui voit qu'on lui a vendu du libre et qu'en fait il y a d'autres choses
2. tu emprisonnes potentiellement l'utilisateur, c'est lui rendre service ?
3. et ? l'alternative est directement proposée ?
mais je ne t'en veux pas de le mentionner, au contraire, il y a matière à néanmoins contribuer au libre par la critique évoquée ci-dessus.
[^] # Re: Et la cohérence ?
Posté par BAud (site web personnel) . En réponse à la dépêche Linux et les Choses. Évalué à 2.
Cela ne me dérange personnellement pas trop qu'il y ait du perso tant que l'objectif principal reste de promouvoir le libre. De même que sur linuxfr, quand nous laissons passer un logiciel propriétaire, il est bon de mettre une NdM rappellant les logiciels libres répondant aux mêmes besoins.
Après faire un comparatif proprio / lbre pour que le libre avance ça m'irait bien... Ensuite ne promouvoir que du proprio (y compris les freeware bien sûr), là ça me gêne.
Merci de corriger en identifiant ce qui se fait en libre et pourquoi cela ne répond pas (encore) au besoin : cela sera bon esprit et bien mieux accepté.
Comme vu plus bas, il n'est pas question de sectarisme mais bien de la contribution au libre qui est possible : faire des critiques est toujours le bienvenu lorsque cela est argumenté, se baser sur du proprio pour le faire passe parfois mal et c'est bien dommage (il n'y a pas que le libre qui a de bonnes idées), promouvoir le proprio en revanche m'a l'air d'aller à l'encontre de l'objectif commun visé. Mieux vaut donc ajouter dans le corps du texte l'équivalent en libre (en pointant du doigt ce qui lui manque et ce qu'il aurait néanmoins en plus outre la liberté, après reporter une wishlist sur les bugzilla appropriés peut être opportun mais pas forcément obligatoire).
N.B. : même si la liste http://linuxetleschoses.tuxfamily.org/rubrique.php3?id_rubri(...) te paraît claire, il me paraît plus opportun de mettre directement dans ton article le concurrent direct en pointant les avantages respectifs de l'un et de l'autre. Cela permettra effectivement à l'utilisateur de choisir en connaissance de cause.
PS : idem pour kiko / google calendar qui ne sont pas libres (impact immédiat : pas d'installation sur son serveur, enfermement des données dans un format hypothétiquement récupérable voire ouvert), promouvoir webcalendar par exemple...
En résumé : bof pour du proprio, si cela permet de mettre en avant une solution libre en identifiant des axes d'amélioration, pourquoi pas ? (la critique a souvent du bon et je crois que ton site s'y prête bien sans donner lieu à de concession avec une approche libre).
[^] # Re: recherches
Posté par BAud (site web personnel) . En réponse au message Le multi media : doutes persos .. Évalué à 2.
Autant garder le PC dans ce cas... la facilité d'usage pour moi est beaucoup lié à prendre en compte ce dont je dispose :/