Le principal problème qu'ils posent est le fait qu'il n'est actuellement pas possible d'installer Debian sur un système nécessitant un paquet (contenant un firmware) provenant de la section non-free de Debian. Cela remet en cause la sortie (prévue en décembre) de Debian Etch, à cause des modifications qui seraient nécessaires à l'installateur de Debian.
Toutefois, pour la première fois, le projet Debian s'ouvre à une double consultation : d'une part, classiquement, auprès de ses développeurs et d'autre part, auprès des utilisateurs (via un vote sur un forum). Les solutions possibles peuvent se résumer à :
- Sortir Etch comme prévu, avec des firmwares non-libres dans 'main'
- Sortir Etch comme prévu, mais sans les firmwares non-libres dans 'main'
- Retarder la sortie d'Etch jusqu'à ce que les modifications nécessaires aient été faites dans l'installateur.
Il faut aussi remarquer que c'est la deuxième fois en quelques mois que le projet Debian se pose ainsi la question d'un compromis avec la liberté. Ainsi, en mars dernier, le projet avait décidé dans une résolution générale que les documents sous licence GNU Free Documentation License étaient libres s'ils ne contenaient pas de section invariante.
Aller plus loin
- Message du responsable du projet Debian sur debian-devel-announce (4 clics)
- Le résultat en direct du vote des développeurs (3 clics)
- Le vote des utilisateurs (1ère question) (4 clics)
- Le vote des utilisateurs (2ème question) (4 clics)
- La résolution générale sur la liberté des contenus sous GFDL (6 clics)
# Et bien ...
Posté par Jaimé Ragnagna (site web personnel) . Évalué à 4.
Debian a toujours ete plus que pointilleux concernant les questions de savoir si un composant de la distrib est libre ou pas. Il est quand meme enorme de passer a cote du fait que l'installateur limiterait les fonctionnalites disponibles en fin de compte a l'utilisateur a cause de son hardware....
Personnelement je serai plutot d'avis de repousser etch. Ca me semble etre la position la plus equilibree : d'un cote, debian gardera une distribution "libre", et de l'autre les utilisateurs pourront choisir en leur ame et conscience d'integrer des modules non libres sur leur machine.
Le choix de sortir Etch en l'etat n'aura qu'une consequence : au pire degouter les utilisateurs de linux, au mieux les pousser a choisir une autre distribution (qui a dit Ubuntu ? ). Et ensuite, les debianneux pourront continuer a cracher leur venin sur les autres distributions qui leur piquent des utilisateurs.
Enfin pour finir, je dois dire qu'il est triste de retarder la distrib juste a cause de l'installateur. Le plus simple n'est il pas de le laisser tomber au moins pour la release de etch, quitte a le reintegrer apres ? Je ne suis plus un debian-user mais je me souviens qu'a l'epoque l'installateur fonctionnait tres bien.
[^] # Re: Et bien ...
Posté par Pierre Tramo (site web personnel) . Évalué à 9.
Oui, après la liberté, c'est une autre valeur fondamentale de Debian, la ponctualité, qui est remise en cause, c'est vraiment dommage.
J'espère que Etch pourra quand même sortir avant Vista, histoire de mettre la pression sur Microsoft, à la fois en terme de qualité et de ponctualité !
[^] # Re: Et bien ...
Posté par lolop (site web personnel) . Évalué à 10.
J'imagine bien que les "team leaders" des équipes de développement de Vista ont les yeux rivés sur l'avancée de Etch et sa date de sortie.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Et bien ...
Posté par kraman . Évalué à -1.
mouarf.
Cela dit, le principal interet que je vois a cette discussion, c'est qu'au moins pendant la periode de la consultation, les debiannards seront tellement occupes a se taper dessus qu'ils vont la fermer sur booboontoo et enfin nous foutre la paix.
[^] # Re: Et bien ...
Posté par ome . Évalué à -1.
Merci quand mêrme pour la bonne tranche de rigolade!
[^] # Re: Et bien ...
Posté par Yth (Mastodon) . Évalué à 7.
Tant d'humour et si peu de reconnaissance !
Yth, qui a ri.
[^] # Re: Et bien ...
Posté par François B. . Évalué à 2.
Maintenant, je ne présume pas savoir exactement ce qui s'est passé : je ne suis pas DD, et vu le volume de la liste j'ai peut-être également raté des informations.
[^] # Re: Et bien ...
Posté par Sylvain Sauvage . Évalué à 6.
Ensuite, tu veux « laisser tomber l'installateur ». Comment on installe alors ? Avec l'ancienne méthode, qui ne reconnaît pas le matériel récent, qui ne permet pas d'utiliser un noyau récent, que tout le monde qualifie d'obsolète et qu'il a fallu refondre parce qu'elle ne pouvait plus évoluer ? Cela revient à installer une Sarge et à faire une upgrade ensuite...
[^] # Re: Et bien ...
Posté par clearstream . Évalué à 3.
C'est de l'humour ?
Depuis toujours Debian fait des paquets non-libre, fournit de la bande passante pour les diffuser, suit les bugs, etc...
[^] # Re: Et bien ...
Posté par BAud (site web personnel) . É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: Et bien ...
Posté par clearstream . Évalué à 3.
Ca c'est très bien. Surtout par rapport à la chartre de Debian.
> Après, c'est bien les utilisateurs qui demandent du non libre non ?
Les utilisateurs, ce n'est pas Debian, ils n'ont une chartre.
Mais Debian qui prétend faire uniquement du libre, fait du non-libre ! Packagé par Debian, hébergé par Debian, diffusé par Debian, etc...
Fedora dit ne faire que du libre et ils ne font que du libre. L'utilisateur qui veut installer du proprio va voir ailleur que sur les sites officiels (supportés) par Fedora.
Fedora n'interdit pas livna (ce serait un comble), mais Fedora ne supporte pas livna (on y trouve des paquets proprio pour Fedora).
Debian n'interdit pas non-libre, mais Debian supporte pleinement non-libre.
Fedora fait que du libre et en supporte les conséquences (utilisateurs qui gueulent car il n'y a pas mp3, etc).
Que je sache, jamais les utilisateurs de Debian ne plaignent du manque de mp3, nvidia, libcss, acroreader, flash, etc... Ils n'ont pas de raison de se plaindre car c'est quasi pleinement supporté par Debian.
La charte de Debian est bien jolie sur le papier, mais dans la pratique elle ne vaut rien (à part casser les couilles aux développeurs pour bien spliter main de non-libre).
Si je suis une boite qui fait du proprio, Debian va faire le paquet, l'héberger, fournir la bande passante, faire une place dans son bugzilla, faciliter l'accès au paquet, etc...
Fedora rien.
Tu vois la différence ?
[^] # Re: Et bien ...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
Parce que tu as déjà essayé de faire rentrer un logiciel propriétaire en tant que paquet debian ? Si tu regardes les derniers paquets qui y sont entrés[1], il s'agit surtout de documentation ou de fichiers de données qui ne sont pas libres (certes, au sens DFSG-compliant du terme car le projet Debian ne reconnait pas la licence GNU FDL comme libre) et à part l'implémentation java de Sun, peu de logiciels vraiment propriétaires y sont présents et certains sans doute depuis longtemps.
[1]: http://packages.debian.org/unstable/newpkg_non-free
[^] # Re: Et bien ...
Posté par Sylvain Sauvage . Évalué à 6.
Et puis l'argument « depuis longtemps » ne tient pas non plus : plus ça fait longtemps qu'un logiciel propriétaire est là, plus il s'est passé de temps pendant lequel il aurait pu/dû être viré/remplacé.
Les logiciels propriétaires de non-free, c'était surtout netscape, parce qu'il n'y avait pas d'alternative libre (application du principe « pour l'utilisateur » de la Charte). Mais il a été viré depuis.
Sinon, quand je fais un vrms chez moi, c'est principalement les paquets de fontes qui apparaissent et un aperçu de aptitude search ~snon-free m'indique surtout des fontes, des docs, des données de jeux (p.ex. les doom-wad), les pilotes proprios (p.ex. ati, nvidia), le jdk de Sun, xmame et xaralx.
Notons que squeak n'est toujours pas dans Debian (ni non-free)...
Certains considèrent que la politique de Debian envers la GFDL est un peu poussée. Que pensent-ils de la politique de Debian concernant les fontes, le jdk, etc. ?
Que font les autres distributions ?
[^] # Re: Et bien ...
Posté par gpe . Évalué à 2.
- mp3 n'est pas dans non-free (c'est dans main)
- acroread n'est pas dans non-free (on le trouve sur des dépôts extérieurs)
- flash n'est pas dans non-free (seul un paquet permettant de télécharger le binaire et de l'installer se trouve dans main)
- libcss n'est pas dans non-free (dépôts extérieurs)
- java n'est pas dans non-free (seul un paquet, permettant de créer un deb depuis le binaire de sun, existe dans main)
Bref à part nvidia qui est effectivement dans non-free ça ne consomme pas tant de bande passante que ça et ce n'est pas supporté pas Debian.
[^] # Re: Et bien ...
Posté par proum . Évalué à 6.
Java est dans non-free depuis le dernier changement de licence. Le paquet pour créer un .deb est dans contrib, et pas dans main.
[^] # Re: Et bien ...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
À noter que le support des mp3 n'est pas disponible sous RedHat/Fedora. Ce n'est pas tant un problème de logiciels libres qu'un problème de brevets logiciels américains ;-)
# Quel que soit le pour et le contre...
Posté par Julien MOROT (site web personnel) . Évalué à 3.
Si ça continue, les mêmes retards que pour la sarge risquent de se produire. Il aurait été plus judicieux de se poser la question au début du cycle de développement.
[^] # Re: Quel que soit le pour et le contre...
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 3.
Je trouve dommage de réduire la problématique en ces termes.
De manière générale, si tous les problèmes pouvaient être traités avant même qu'ils n'apparaissent on vivrait dans un monde idylique. Heureusement, il y a des problèmes à traiter et du coup, y'a du boulot.
Moins ironiquement, il faut se réjouir que les problèmes restants soient de cet ordre et que la question de leur priorité soit posée. Ce dernier point nous offre une chance de ne pas retomber dans le modèle Sarge.
[^] # Re: Quel que soit le pour et le contre...
Posté par Julien MOROT (site web personnel) . Évalué à 5.
Maintenant c'est quelque chose qui a été voté en 2004 la résolution sur les firmware non libres :
http://www.debian.org/vote/2004/vote_003
# Une 4ème option ?
Posté par Anonyme . Évalué à 5.
Si je devais transiger sur du closed source ca serait en user-land et certainement pas dans l'espace du noyau. Je ne vais surement pas faire tourner du code fermé et donc non-auditable en mode non protégé.
Sans parler du design souvent discutable de ces blobs (exemple du driver wifi intel qui réinvente 4 fois la roue alors qu'on aura bientôt (j'espère) la superbe pile devicescape)
Je sais c'est contraignant, pour l'achat de mon portable en trouver un ayant à la fois un chip graphique intel et un chip wifi atheros n'a pas été facile, mais vu la stabilité je ne changerai pour rien au monde (enfin si mais quand les futurs chip intel g965 et chip atheros 802.11n seront sortis ^^)
Le problème c'est qu'avec le succès de la plateforme centrino, ca va devenir très dur de trouver autre chose que du intel en chip wifi intégré. Donc si le travail d'ingénieurie inverse et de redesign complet du driver wifi intel commencé pour OpenBSD 4.0 pouvait inspiré Linux ca serait vraiment une bonne chose.
Plus d'info:
http://linuxfr.org/~patrick_g/21744.html
[^] # Re: Une 4ème option ?
Posté par Aldoo . Évalué à 10.
La différence est de taille : l'un s'exécute sur le processeur principal avec tous les droits, l'autre s'exécute sur le périphérique concerné seulement (avec tous les droits sur le périphérique, mais ça s'arrête ici, si le module noyau correspondant est ouvert et bien foutu). Le résultat, c'est que le périphérique avec le firmware chargé revient finalement à un périphérique tout court, du point de vue du noyau.
On ne sait pas exactement ce qui s'y passe, mais ce serait pareil pour un périphérique sans firmware.
Le problème finalement, avec ces firmwares, est plutôt du côté de la distribution : en effet, la galette d'installation du système dit "libre" contient des morceaux non libres, et tu ne peux donc pas coller l'étiquette "libre" sur le CD. Sans compter qu'il est possible que certains firmwares aient une licence ne permettant même pas la redistribution...
Je ne suis pas trop au courant de ce qui se fait chez debian, mais ça m'étonnerait qu'ils autorisent le moindre blob dans leur distrib. S'il y a des intAIgristes, c'est bien eux !
[^] # Re: Une 4ème option ?
Posté par Aldoo . Évalué à 7.
[^] # Re: Une 4ème option ?
Posté par Anonyme . Évalué à -2.
Je pense que si mais je me demande surtout si à la base un firmware ca n'est pas censé être dans la rom associée au chip et on a pas à y toucher sauf en cas de flashage ? Car si cela doit être chargé à l'initialisation comme semble le suggérer les problèmes de licenses, je me demande bien comment fait OpenBSD, je le voit pas vraiment inclure un firmware proprio dans son kernel.
[^] # Re: Une 4ème option ?
Posté par lasher . Évalué à 8.
[^] # Re: Une 4ème option ?
Posté par panda panda . Évalué à 5.
[^] # Re: Une 4ème option ?
Posté par lasher . Évalué à 2.
[^] # Re: Une 4ème option ?
Posté par BAud (site web personnel) . É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: Une 4ème option ?
Posté par snt . Évalué à 3.
Petite parenthese.
Faut se mettre d'accord sur le sens du blob. Il a souvent l'air employé dans le sens BLOB ( type d'une colonne d'une base de données qui permet de stocker du binaire ). Du coup ça veut tout et rien dire puisqu'en informatique tout est en binaire.
Les firmwares sont donc bien des blobs. Par contre les fichiers binaires contenant des firmwares sont effectivement différents de fichiers binaires contenant des drivers qui seront executés par le processeur central de la machine.
[^] # Re: Une 4ème option ?
Posté par Yth (Mastodon) . Évalué à 4.
Tu n'as aucun contrôle sur le blob, mais tu peux l'utiliser.
Yth.
[^] # Re: Une 4ème option ?
Posté par herodiade . Évalué à 10.
- Il ne s'agit pas de code noyau ni même de code userland : ça tourne sur du matériel séparé (par ex. sur le proc de la carte réseau ou scsi).
- Pour la sécurité : le firmware tourne dans le matériel, la compromission possible de l'OS dépend seulement de ce qu'on accepte venant du matériel . Qu'il soit distribué avec l'OS ou pas ne change absolument rien. Et une même bombe logique pourrait être intégrée directement dans le design électronique du chipset (donc la question n'est même pas spécifique au monde du logiciel).
- OpenBSD a déjà choisi d'accepter les firmwares binaires dans base*.tgz (à condition qu'ils soient librement redistribuables)
- Tu mélange firmwares binaires (acceptés jusqu'à présent dans OpenBSD et Debian Sarge - et en fait, toutes les distros que je connaît) et drivers non libres (refusés par ces deux, et où OpenBSD se distingue par son militantisme sans concession).
- Ce que les devs. d'OpenBSD appellent « blob » ce sont des objets binaires chargés dans l'espace noyau par un pseudo driver minimaliste (un wrapper autour de l'objet binaire propriétaire). Rien à voir avec les firmwares.
- Le cas des chipsets wireless d'Intel est spécifique en ceci qu'ils ont d'abord fait des histoires au sujet de la redistribution de leur firmware (qu'ils n'autorisaient que sous condition) et ensuite par l'affaire du chipset 3945 (le driver Linux de ce chipset, écrit par Intel, est libre mais nécessite un daemon userland binaire proprio, cf. http://kerneltrap.org/node/6650 ).
[^] # Re: Une 4ème option ?
Posté par I P . Évalué à -2.
C'est sur qu'un module binaire éprouvé c'est *par nature* plus dangereux qu'un soft libre suid root.
Des fois on lit de ces choses...
[^] # Re: Une 4ème option ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 4.
[...]
un chip wifi atheros
Hélas, Le pilote Linux utilise un blob, il me semble.
Et le driver OpenBSD ne supporte pas le WPA... (et puis bon, OpenBSD...)
[^] # Re: Une 4ème option ?
Posté par Anonyme . Évalué à 1.
le pilote madwifi qui contient un blob, et le pilote ath-driver qui lui est sous GPL. Il ne supporte pas le WPA, je suppose qu'il s'inspire du pilote BSD (je n'ai pu vérifier cela, le site semble down).
Ensuite ce qui est proprio dans le pilote madwifi, c'est sa HAL. On peut la remplacer par un port de la HAL atheros réecrit par OpenBSD, je n'ai pas encore essayé cela, pour l'instant ath-driver passe sans pb sur mon reseau maison.
En fait j'ai bien cherché un portable avec un chip Ralink mais j'ai pas trouvé ^^
Sinon mon reseau est open, ca ne me dérange pas, par contre le QoS donne une priorité monstrueuse aux pcs de ma maison ^^
[^] # Re: Une 4ème option ?
Posté par mururoa69 . Évalué à 1.
C'est irresponsable.
Si quelque chose se fait à partir de ton reseau open du style hack ou spam tu en sera tenu responsable.
Open/closed ne se resume pas à je partage ou je me reserve toute la bande passante que j'ai payé.
[^] # Re: Une 4ème option ?
Posté par 태 (site web personnel) . Évalué à 1.
Ah, si bien sur, la différence, c'est 10 minutes.
[^] # Re: Une 4ème option ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[1]: http://linuxfr.org/2006/08/16/21198.html
[^] # Re: Une 4ème option ?
Posté par jjl (site web personnel) . Évalué à 4.
http://sid.rstack.org/blog/index.php/2006/08/24/112-savez-vo(...)
[^] # Question HS sur le wifi...
Posté par Mathias Bavay (site web personnel) . Évalué à 5.
Mais dans un cas tres simple, tel que le mien, que se passe-t-il: j'ai un portable acheté aux Etats Unis (je suis résident US, donc meme avec beaucoup de mauvaise fois, on ne peut pas me reprocher d'acheter mon materiel aux Etats Unis), avec une Mandriva installee dessus. Dans cette configuration, comment est ce que la carte "sait" qu'il faut appliquer les regulations US? Dans quelques semaines, je vais revenir en France pour des vacances... donc ma carte se retrouve a utiliser (potentiellement) des frequences interdites en France...
Si c'est le firmware qui s'occupe de gerer les regulations locales, il faudrait que Intel me donne un jeux de firmwares me permettant d'etre conforme quelque soit l'endroit ou je me trouve dans le monde... Si c'est le pilote (il me faut alors une option pour indiquer la zone geographique au pilote), alors ca ne sert a rien de faire tout un flan pour ces regulations, vu que le pilote est deja open source.
Et dans tous les cas, il faut que l'utilisateur daigne signaler au systeme ou il se trouve pour dire que le pilote satisfasse aux regulations locales (a moins de mettre un gps dans chaque carte et un clavier qui envoie des decharges electriques des que l'utilisateur cherche a faire une operation interdite)...
Si quelqu'un a des precisions sur comment ce genre de chose doit se passer dans la pratique...
Mathias
[^] # Re: Question HS sur le wifi...
Posté par Nicolas Schoonbroodt . Évalué à 5.
Donc je me lance dans une petite exploration. dmesg me dit qu'il me reconnait dans la zone "ZZM" (ou quelque chose comme ça)
grep ZZM /path/to/ipw2200.c , je récupère la ligne, petit saut là dedans.
Ok, ZZM, en commentaire "zone inconnue", je rajoute un p)eu de débug, et dans la ROM il est marqué "0" (enfin plein de 0) à la place d'un marqueur censé donner la zone. Du coup il retombe dans un mode sur, je supose en tout cas. C'est un mode qui avait moins de chanel que les autres. Le patch pour faire marcher ? Changer dans le driver GPL "ZZE" en "ZZM" et l'inverse au niveau des définis de fréquence. Moralité, le firmware ne sert pas à choisir les zone d'après la région. À quoi sert-il ? Mystère.
[^] # Re: Question HS sur le wifi...
Posté par ribwund . Évalué à 3.
En même temps la différence entre le firmware et le driver, c'est que en modifiant le driver tu peux emettre sur n'importe quel canal. Mais en modifiant le firmware tu pourrais possiblement emettre sur n'importe quelle fréquence (même en dehors des fréquences wifi), donc j'imagine que c'est ca qui embete le plus la FCC et compagnie.
[^] # Re: Question HS sur le wifi...
Posté par Nicolas Schoonbroodt . Évalué à 4.
Enfin je peux me tromper bien sur.
[^] # Re: Question HS sur le wifi...
Posté par BAud (site web personnel) . É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.
# mon humble avis
Posté par karmatronic . Évalué à 1.
c est le plus gros reproche fait á Debian ces dernieres annees que celui de ces incessants retards et si je comprends qu on retarde une sortie pour des raisons de sécurité ou de fiabilité,le "dogmatisme" est un mauvais motif,et qui discrédite linux en géneral.
bon je reste evidemment grand fan de debian,la meilleure distrib,et de loin :)
[^] # Re: mon humble avis
Posté par jerome Hentzen . Évalué à 3.
Trouvez le troll dans la phrase... non je ne vous aiderez pas !
[^] # Re: mon humble avis
Posté par Yth (Mastodon) . Évalué à 10.
Yth...
[^] # Re: mon humble avis
Posté par Sylvain Sauvage . Évalué à 8.
La réforme grammaticale en cours sur le ouèb semble plutôt être l'accord du verbe avec le complément plutôt (encore lui) qu'avec le sujet (« je ne vous aiderez pas »)...
# Juste histoire de ...
Posté par Pierre Habouzit . Évalué à 10.
L'annonce du DPL se moque complètement de ces propositions, et ne les évoque même pas. On les trouve ici:
http://lists.debian.org/debian-vote/2006/08/msg00032.html
http://lists.debian.org/debian-vote/2006/08/msg00215.html
http://lists.debian.org/debian-vote/2006/08/msg00185.html
Ce sont ces propositions qui vont déterminer quel sera le futur de Debian vis à vis des firmware, et pas le pseudo-poll proposé dans l'annonce.
Ce mail sur debian-devel-announce@l.d.o est une man½uvre populiste, qui reflète largement un état de conflit intense interne à Debian, et il serait maladroit de s'en féliciter. Sans parler du fait que n'importe quel développeur peut faire des annonces sur d-d-a et que ceci n'est pas nécessairement un statement du projet.
# Pondération
Posté par herodiade . Évalué à 10.
En fait le cas des firmwares est spécifique, pour au moins trois raisons :
1) Le cas des firmwares est spécifique. Il s'agit de code qui ne tournera pas sous l'OS (sous Linux), ni même sur le CPU principal, mais dans le matériel ; les problèmes habituels des drivers proprios : de sécurité (backdoors etc.), d'évolution de l'OS (freinée par les drivers propriétaires), de stabilité du système (fragilisée), de maintenabilité etc. ne se posent pas spécifiquement. Lorsque vous achetez (ou vendez) un ordinateur domestique, il contient généralement une foultitude de tels firwmares déjà intégrés dans le matériel. Tout le monde s'accommode de ça, faute de choix (achèteriez vous un PC sans son bios ?) ; mais de nos jours, pour économiser une peu de ROM, les fabriquants préfèrent de plus en plus fréquemment que les firmwares soient chargés dans le matériel à la volée par l'OS plutôt qu'intégrés d'emblée dans une puce.
Cette proposition ne se résume donc pas a un « nous voudrions faire admettre n'importe quel logiciel non libre dans main, celui-ci est un candidat parce qu'il est très utile ». Pour preuve, si l'acceptation des firmwares est proposée, ce n'est pas le cas pour les drivers non libres (nVidia, ATI, ...).
En somme, on pourrait comparer la problématique des firmwares à celle des images plutôt qu'à celle des logiciels : on (les distros Linux, le site gnu.org, Wikipédia ...) ne refuse pas d'intégrer une image sous prétexte qu'elle n'est pas fournie avec ses fichiers « sources » de développement (PSD Photoshop, XCD Gimp, photos initiales ...), ce qui importe c'est le droit de réutilisation et redistribution (et éventuellement modification).
2) En pratique, outre la question de l'utilisabilité d'un OS sans les firmwares adaptés au matériel, un autre problème se pose pour Debian : le fait d'enlever les firmwares binaires du kernel demande beaucoup de ressources et de temps, des compétences précieuses (devs. kernel) et c'est une opération a réitérer à chaque mise à jour. En bref, cette tache ralentie fortement le projet. Par exemple le choix du kernel d'Etch (2.6.17 ou 2.6.18) est fortement subordonné à cette question (pas le temps d'intégrer 2.6.18 s'il faut enlever les firmwares avant de le tester dans sid).
3) Le code source des firmwares en question serait probablement bien souvent inexploitable avec les outils (la toolchain) GNU car les microgiciels sont souvent développés avec des environnements de dev. propriétaires (donc quand bien même nous disposerions des sources, nous ne pourrions pas facilement construire les packages binaires à partir d'elles, c'est le fameux « ftbfs »).
La question fréquemment évoquée à ce sujet est celle de l'utilisabilité d'un OS qui ne peut pas s'installer sur son contrôleur SCSI (ou SATA, RAID ...), ou qui ne peut pas initialiser les cartes réseau, à une époque où les firmwares externes (chargés par l'OS) deviennent la nouvelle norme. Vous voyez, ce n'est pas la seule question à se poser.
[^] # Re: Pondération
Posté par BAud (site web personnel) . É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: Pondération
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
Et comment fais-tu pour installer un pilote réseau qui nécessite un firmware ? Doit-on rappeller en outre que, officiellement, Debian se défend de fournir un repository non-free et qu'il a même été question de le supprimer ?...
Faudra-t-il donc un CD non-free supplémentaire à chaque fois (oui, à chaque fois car comme il l'a bien fait remarqué, ce type de matériel devient peu à peu la norme, qu'on le veuille ou le déplore) et qui se chargera de le distribuer si Debian refuse de le faire ?
[^] # Re: Pondération
Posté par Pierre Habouzit . Évalué à 6.
FUD1: le maintien de non-free a été un plébiscite[1].
FUD2: debian ne se défend pas d'avoir une section non-free. non-free et contrib ne font pas partie du *projet* debian, mais existent bel et bien, et utilisent les mêmes outils pour les gérer (BTS, miroirs, autobuilders lorsque c'est relevant, releases, ...). Et ceci est fait pour des raisons évidentes: je ne vois pas comment Debian peut être "responsable" de ce qui est dans non-free sans avoir les moyens basiques pour y corriger les dits problèmes (à savoir les sources).
[1] : http://www.debian.org/vote/2004/vote_002
[^] # Re: Pondération
Posté par kraman . Évalué à 3.
hihi
c'est fait pour et par debian
c'est heberge par debian
c'est maintenu par debian
ce sont des developpeurs debian qui travaillent dessus
mais ca ne fait pas partie de debian.
J'adore, changez rien les mecs.
[^] # Re: Pondération
Posté par ragnar . Évalué à 5.
[^] # Re: Pondération
Posté par gpe . Évalué à 3.
[^] # Re: Pondération
Posté par ragnar . Évalué à 1.
[^] # Re: Pondération
Posté par Raphaël SurcouF (site web personnel) . Évalué à 0.
[^] # Re: Pondération
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 7.
c'est heberge par debian
c'est maintenu par debian
ce sont des developpeurs debian qui travaillent dessus
mais ca ne fait pas partie de debian.
L'ambiguité vient du fait que le nom Debian se rattache à deux choses :
1) La distribution Debian, à laquelle non-free et contrib n'appartiennent pas
2) L'organisation Debian, qui maintient (entre autre) non-free et contrib
Quand on dit que contrib et non-free n'appartiennent pas à Debian, on se réfère à la distribution. Effectivement, tu ne trouvera jamais des paquets de non-free ou contrib sur les iso téléchargeables.
Il n'y a aucune hypocrisie là-dedans.
Enfin, une dernière chose : serait-il possible que tu ne sois pas insultant dans tes commentaires ?
Je n'ai pas lu un seul de tes commentaires qui ne soit pas irrespecteux (qu'il y ait un rapport avec Debian ou non).
C'est lassant à force.
[^] # Re: Pondération
Posté par clearstream . Évalué à -2.
> Il n'y a aucune hypocrisie là-dedans.
Mon oeil.
Debian fait tout pour supporter non-libre, sauf que ce n'est pas dans les iso. La belle affaire. Durant l'installation on peut mettre du non-free ! Tout est indiqué, il n'y a rien à chercher. Et où sont les programmes non-free ? Sur le site de Debian. Où est le bugzilla associé ? Sur le site de Debian. Qui paye la bande passante ? Debian. Où est le système qui construit les paquets ? Toujours Debian.
Quand Fedora dit ne pas supporter le proprio, ben il le supporte pas. Les bug pour programmes proprios sont systématiquement fermés, il n'y a pas d'aide pour aller chercher les programmes proprios, Fedora n'héberge pas de proprio, etc...
J'oubliais ce détail, il n'y a pas de proprio sur les iso de Fedora.
Debian fait des contorsions pour se donner bonne conscience.
[^] # Re: Pondération
Posté par BAud (site web personnel) . É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: Pondération
Posté par clearstream . Évalué à 2.
C'est une excellente remarque. Les services Red Hat, et hébergés par Red Hat, ne sont pas libres.
La distribution et ce qui utilisent ses logiciels côté client (rhn, etc) sont libres.
Le reproche est tout à fait valable (du moins pour RHEL, car il n'y a pas de rhn, etc dans Fedora et toute l'infrastructure de Fedora (système de build, etc) est libre).
Mais il faut pondérer un peu. Ces logiciels proprios, sont comme les firmwares, ils ne tournent pas sur ton OS et mieux tu n'en as pas besoin pour utiliser ton OS et ta bécane ! C'est Red Hat qui en a besoin pour fournir un service que tu as acheté.
Notes comme rhn, etc ne posent aucun problème pour ceux qui veulent forker RHEL (centos, etc). RHEL reste fondamentalement libre. Les services vendu par Red Hat non.
D'ailleurs, on pourrait chipoter et dire que ces logiciels sont libres, mais que Red Hat ne les diffuse pas (c'est son droit, même si le logiciel est sous GPL).
En grattant bien chez Red Hat, tu dois pouvoir trouver du proprio (ou sous double licence) développé par Red Hat et diffuser par Red Hat. Je sais que ça existe, mais il faut bien chercher et je suis incapable de te les retrouver. Ca concerne principalement des petits produits très spécifiques pour l'embarqué.
S'il faut faire un reproche à Red Hat, ce n'est pas celui là. Red Hat (pour RHEL) supporte le proprio. Certes, Red Hat ne le diffuse pas, n'a pas de bugzilla pour les produits proprio, ne package pas de produit proprio, mais Red Hat bosse avec des boites proprio pour que RHEL soit adapté à des produits proprio. Par exemple pour avoir des benchmark qui arrachent sous Oracle ce qui aide à vendre du Oracle (et du RHEL).
Red Hat n'a pas de double discours consernant RHEL. D'ailleurs Red Hat a toujours des discours très honnètes.
Si tu fouilles Red Hat Magazine ( http://www.redhat.com/magazine/ ) tu trouveras un article en quatre parties sur les différences entre RHEL et Fedora. Pas uniquement technique, mais qui montre aussi la "colaboration" de Red Hat avec des boites proprios dans le cadre du projet RHEL (et uniquement celui ci, ça ne concerne pas Fedora).
Ce qui me gonfle particulièrement avec Debian, c'est que les discours (sa chartre) ne sont pas en accord avec la réalité.
> Cela ne remet pas en cause l'implication tant de Debian que de Red Hat pour le libre, hein.
Même si je n'apprécie pas certains aspects de Debian, je suis assez d'accord. Une chose est très claire, Debian ne nuit pas au libre, Debian aide le libre. Non-libre ne serait pas là ça ne profiterait pas à main. Les développeurs qui supportent du non-libre le feraient ailleurs.
[^] # Re: Pondération
Posté par ragnar . Évalué à 2.
Mais il faut pondérer un peu."
Non, il ne faut pas. Ou alors j'aimerais qu'on arrête de faire du FUD sur VA Software à cause de sourceforge. Tant qu'on arrêtera pas de cracher sur VA, je ne vois pas de raison de ne pas reprocher à Red Hat ses services basés sur des logiciels proprio.
[^] # Re: Pondération
Posté par clearstream . Évalué à 3.
> Non, il ne faut pas.
Au-lieu de pondérer, disons qu'il convient de bien en analyser les conséquences. C'est beaucoup moins grave que la propagation de skype par exemple.
> je ne vois pas de raison de ne pas reprocher à Red Hat ses services basés sur des logiciels proprio.
Notons qu'on ne sait pas si ce sont des logiciels proprios ! Mais je t'accord le raccourcis.
Plus haut j'ai dit :
- "Le reproche est tout à fait valable"
[^] # Re: Pondération
Posté par BAud (site web personnel) . É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.
[^] # Re: Pondération
Posté par clearstream . Évalué à 1.
Certe. Mais il y a quoi de propriétaire sur ta bécane ?
Fais un "rpm -q -i [paquet]".
Si j'ai dit une connerie, je t'applaudirai des deux si tu rétablis la vérité. Mais là je ne comprend pas où tu veux en venir.
T'es bien placer pour vérifier ce qu'il en est des licences côté client pour satellite server. Fais nous en profiter.
Je n'ai pas de satellite server.
> couplé à Oracle et ce n'est pas une licence libre que j'ai reçue pour le satellite
T'es sûr qu'Oracle est obligatoire ? Ce ne serait pas ton boss qui l'a imposé ?
> 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.
Je ne comprend pas bien.
Pour info (j'image que c'est inutile) :
https://hardware.redhat.com/
Pour bugzilla, c'est ici :
https://bugzilla.redhat.com/
Attention, il n'y a que les bugs saisis directement par l'utilisateur, pas via hot-line ou équivalent. Mais si tu insistes pour que ton bug soit public, je ne vois pas pourquoi il ne le fairait pas.
En général Red Hat est assez porté sur la confidencialité pour les clients payants. C'est comme ça depuis bien longtemps (depuis toujours ?).
Notes que parmis les boîtes qui font du support payant (plus que seulement fournir des mises à jours), presque tout le monde fait comme Red Hat. C'est "con", mais le client l'exige.
[^] # Re: Pondération
Posté par BAud (site web personnel) . Évalué à 2.
Sur une Red Hat censée être libre :
Red Hat Enterprise Linux ES release 4 (Nahant Update 3)
rpm -qa --queryformat="%{NAME} %{LICENSE}\n"|grep Copyright
redhat-logos Copyright � 1999-2004 Red Hat, Inc. All rights reserved.
L'image de Red Hat est non libre, mêm si ça ne sert à rien de rendre les paquets non libres, vu qu'il y a une trademark déjà dessus mais bon (les logos auraient pu avoir une licence libre, la trademark s'applique par ailleurs quand même, bref je vais pas chipoter).
Avec l'install' par défaut, c'est le seul paquet clairement estampillé non libre que j'ai vu, voici une petite liste des choses à vérifier (nom du paquet, licence) mais qui selon tes critères sont acceptables (et ne me dérangent pas trop trop non plus, n'étant pas intégriste jusqu'au-boutiste, hormis peut-être le terme "freeware").
rpm -qa --queryformat="%{NAME} %{LICENSE}\n"|grep -iE "Copyright|redistributable|freeware|boost|psf|various"
redhat-logos Copyright � 1999-2004 Red Hat, Inc. All rights reserved.
fonts-xorg-75dpi Redistributable
libselinux Public domain (uncopyrighted)
urw-fonts GPL, URW holds copyright
bitstream-vera-fonts Redistributable, with restrictions
netpbm freeware
vim-common freeware
fonts-xorg-100dpi Redistributable
fonts-xorg-base Redistributable
w3c-libwww W3C (see: http://www.w3.org/Consortium/Legal/copyright-software.html)p(...) PSF - see LICENSE
vim-minimal freeware
lha freeware
crypto-utils Various
vim-enhanced freeware
boost Boost Software License
gnuplot Redistributable, with restrictions
En revanche, sur le satellite server, la liste s'allonge concernant le non libre tout de même...
Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
rpm -qa --queryformat="%{NAME} %{LICENSE}\n"|grep -iE "Copyright|redistributable|freeware|boost|psf|various|(c) 200|subscription|binary|oracle"
rhns RHN Subscription License
rhn-satellite-config RHN Subscription License
rhn-satellite-admin RHN Subscription License
boost-devel Boost Software License
oracle-devel-jdbc Oracle license
rhn-oracle-jdbc-tomcat5 GPL
rhns-app RHN Subscription License
rhns-config-files RHN Subscription License
oracle-server-920 Oracle License
rhn-grail RHN Subscription License
oracle_perl (c)2004 Red Hat, Inc. All rights reserved.
vim-minimal freeware
lha freeware
netpbm freeware
fonts-xorg-base Redistributable
python-ldap PSF - see LICENSE
gnuplot Redistributable, with restrictions
java-1.4.2-ibm IBM Binary Code License
perl-DBD-Oracle distributable
xsdlib Sun Source/Binary Code License
rhns-config-files-common RHN Subscription License
rhns-config-files-tool RHN Subscription License
rhns-schema-tools RHN Subscription License
rhn-web-docs RHN Subscription License
rhn-cypress RHN Subscription License
rhn-i18n-release-notes RHN Subscription License
rhn-moon RHN Subscription License
rhn-dobby RHN Subscription License
rhn-swab RHN Subscription License
libselinux Public domain (uncopyrighted)
w3c-libwww W3C (see: http://www.w3.org/Consortium/Legal/copyright-software.html)
oracle-devel Oracle license
jta Sun Binary Code License
cx_Oracle BSD-style
perl-NOCpulse-OracleDB (c) 2000-2003 Red Hat, Inc. All rights reserved.
rhns-sql RHN Subscription License
rhns-server RHN Subscription License
rhns-xml-export-libs RHN Subscription License
rhns-applet RHN Subscription License
rhnpush RHN Subscription License
rhn-i18n-guides RHN Subscription License
rhn-pxt RHN Subscription License
rhn-sniglets RHN Subscription License
redhat-logos Copyright � 1999-2004 Red Hat, Inc. All rights reserved.
urw-fonts GPL, URW holds copyright
libselinux-devel Public domain (uncopyrighted)
boost Boost Software License
jaf Sun Binary Code License
rhn-oracle-jdbc GPL
python-gzipstream PSF
rhns-xmlrpc RHN Subscription License
rhns-package-push-server RHN Subscription License
oracle-server-scripts-920 Oracle License
rhn-java RHN Subscription License
rhn-base RHN Subscription License
taskomatic RHN Subscription License
python PSF - see LICENSE
python-devel PSF - see LICENSE
fonts-xorg-75dpi Redistributable
javamail Sun Binary Code License
jms Sun Binary Code License
java-1.4.2-ibm-devel IBM Binary Code License
rhn-html RHN Subscription License
osa-dispatcher RHN Subscription License
rhns-xp RHN Subscription License
oracle-server-admin Oracle License
rhns-satellite-tools RHN Subscription License
Pour ce qui est d'oracle, c'est imposé dans le produit (j'ai effectivement demandé si PostgreSQL n'aurait pas pu convenir, au moins 2 ou 3 fois, ...). Ne t'inquiète pas, je suis très au fait de notre référentiel... la fourniture de PostgreSQL aurait pu nous convenir s'il était packagé dans la solution (d'autant que s'il ne tenait pas les perfs, c'était l'occasion de contribuer à un projet libre de plus).
Pour la hardware list, visiblement tu n'as pas vu non plus complètement le process de certification des matériels constructeurs, effectivement tu tapes à côté vu que hardware.redhat.com et bugzilla.redhat.com sont ce qui est grand public, mais ce n'est pas trop grave de confondre, je n'avais pas forcément été très clair.
Après, je comprends cette notion de "confidentialité" qui peut rassurer certaines entreprises : dommage pour Red Hat de ne pas pousser tout de même une démarche du libre qui va à l'ouverture et à faire bénéficier les uns de l'expérience des autres (en caricaturant : comme si répondre incessamment aux mêmes problèmes déjà rencontrés avait une quelconque valeur ajoutée, tu me diras il faut bien justifier le contrat de maintenance... perso je préfère savoir que l'information est librement disponible, payer le contrat de maintenance et n'avoir à y faire appel qu'en cas de réel besoin ce qui est gagnant/gagnant AMHA mais peut réclamer un changement des mentalités, c'est comparable à metalink pour Oracle en fait... dommage).
[^] # Re: Pondération
Posté par clearstream . Évalué à 2.
Elle est libre. C'est le support qui ne l'est pas. Ca a été discuté sur fsf.org.
Si avec un CD de RHEL tu installes 2 bécanes (ou 15 000) alors que tu n'as souscrit que pour une bécane, tu en as parfaitement le droit. Si Red Hat l'apprend, Red Hat a parfaitement le droit d'arrêter de te donner du support (plus de rhn). Par contre Red Hat ne peut t'interdire d'utiliser ce que tu as déjà (c'est du libre).
Idem pour tout ce que tu récupères via rhn.
Tu peux me croire, ça a été discuté sur la mailing de fsf.org.
> vu qu'il y a une trademark déjà dessus
C'est le même problème avec Ubuntu, Mandriva, etc... Fedora a le même "truc".
Ca n'empêche pas Centos d'exister par exemple.
> rhns RHN Subscription License
J'abuse peut-être mais peux-tu donner le texte de cette licence (ou le mettre sur un site http) et regarder si tu as les sources des programmes sous license "RHN Subscription License".
Je n'ai trouvé que ça :
http://www.redhat.com/licenses/rhn.html
http://www.redhat.com/licenses/rhel_france.pdf?country=buyin(...)
Tout celà m'a l'air parfaitement libre (sauf le service).
[^] # Re: Pondération
Posté par clearstream . Évalué à 1.
Je trouve que Debian ergote beaucoup avec les firmwares. Si la carte a une ROM et que le firmware ne transite pas par Linux alors Debian est heureux alors que ça ne change RIEN de RIEN. Je préfère avoir le firmware dans Linux que de booter sous Windows pour charger le firmware puis faire un soft reset et passer sous Linux.
Ce qui serait cohérent si Debian n'aime pas les firmwares proprio, c'est que Debian vire tous les drivers pour cartes qui utilisent des firmwares non-libre (qu'il passe par Linux ou non). Là ça serait cohérent.
Tout ce que fait Debian, c'est pénaliser les gens qui ont acheter du hardware sans ROM (ce qui peut permettre de mettre un firmware libre si l'occasion se présente).
Autre chose, ces firmwares dans Linux sont sous GPL ! Certe, la GPL n'est pas totalement respectée (c'est un peu subjectif). Mais je préfère les voir sous GPL que sous je ne sais qu'elle licence proprio.
Le seul problème de ces firmwares est qu'ils ne sont pas "lisibles". Mais ils sont librement utilisables.
Puis pour le respect de la GPL, on peut déplacer les firmwares dans /lib/firmware. Je ne vois pas ce qui gagnera le libre mais on ne peut pas être contre.
[^] # Re: Pondération
Posté par BAud (site web personnel) . É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 clearstream . Évalué à 2.
C'est un poil plus compliqué. Lorsque tu as une image png, tu estimes qu'il faut les sources ? C'est pourtant bien du binaire et il faut un programme pour l'interpréter et le modifier. Donc ce n'est manifestement pas lisible.
Je sais que la GPL est néanmoins assez claire sur ce point.
Le problème du firmware, est qu'on ne sait pas ce que c'est ET on ne sait pas ce que ça fait ! On constate seulement que c'est necessaire pour que le périphérique fonctionne.
C'est peut-être des sources en klingon, c'est peut-être un mot de passe pour déverrouiller la carte, c'est peut-être une image, etc...
Quel est le rôle de Linux ? C'est un firmware qui s'installe sur des périphériques ? Non. C'est un OS qui utilise des périphériques qui ont une tâche bien précises. La fonction "firmware de périphérique" ne fait pas partie des fonctions de Linux. Tu ne peux pas dire : "je veux les sources de cette fonction, car cette fonction est prise en charge par Linux, et car Linux est GPL".
[^] # Re: Pondération
Posté par BAud (site web personnel) . É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.
[^] # Re: Pondération
Posté par ptitlouis . Évalué à 6.
Quand toi tu vois du proprio dans la section non-free, debian voit juste des problèmes au niveau des licences.
[^] # Re: Pondération
Posté par clearstream . Évalué à 2.
Un logiciel non-free diffusé par debian est forcément un logiciel non-free !
Un logiciel diffusé par Fedora (et d'autres) est forcément un logiciel libre !
> c'est à dire qui ne correspondent pas à 100% aux critères définit par Debian.
Donc pourquoi ces critères s'il est si facile de les contourner et au sein même de Debian ?
Quel est la crédibilité de ces critères ?
Pour moi pratiquement nulle.
Fedora (et d'autres) dit faire uniquement du libre et c'est crédible car Fedora ne fait que du libre.
Franchement la charte Debian me fait rigoler.
[^] # Re: Pondération
Posté par imalip . Évalué à 6.
C'est tres beau comme affirmation, mais tu pourrais nous filer un pointeur vers la definition de "logiciel libre" pour Fedora ? Je suis alle sur le site, j'ai pas trouve. Parce que quand on prend la definition de Debian (DFSG), la GFDL n'est pas libre, donc si Fedora distribue, par exemple, la documentation de Emacs, eh bien Fedora distribue du non-free.
Si le terme n'est pas defini, je ne vois pas comment on peut pretendre le respecter.
[^] # Re: Pondération
Posté par clearstream . Évalué à 1.
Et la GPL n'est pas libre car l'utilisateur ne peut pas la modifier. Ok, Ok, Ok....
Et qu'en pense la FSF ?
Et qu'en pense RMS ?
Ce n'est pas Debian qui défini ce qui est libre ou non.
> Si le terme n'est pas defini, je ne vois pas comment on peut pretendre le respecter.
Fais comme ça :
- Prend le logiciel le plus "non-libre" de Fedora, et à partir de ce point, c'est libre pour Fedora.
Trouves un programme non libre (au sens de la FSF) dans Fedora (Core et Extras).
Des programmes non libre dans Debian, ça se trouve facilement.
Pour info :
Les sources de FC5 :
http://fr2.rpmfind.net/linux/fedora/core/5/source/SRPMS/
Les sources des mises à jours :
http://fr2.rpmfind.net/linux/fedora/core/updates/5/SRPMS/
Les sources de Fedora Extras 5 :
http://fr2.rpmfind.net/linux/fedora/extras/5/SRPMS/
Tu peux aussi regarder les binaires, ça ne change rien. Tout paquet rpm installable (hors d'une arborescence de build) a un paquet src.rpm.
> Si le terme n'est pas defini
http://www.fsf.org/
[^] # Re: Pondération
Posté par ptitlouis . Évalué à 3.
[^] # Re: Pondération
Posté par imalip . Évalué à 3.
Debian dépend de la FSF ? Non.
RMS est un dev Debian ? Non.
Ce ne sont pas des personnes ou organisations exterieures a Debian qui décident de ce qui doit etre distribué dans main ou dans non-free.
Belle démonstration. Fedora ne contient que du libre, donc tout ce qui est dans Fedora est libre.
Tout ce qui est dans Fedora est libre, donc Fedora ne contient que du libre.
Et tu aurais un lien pour confirmer ca officiellement ? Parce que les seuls références a la FSF que j'ai trouvées sur fedora.redhat.com, c'est des "Upstream link" et le contenu de la GPL.
[^] # Re: Pondération
Posté par ptitlouis . Évalué à 6.
Dois-je en conclure que fedora distribue des logiciels non-free ? ou que les logiciels dans la section non-free de debian sont libres ?
[^] # Re: Pondération
Posté par clearstream . Évalué à 1.
Ce n'est pas Debian qui définit ce qui est libre ou non.
Si vraiment Debian était le chevalier blanc du logiciel libre, il n'y aurait pas de section "non-free" avec des choses sans codes sources, etc...
> latex2html est considéré comme non-free par Debian et est distribué dans fedora.
Voilà la licence :
http://www-texdev.ics.mq.edu.au/l2h/docs/manual/node5_ct.htm(...)
Je pense que c'est cette partie qui ne plait pas à Debian :C'est grave docteur ?
[^] # Re: Pondération
Posté par ptitlouis . Évalué à 2.
Si ce n'est pas Debian qui définit ce qui est libre ou non, alors qui le définit ? La FSF ?
> Si vraiment Debian était le chevalier blanc du logiciel libre, il n'y aurait pas de >section "non-free" avec des choses sans codes sources, etc...
Hormis les drivers nvidia et ati et le jdk de sun, qu'est-ce qui est sans code source ? Arrête d'envoyer des affirmations gratuites et donne nous des exemples concrets.
[^] # Re: Pondération
Posté par Didier Raboud (site web personnel) . Évalué à 2.
Peut-être pas. Mais Debian a défini ce qui, pour Debian, est considéré comme libre ou pas. Debian se donne un référentiel clair, précis et commun pour décider si, pour Debian, tel ou tel paquet est libre ou pas, et donc pour décider si le paquet en question peut faire partie ou non de la distribution Debian (dans main ou pas).
Ce référentiel est fait par et pour Debian, pas pour Fedora, RedHat ni la FSF. Selon ce référentiel, un paquet qui atterrit dans non-free n'est pas forcément non-libre (aux sens plus généraux du terme libre (selon la FSF, selon Fedora, ...) ), mais ne correspond simplement pas à la DFSG, pour Debian.
Il ne faut pas mélanger libre et dans main, de même que non-libre selon la FSF et dans non-free chez Debian. Ce n'est pas la même chose et n'a jamais été énoncé comme tel.
[^] # Re: Pondération
Posté par proum . Évalué à 6.
Ça signifie que tu ne peux pas vendre le logiciel, donc oui c'est grave. Et pas seulement du point de vue de Debian, mais aussi de celui de la FSF (puisque tu ne sembles pas faire confiance à Debian) :
http://www.gnu.org/philosophy/free-sw.html
http://www.gnu.org/philosophy/selling.html
Cela signifie donc que :
- Fedora inclus des logiciels non libres
- Il est interdit de vendre Fedora.
Il est parfois bon de regarder la poutre dans son ½il avant de voir la paille dans celui du voisin.
[^] # Re: Pondération
Posté par kraman . Évalué à -1.
oui oui, c'est ca, continue a parler.
C'est pratique les oeillieres quand meme, meme pas besoin de fermer les yeux, suffit juste de tourner un peu la tete et on voit plus rien.
Tu peux diviser debian en autant d'entite que tu veux avec toutes les pirouettes administratives que tu veux, toujours est il que l'equipe debian bosse sur non free, ya un budget qui lui est dedie etc.
Bref, dire que non free n'est pas dans debian, c'est au pire un mensonge au mieux de la grosse mauvaise foi.
Enfin, une dernière chose : serait-il possible que tu ne sois pas insultant dans tes commentaires ?
ben tant que je lit des enormites dans le style de celle que je viens de relever, non, c'est pas possible.
Ah ouais, tu savais que microsoft ne faisait que du libre?
Bon, windows et office, ca fait pas partie des suites logicielles de microsoft hein (microsoft au sens distribution, pas organisation). Mais le reste est libre, sisi.
[^] # Re: Pondération
Posté par BAud (site web personnel) . É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: Pondération
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Debian vient à peine d'avoir les honneurs d'un vrai support de la part d'un constructeur majeur comme HP et ce genre de décision va tout remettre en cause (à moins que le dit constructeur suive la même politique et évite les périphériques à firmware, on peut rêver).
Dès lors, il sera plus difficile de vendre (oui, vendre, parce qu'il y a des gens qui "vendent" Debian auprès de leurs collègues, supérieurs, clients, etc.) cette distribution à cause de ce manque de support matériel, là où d'autres distributions l'offrent sans compromis (et sans pour autant fournir des pilotes non libres avec les CD d'installation). Ce sera très difficile à expliquer et à convaincre...
Le Logiciel Libre c'est bien mais encore faut-il qu'une alternative existe... Jusqu'à présent, pendant l'intermède, on faisait avec le produit propriétaire en attendant un logiciel libre au moins aussi bien voire mieux, comme ce fut le cas avec Netscape Navigator, devenu Mozilla Firefox (bien que ce soit le même logiciel, à la base). Pas l'inverse.
L'inverse, c'est se couper de la base même des utilisateurs et sans utilisateurs, Debian risque de devenir une distribution d'élite...
[^] # Re: Pondération
Posté par BAud (site web personnel) . É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 Aldoo . Évalué à 3.
Le problème principal est que vu que c'est du logiciel, le firmware a une licence, et il faut donc vérifier qu'elle est compatible avec le mode de distribution.
Bon, maintenant revenons au bénéfice supposé de l'ouverture des firmwares : à savoir la possibilité de personnaliser et compiler ses propres versions. Si certains périphériques peuvent se reprogrammer ainsi (ça s'est vu, nombreux exemples : WRT54G, Archos, Freebox, etc. ), beaucoup tournent sur des processeurs super spécialisés avec des optimisations parallèles réglées au quart de millipoil, à tel point que je me demande s'ils sont vraiment "compilés" ou juste assemblés. Enfin, même compilés depuis un langage de haut niveau, celui-ci doit-être certainement très différent de ce dont on a l'habitude, et qui plus est spécifique à chaque architecture. Autant d'architectures à ajouter à la liste déjà longue qu'il faut supporter quand on maintient une distrib...
(même s'il ne s'agit pas de faire du support pour un nombre aussi conséquent de paquets, il faut tout de même maintenir la chaîne de compilation croisée).
Cela n'est pas impossible, mais je dirais que c'est un peu hors sujet pour le distributeur Linux, dont le rôle est de maintenir un OS basé sur Linux, tournant sur un processeur de PC. Les firmwares ne font pas partie de cet OS ! Par contre, le logiciel qui envoie le firmware, éventuellement oui.
Qu'on ne me parle pas des firmwares basés sur linux tournant sur les périphériques cités plus haut ! Il s'agit de projets séparés dédiés à maintenir un firmware uniquement, et non un OS pour PC. Maintenant, dans le cadre d'un tel projet (ou tout autre projet de firmware libre), si le mainteneur décide d'intégrer un morceau de code non libre, il y a effectivement de quoi faire la gueule, puisque le projet de firmware était là avant tout un projet d'OS embarqué libre, c'est à dire de faire tourner du code libre sur le processeur embarqué.
Pour résumer ma position : OS (de PC) et firmware sont deux mondes séparés et il n'y a pas de problème éthique à utiliser simultanément du libre d'un côté et du proprio de l'autre (même si c'est mieux d'avoir du libre partout ;-) ). Juste un problème de distribution éventuellement.
[^] # Re: Pondération
Posté par BAud (site web personnel) . É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 Aldoo . Évalué à 3.
Tout périphérique de communication dont le fonctionnement est obscur est une faille potentielle (à moins de ne lui envoyer que des flux cryptés, et encore ! En plus il faudrait que la norme de cryptage soit reprise à l'autre bout. Pas sûr que ça intéresse mon FAI !).
Par contre, que ma carte graphique ou mon ventilateur USB utilisent un firmware non libre, ça me dérange moins ! (alors oui, on pourrait imaginer la carte graphique envoyant des fréquences spéciales dans le tube cathodique afin d'envoyer des signals codés à la NSA... avouons que ce serait un peu capilotracté ! Quoique... j'avais vu un journal sur un émetteur TNT bricolé à partir d'une carte graphique... ).
[^] # Re: Pondération
Posté par herodiade . Évalué à 6.
1- Soit ils autorisent les fw librement distribuables une bonne fois pour toute (tout en réaffirmant qu'ils préféreraient avoir les sources)
2- Soit ils les autorisent provisoirement dans main pour Etch et juste après la release, ils travaillent à les déplacer dans non-free.
L'option « pas de fw du tout, même dans non-free » semble n'avoir pas beaucoup de supporters en fait.
Cela dit, je trouve à titre tout à fait personnel que la seconde option (révision après Etch) est un pinaillage très coûteux (voir hypocrite), qui, en pratique, n'améliore pas la « liberté » des fw et n'aide pas les LL (au contraire):
- Les déplacer dans non-free c'est encore les supporter un peu, au sens d'en faciliter l'utilisation. D'ailleurs, tourner sur les machines réelles (pécés i386, Apple ppc etc.) qui contiennent des « logiciels non libres » (fw, bioses) déjà intégrés au chipset c'est aussi supporter ces machines (et les logiciels qu'elles contiennent). Bref, une solution si coûteuse ne nous absoudrai pas pour autant ;)
- Personne ne propose la « libération » des fw. La solution 2 préconise seulement de « cachez ce fw que je ne saurai voir, mais cachez le à portée de main pour que je puisse quand même l'utiliser ».
- Les problèmes techniques sont intenses (si on met les fw sur un média séparé, cela suppose que la machine peut accéder au média - pas bon pour le netboot et pas bon s'il faut justement le fw pour accéder au média). Le travail des devs. kernels et des gens qui développent l'installeur serai alors lourdement bloqué pour régler ces questions (+ extraire les fw du kernel, corriger les bugs que ça amène, etc.) au lieu de s'occuper d'autres choses utiles.
- Rendre Linux plus difficile a installer et à utiliser n'aide pas les LL. Dans ce cas précis il est hautement improbable qu'un tel lobbying Debian parvienne à faire fléchir (libérer les sources) un seul vendor. D'une part parce qu'il existera des solutions « de secours », même bancales (fw dans non-free), d'autre part parce que toutes les autres distros et même le kernel vanilla/standard tolèrent la situation comme un pi allé, et enfin parce qu'on aura du mal à répondre a un vendor qui dirait « et bien pourquoi acceptez vous des bios et fw non libres dans le matériel ? ». Si encore cette stratégie permettait d'obtenir la libération des fw ... mais non, tout ce qu'elle va faire, c'est occuper des précieux et bénévoles devs. du libre à bidouiller des solutions mi figue mi raisin au lieu de coder du libre (et, je parie, un autre vote identique avant la release de Etch+1 pour constater qu'il faut de nouveau reporter).
- La position de Debian serait alors très difficile parce que l'upstream (le kernel Linux dans ce cas) a choisi de tolérer ces fw, et envoient bouler les devs Debian lorsqu'ils relancent ce sujet sur LKML. Il leur faudra donc maintenir un fork au fur et à mesure plus déviant de l'upstream, du kernel Vanilla.
- Et surtout, ce parti pris néglige un point important, à savoir que la grande majorité des gens vraiment concernés par cette décision, les devs. kernel de Debian, généralement bénévoles, n'ont pas envie de le faire. D'ailleurs ce débat arrive justement parce que le parti pris « tout les firmwares non libres hors de main », un des objectifs pour Etch, ne semble pas pouvoir être atteint dans les temps (c'est un euphémisme, en fait le plus gros du travail reste à faire), simplement parce que les « philosophes donneurs de leçons sur le libre » des ML Debian ne sont pas les mêmes que ceux qui font le gros du boulot sur le kernel (à de rares exceptions près).
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.
Ne pas confondre, le taf de Bergamini (et je crois aussi sur les modem eagle, à confirmer) n'est pas ce dont il est question : ils ont transformé des drivers non libres en "driver libre + fw/microcode non libre". Là dessus on est tous d'accord, rien ne change : pas de driver non libres.
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")
En fait j'ai été convaincu de la pertinence de cet argument par l'exposé de Theo de Raadt (leader d'OpenBSD), je ne connais la position de d'Itri que depuis récemment.
L'argument « on supporte les machines incluant un fw ou bios non libre, et on supporte et distribue les fw non libres via le dépôt non-free » (donc un changement minime sur le plan éthique, voir un peu hypocrite, mais très lourd et au mépris du coût en stabilité et temps de mise en oeuvre), est-il moins trollesque ?
Marco d'Itri est justement un des développeurs kernel de Debian les plus actifs, il est certainement bien au fait du coût d'une telle décision. Le fait qu'il tourne sur une autre CPU fait que ça n'affecte pas le fonctionnement de son Linux bien libre (de même qu'on accepte depuis toujours d'utiliser des bios non libres déjà inclus dans nos pécés, des firmwares non libres dans nos périphériques etc.). C'est donc une différence importante.
Et en aucun cas je crois qu'il ne dit : « on s'en fout libre ou pas ». J'ai plutôt compris ses quelques mails (peux verbeux) comme : « nous n'avons pas les moyens d'un voie alternative, et le problème est mineur ». Mais je suis convaincu qu'il préfère lui aussi les fw libres (tout comme les devs. du noyau Linux, qui ont pourtant toléré l'inclusion de certains de ces fw).
Cette question a trois faces distinctes, il est préférable de ne pas les mélanger et de les considérer toutes pour bien aborder le problème :
- technique (difficulté de séparer les fw, difficulté d'utiliser Debian avec des fw séparés, difficulté de maintenir ça ...)
- éthique (ça c'est le point sensible/émotionel des débats je crois, et pourtant, dans ce cas précis, je crois qu'il devrait passer après les deux autres)
- juridique (peu abordé ici, mais important : que faire si qqun demande les sources d'un fw non libre inclus dans le kernel, donc de facto soumis à la GPL + évidement le fait qu'il faut tout de même trier les fw qu'on a le droit de redistribuer ou pas - qu'ils soient libres ou pas).
Et ne pas oublier qu'on est tous d'accord sur ce point : « si c'est libre, c'est mieux » (ton commentaire semblait dire : ceux qui acceptent une telle concession sont indifférents au libre).
[^] # Re: Pondération
Posté par BAud (site web personnel) . É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 Raphaël SurcouF (site web personnel) . Évalué à 1.
La réponse est relativement simple: si Debian retire ces fameux firmwares de main, c'est bien simple, il ne sera pas possible de l'installer sur les machines récentes (et encore récentes, tout est relatif: mon portable professionnel doit avoir au moins deux ans). Autrement dit, elle sera cantonné, dans le meilleur des cas, à du matériel qui aura au moins deux ou trois ans.
Et qu'on ne vienne pas me parler de poser les firmwares dans un paquets non-free quelque part sur le net de façon plus ou moins officielle car allez télécharger le paquet avec votre carte réseau dont le module se nomme tg3 (ou tigon3 pour les intimes). Ce type de carte est de plus en plus fréquente et là, paf des firmwares... Donc, pas de réseau, pas de chocolat.
Personnellement, je préfère qu'ils laissent les firmwares tels quels dans main et si ils ont une alternative libre et seulement si, alors qu'ils les retirent. Ce n'est pas comme si on demandait d'avoir Skype ou Opera (mauvais exemples certes, puisque des alternatives libres existent)...
Sinon, j'ai bien peur que la distribution que j'avais au départ choisie juste pour les postes de travail n'étende son champ d'action.
[^] # Re: Pondération
Posté par Jar Jar Binks (site web personnel) . Évalué à 0.
# 1ere question
Posté par gpe . Évalué à 1.
[^] # Re: 1ere question
Posté par ptitlouis . Évalué à 1.
La premiere réponse propose de sortir etch à la date prévue en incluant les firmware dans main. La troisieme réponse propose d'inclure le support du chargement des firmware dans l'installateur ce qui implique un retardement de la sortie a cause du temps de développement et la migration de ces firmware dans non-free
[^] # Re: 1ere question
Posté par gpe . Évalué à -2.
Pourquoi 2 questions alors?!
# Je croyais ...
Posté par Colin Pitrat (site web personnel) . Évalué à 2.
Naïvement, je croyais que "on time" signifiait quand ce sera prêt pour Debian ...
# Debian, Vista, ma mère et le peuple : merde alors !
Posté par Olivier Prieur . Évalué à -1.
Je m'explique et c'est l'occasion ou jamais : cette question sur la possibilité ou non d'intégrer des firmware non libres dans la future Debian pose bien le fond du "probleme" !
Mes tentatives répétées et infructueuses de proposer et de faire adopter Linux aux miens restent en général sans lendemain :
"Linux, c'est trop dur, on comprend rien, j'arrive pas à configurer, etc."
Franchement j'en ai ma claque d'entrendre ça !
Et je vais vous répondre d'une autre manière notamment pour les deux premieres propositions :
* Sortir Etch comme prévu, avec des firmwares non-libres dans 'main' et possiblement gagner des milliers de personnes à Linux et donc au Libre ... mais bafouer quelque peu l'idéologie de Debian. La liberté et l'ouverture nécessite quelques fois des sacrifices ... à moins que le monde de Linux soit en fin de compte réservé à certains ... Ceux qui savent !
* Sortir Etch comme prévu, mais sans les firmwares non-libres dans 'main' et de fait respecter le philosophie de Debian MAIS cloisonner encore un peu plus l'univers merveilleux du libre et de Linux (Unix) au seul monde des super-geeks, des hackers, des passionnés célibataires et autres "mange-écran" en tout genre. Passer 7h à configurer un wifi sur mon portable à cause d'un firmware non libre, c'est dur et c'est fini pour moi !
QUE VEULENT LES "GENS" DU LIBRE ET DE LINUX EN GENERAL ? Miner le terrain afin d'etre sur de garder le savoir ou bien s'entre ouvrir au "reste du monde" ?
J'ai trop souvent l'impression que le libre est synonyme de "réservé" : un comble !
Donc ma réponse à tout ca se fera entendre sous la forme d'un cri : "OUI ! Intégrez les firmware non libres si cela peut permettre "d'améliorer" Linux en terme de performances et de simplicité !!!!!"
[^] # Re: Debian, Vista, ma mère et le peuple : merde alors !
Posté par lezardbreton . Évalué à 8.
Franchement, Debian n'est pas la seule distribution GNU/Linux et d'autres contiennent ces fameux firmwares, alors autant laisser Debian pure et vierge de toutes ces cochonneries.
Ca n'a rien à voir avec "faire gagner en popularité GNU/Linux" mais plutôt "faire gagner en popularité Debian", et est-ce que Debian dans le but de gagner en popularité a intérêt à renier son idéologie, ses racines, le ciment entre ses développeurs ?
Est-ce que gagner en popularité doit être un objectif de Debian ?
Pourquoi cherche-t-on absolument à niveler par le bas la liberté de nos distributions ?
[^] # Re: Debian, Vista, ma mère et le peuple : merde alors !
Posté par ragoutoutou . Évalué à 3.
Le vrai problème n'est pas idéologique mais signalétique: mettre des éléments non-libres dans un dépôt qui a pour vocation de ne contenir que du 100% libre est un transgression des règles d'organisation des dépôts, et est donc peu judicieux car une fois ces éléments non-libres dans le dépôt, celà risque d'être difficile de les retirer.
Il y a des dépôts pour les éléments non-libres, et ces dépôts doivent pouvoir être invoqués lorsque l'utilisation des éléments non-libres est incontournable.
Pour moi, il ne faut pas mélanger des éléments non-libres à main, mais en revanche, il faut assurer que le système soit en mesure de faire le minimum syndical lors de l'installation et de l'utilisation.
En aucun cas l'utilisation de firmwares non-libres n'altère tes libertés par rapport aux logiciels libres de la distribution, le tout est de pouvoir les garder séparés du reste de la distribution afin que ceux-ci ne compliquent l'exercice du droit à la redistribution des éléments libres.
[^] # Re: Debian, Vista, ma mère et le peuple : merde alors !
Posté par Jean-Philippe (site web personnel) . Évalué à 10.
[^] # Re: Debian, Vista, ma mère et le peuple : merde alors !
Posté par ragoutoutou . Évalué à -1.
[^] # Re: Debian, Vista, ma mère et le peuple : merde alors !
Posté par Mark Havel . Évalué à 2.
Je pense donc que Debian peut très bien décider de conserver sa liberté et sa philosophie et faire le nécessaire. Cela ne me parait pas dramatique si la prochaine version est retardée, tant que ça n'atteind pas les délais monstrueux de la dernière version.
[^] # Re: Debian, Vista, ma mère et le peuple : merde alors !
Posté par ciol . Évalué à 0.
ben si... Je suis débutant, utilisateur de base tout ce que tu veux mais j'ai choisi Debian parce qu'elle me semblait plus libre que les autres. Je la trouve assez facile à utiliser, mais c'est peut être aussi parce que j'ai de la chance (tout mon matériel supporté d'entrée). Après pour le vote, ça dépend :
* Sortir Etch comme prévu, avec des firmwares non-libres dans 'main'
> on peut toujours déplacer les firmwares de main après la sortie de Etch, c'est pas pressé non ?
* Sortir Etch comme prévu, mais sans les firmwares non-libres dans 'main'
> Tant que ça devient pas impossible à installer et qu'on explique les changements à faire, c'est cool.
* Retarder la sortie d'Etch jusqu'à ce que les modifications nécessaires aient été faites dans l'installateur.
> J'espère que ça ne retardera pas de 3 ans la sortie.
# ...
Posté par Anonyme . Évalué à -6.
Et aux résultats, on se rend compte qu'il y a de grandes chances que debian commencent à faire des compromis, et on sait où ça mène (je ne citerais aucun nom, pas envie qu'on me traite de trolleur).
Ce que je trouve remarquable, c'est que tout le monde tienne acquis que Linux doit être utilisé par tout le monde.
Oui, cent fois oui, je trouve Linux supérieur à Windows dans bien des points, mais je ne vois pas pourquoi tout le monde devrait l'utiliser.
Si c'est pour se taper des milliers de crétins au QI d'huitre sous nux, alors autant qu'ils restent sous Windows, au moins on aura la paix.
Tout le monde part du principe que c'est à l'OS de s'adapter aux utilisateurs, mais je ne suis pas d'accord.
Debian propose une distribution qui a ses avantages et ses inconvénients. Ceux à qui cela convient l'utilisent, les autres prennent une autre distribution. C'est ça, aussi, la liberté.
Personnellement, j'ai choisis Gentoo/Linux, parce que j'apprécie sa modularité, et je n'aimerais pas que la team Gentoo décide de réduire celle-ci parce que ça fait peur à certains indécis, ou parce que ça oblige a rallonger la release date.
De même, je suis persuadé que beaucoup de gens utilisent debian pour sa politique «tout est libre», et je pense qu'accepter d'intégrer des saloperies de blobs est franchement insultant (ça sonne un peu comme «Vous aimez debian parce que c'est libre, mais nous on veut séduire de nouveaux utilisateurs et sortir notre release à temps donc allez vous faire foutre»)
Enfin pour ce que j'en dis, tout ce qu'ils vont gagner c'est que ceux qui n'aiment pas les blobs vont se tailler sur une autre distrib, sachant que les neuneux resteront de toute manière sur ubuntu/mandriva/suse (et après, la team debian va venir pleurer que ouin, cpas juste, personne veut utiliser leur distrib
[^] # Re: ...
Posté par ciol . Évalué à 4.
Citation extraite du contrat social de Debian (paragraphe 4) :
Nos priorités sont nos utilisateurs et les logiciels libres.
http://www.debian.org/social_contract
[^] # Re: ...
Posté par Xavier Maillard . Évalué à 1.
Et ce n'est pas une fausse question. Si les utilisateurs souhaitent voir leurs firmwares (non libres) dans main, que devient ce paragraphe ?
Quand je pense au foin fait sur la GNU FDL (j'en suis toujours autant affecté), j'espère que les firmwares non libres vont dégager de main ou alors Debian perdra toute ma confiance mais surtout, toute crédibilité (encore une fois, rappelez-vous la guerre fratricide entre la FSF et Debian à ce sujet ainsi que les "arguments" avancés par Debian...)
[^] # Re: ...
Posté par Florent Bayle (site web personnel) . Évalué à 1.
Pourtant, j'ai trouvé les arguments de Debian parfaitement valides. Les DFSG, qui décident si une licence est libre ou non pour Debian comportent ce passage : The license must allow modifications and derived works. La GFDL autorisait des sections invariantes (des parties de texte que l'on ne peut pas changer), donc elle n'est pas considérée comme libre. Après, il y avait d'autres points, mais je te renvois vers la GR pour en savoir plus.
# Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Firmware et systèmes distribués
Posté par Zenitram (site web personnel) . Évalué à 3.
Bref, je ne comprend rien à ce que tu racontes, de ta differenciation entre premier et deuxieme processeur, car on parle ici du ou des processeurs sur lesquels tournent Linux, quelques soit le nombre, entre 1 et 1000000 de CPU, ca ne change pas le probleme.
On parle qu'il ne tourne pas en mode noyau si tu preferes, donc pas de crash de l'OS si le firmware crashe.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Firmware et systèmes distribués
Posté par BAud (site web personnel) . É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: Firmware et systèmes distribués
Posté par SF . Évalué à 2.
Je crains qu'actuellement ma distrib parfaitement dénuée de tout firmware binaire ne soit quand même en contact avec un grand nombre de logiciels closed-source à l'insu de mon plein grè...
BIOS ? Microcode du processeur central chargé par le bios ? Firmware de ma carte graphique (en ROM) ? Firmware de mon graveur de DVD ? Firmware de ma carte réseau ? Firmware de ma carte son (qui tout intégrée qu'elle soit en a peut-être un) ? Et j'en oublie surement beaucoup...
Bon la nouveauté c'est qu'il faut les redistribuer avec le CD mais ils ont toujours été là je pense. Bon évidemment ça pourrait être un moyen de faire bouger les choses mais j'ai plus peur qu'au vue des parts de marché de linux ça serve juste à s'isoler un peu plus.
# Le poids politique de Debian
Posté par _gryzor_ . Évalué à 5.
Aussi, Debian pourrait sans doute assumer un sous-projet de lobbying auprès des fabriquants. Si un fabriquant reçoit des dizaines d'emails par jour lui disant qu'on n'achetera pas ses produits, il va très rapidement se mettre à réfléchir.
Faire du libre, c'est - pour moi - aussi ça. En plus, cela peut contribuer à sensibiliser le public, par effet de bord. Et permettre à des non-développeurs de contribuer.
Si, au contraire, debian se plie au "c'est non libre, utilisons le quand même", c'est comme un gros feu vert aux fabriquants pour continuer à développer des firmwares propriétaires...
C'était mes 2 cents :)
[^] # Re: Le poids politique de Debian
Posté par tinodeleste . Évalué à -4.
[^] # Re: Le poids politique de Debian
Posté par clearstream . Évalué à 1.
Certe ça ne concerne que les serveurs. Mais maintenant dans ce domaine, si les constructeurs veulent être placé sur Linux, ils *doivent* fournir des drivers libres.
> ou j'aurai un driver libre qui marche raisonnablement pour une carte graphique raisonnablement "moderne" (moins de 3 ans disons).
http://intellinuxgraphics.org/
[^] # Re: Le poids politique de Debian
Posté par tinodeleste . Évalué à 1.
Dans le cas du graphisme au contraire, les drivers ont toujours été proprio, même à l'époque ou ATI et Nvidia avaient de la concurrence (stations irix...), et évoluent toujours vite, parce que vu leur complexité, la chasse au bug, même quand on a les specs, prend du temps. Les utilisateurs 'industriels' de ce type de matériel ont toujours utilisé du non libre, parce que ca marche mieux pour leurs applis que les drivers libres en terme de vitesse et de fonctionnalités. La liberté du chipset intégré intel est un pas en avant, mais vu le retard accusé au niveau performances pures de ces cartes là sur les deux principaux acteurs...
Enfin pour faire plaisir à Xavier, je veux bien forcer les industriels à libérer tout leurs pilotes quand je serai maître du monde, en attendant mes courriers sont restés sans retour...
[^] # Re: Le poids politique de Debian
Posté par Xavier Maillard . Évalué à 0.
C'est facile de se plaindre sans jamais rien proposer. Alors bouge-toi pour l'avoir ce support de la 3D.
/me énervé de toujours lire ce genre de truc.
[^] # Re: Le poids politique de Debian
Posté par ragoutoutou . Évalué à 10.
Les fabriquants de matos n'ont pas besoin de l'autoriastion de la communauté du libre pour continuer à faire des firmwares proprio. Ensuite, par leur nature véritablement liée au matos, ceux-ci n'interfèrent aucunement avec le logiciel libre.
Au lieu de perdre du temps à courrir derrière les firmwares, il serait bien plus intéressant de faire du lobbying pour obtenir les spécifications et/ou des pilotes libres pour les différents périphériques dont les seuls pilotes sont encore proprios.
Un firmware proprio n'empèche pas d'utiliser du matériel avec un noyau 100% libre, un firmware proprio n'empèche pas d'utiliser un périphérique sur une machine avec une autre architecture, un firmware proprio ne donne pas le pouvoir à un constructeur de stopper artificiellement la vie commerciale d'un produit.
Par contre, un pilote proprio teinte le noyau avec des éléments non contrôlables, un pilote proprio empèche de changer d'architecture si la nouvelle n'est pas supportée, un pilote proprio permet à un constructeur de décider qu'à partir de la version x du noyau, les gens n'ont qu'à acheter la nouvelle version du matos.
Faire du lobbying pour libérer les firmwares est une perte de temps.
Le plus important en ce qui concerne le matériel, c'est de libérer les pilotes.
Le plus important en ce qui concerne les firmwares, c'est d'avoir la permission de les redistribuer de manière illimitée lorsque ceux-ci sont indispensables pour pouvoir initialiser du matériel vital au bon fonctionnement de la machine.
En ce qui concerne les firmwares proprio dans debian, il est clair que leur place n'est pas dans main, il faut les mettre ailleurs.
[^] # Re: Le poids politique de Debian
Posté par Raphaël SurcouF (site web personnel) . Évalué à 0.
J'avoue ne pas comprendre le lien entre tout ce que tu as exposé et cette dernière affirmation. Si les questions relatives aux firmwares sont une perte de temps, pourquoi en faire perdre à Debian en prônant la solution conduisant à sortir les firmwares de main (chose qui n'est pas avare en temps et en heure puisque ça menace la sortie de la prochaine version d'au moins 6 mois et encore, ce n'est qu'une estimation...) ?
[^] # Re: Le poids politique de Debian
Posté par ragoutoutou . Évalué à 3.
La compartimentation des diférents dépôts est une méthode pour garder des logiciels groupés par license, mode de support, ... et main est un dépôt normalement réservé aux éléments de base 100% libres et supportés par les devs de debian.
Mettre du contenu qui n'est pas libre dans main, c'est mélanger des éléments qui n'ont ni la même méthode de gestion, ni la même méthode de support, ni les mêmes licenses.
Par contre, mettre les firmwares non-libres hors de main, mais permettre éventuellement que des éléments de main puissent dépendre de ces éléments non-libres serait peut-être une solution.
Ok, c'est un peu moins élégant qu'une belle structure en oignon des dépôts, mais je pense qu'avant tout, les firmwares non-libres sont une question organisationnelle, et qu'il faut une solution organisationnelle pour permettre aux utilisateurs de profiter au moins des fonctionnalités de base de leur hardware sans pour autant mélanger des éléments qu'il vaudrait sans doutes mieux garder séparés.
Le problème, c'est que vraissemblablement il y a urgence. Du coup, des deux côtés certains prônent le bâclage: certains préfèrent qu'on sacrifie la structure et qu'on mélange les torchons et les serviettes, et d'autres préfèrent tout virer sous couvert de pureté philosophique pour ne pas avoir à se poser de questions... la bonne solution se trouve sans doutes dans un petit report et une approche à tête reposée du problème.
[^] # Re: Le poids politique de Debian
Posté par François B. . Évalué à 2.
On peut lire dans la Charte, pour main : Et pour contrib :
La partie concernée de la Charte est disponible par là http://www.fr.debian.org/doc/debian-policy/ch-archive.html#s(...) (en anglais)
[^] # Re: Le poids politique de Debian
Posté par ragoutoutou . Évalué à 3.
Certainement, le tout est d'avoir un système d'installation permettant d'exploiter correctement cette réalité... c'est pour celà qu'il vaut mieux attendre que le système d'installation soit adapté plutôt que d'essayer de "trancher" et de ne pas faire les choses dans les règles de l'art.
[^] # Re: Le poids politique de Debian
Posté par François B. . Évalué à 3.
Sinon, je suis parfaitement d'accord avec toi, la décision a un fort impact sur les développements nécessaires. Mais comme j'ai dit un peu plus haut, quelqu'un aurait prévenu l'équipe de d-i peu de temps après la sortie de sarge, mais cela aurait été sans effet. Maintenant, au vu de la manière dont cette personne s'est plainte sur debian-devel@l.d.o, j'ai peur que les dev de d-i aient mal pris son message...
Avant de régler les problèmes de conformance aux DFSG, certains devraient se remettre en question afin de limiter les discussions stériles sur les listes et se mettre réellement à construire le système ! Auparavant, avant de connaître le libre, je connaissais les "yakas" dans le milieu associatif, maintenant je vois exactement la même chose sur les listes :-(
[^] # Re: Le poids politique de Debian
Posté par ragoutoutou . Évalué à 3.
Bien entendu... maintenant, on pourrait débattre aussi sur le fait que les firmwares appartiennent à non-free ou si une classification alternative serait nécessaire (par exemple, faire une distinction entre applications/librairies non-libres et ressources non-libres, définir si les firmwares sont ou ne sont pas des ressources plutôt que des applications, si le fait de dépendre d'une ressource non-libre est un motif suffisant pour aller dans contrib, ...) mais bon, débattre de celà ici aurait peu de sens, mais clairement, il y a matière à débat et à amélioration puisqu'il y a problème, et ce n'est pas en faisant des hacks grossiers qui ne respectent pas le modèle actuel qu'on arrangera les choses.
<mode_yaka>Ce qu'il faudrait peut-être, c'est un projet ayant pour objectif d'évaluer s'il y a besoin d'une réforme du modèle, pour ensuite si nécessaire, faire une véritable analyse pour trouver un nouveau modèle répondant aux attentes, au cas où on se heurterait effectivement à une limite du modèle. </mode_yaka>
# Interrogations ???
Posté par kolter (site web personnel, Mastodon) . Évalué à 5.
Il faudrait être idiot pour ne pas voir que ce sondage est une parodie de sondage et que la réponse à la question posée est connue d'avance.
Alors pourquoi cette annonce ? pour sortir Etch à temps ? Pourquoi vouloir sortir Etch à temps alors que la politique de Debian à toujours été de sortir la version stable quand "tout est prêt".
Pourquoi le leader du projet Debian ne tiens pas compte des propositions de certains développeurs et qu'une GR est en cours sur le sujet et qu'il s'en fou royalement ?
C'est un peu comme si l'assemblée nationnale prenait une décision sur un sujet sans tenir compte des parties concernées (DADVSI?!?).
To Be Continued ....
M.
[^] # Re: Interrogations ???
Posté par Sylvain Sauvage . Évalué à 3.
[^] # Re: Interrogations ???
Posté par herodiade . Évalué à 1.
Mais c'était trop dur, long, peut intéressant pour ceux qui savent le faire, ... bref, ce n'était pas pret à temps pour Sarge. Un GR a été voté : on fera ça après Sage ».
Puis Etch arrive, on s'apperçois de nouveau que ce même truc n'est pas fait.
On repropose des GR, et je met ma main à couper qu'on va voter « on fera ça après Etch ».
Ça fait beaucoup de temps perdu à essayer de faire ça, à troller, pour finalement reporter à chaque fois.
Et surtout, si la décision était de repousser la release à cause de ça ... aujourd'hui ce serait encore *Sarge* qu'on devrait reporter !
[^] # Re: Interrogations ???
Posté par THR4K . Évalué à 3.
Je ne reviendrais pas sur tout ce qui a été déjà dit concernant les différentes façons de considérer la nature d'un firmware, la nécessité ou non pour Debian de s'occuper des firmwares qui usuellement ne sont pas fournis avec la distribution/l'OS mais avec le matériel contenant lesdits firmwares, la question de l'utilisateur et de l'usabilité d'un OS sur du matériel requierant des firmwares non fournis, le fait que cela puisse être un problème amont (au niveau de la communauté plus largement) et donc que cela sorte du simple cadre de Debian et des DFSG, les contraintes purement techniques que cela implique,etc.
Pour se faire une petite idée du travail qui serait nécessaire :
---> http://lists.debian.org/debian-vote/2006/08/msg00122.html
Autre lien intéressant, un inventaire des firmwares concernant le noyau prévu pour Etch et les possibles problèmes de licence qu'ils posent :
---> http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html
Avant de tirer des conclusions hâtives donc, il est utile de se renseigner un peu quite à consulter les ML Debian relatives à ce GR. Même si certains posts sont trollogènes (comme partout), un bon nombre d'arguments sont pertinents et montre combien Debian reste soucieuse de ses utilisateurs en quête de liberté alors que d'autres projets de distribution "libre" ne se sentent visiblement guère concernés.
THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.
[^] # Re: Interrogations ???
Posté par herodiade . Évalué à 4.
Plaît-il ?
Avant de donner des leçons de morales, faudrait peut-être voir à ne pas prendre tes interlocteurs pour des sous informés débiles. Merci.
D'une part j'ai bien entendu lu les threads sur les mailings-lists à ce sujet, dont les deux liens que tu cite, d'autre part j'ai aussi lu (et ça tu ne les cites pas dans ta selection de messages) des messages expliquant que l'absence de sources pour ces fichiers ne poserait pas de vrais problèmes légaux:
1) parce qu'on peut éventuellement filer des sources assembleur si qqun insiste à coup de procès (en décompilant le fw binaire)
2) parce que toutes les distros qui ont des juristes pour étudier ces questions ont jugé que ce ça ne pose pas de gros problème
3) parce que si on va par là, il y a un paquet d'autres fichiers, inclus dans des softs libres, dont debian ne peut pas filer les sources : scripts './configure' dont le config.in est perdu, images diverses, certaines fonts, ... . Tant qu'à enculer les mouches au lieu de se battre aux cotés de ceux qui écrirvent les drivers pour régler les vrais problèmes de liberté (obtenir les specs du matos sans NDA, par ex.), allez-y jusqu'au bout.
Quoiqu'il en soit, mon commentaire ne visait pas à critiquer le fait que Debian ne soit pas parvenu à retirer ces fw jusqu'à présent, au contraire (car oui, je sait que c'est dur, long, etc. et je l'ai dit plus haut), mais à critiquer ceux qui jettent des GR inaplicables (parce que justement, c'est dur) sur ce sujet, et qui ne font pas (ou ne peuvent pas finir) le boulot de toutes façons (parce que oui, c'est dur).
C'est très bien de faire la morale et de lancer les GR, maintenant, si ceux qui savent si bien monter sur leurs grands cheveaux quant à la question de la liberté des fw s'étaient sortis les doigts du cul pour virer ces fw, adapter l'installeur, etc. ils n'en seraient peut-être pas là. En l'occurence, ça ressemble fort à un : « nous on aime seulement donner des leçons et troller sur les ML, alors on va vous forcer, vous les developpeurs kernels, à faire le boulot que vous ne jugez pas prioritaire/utile ou que vous n'avez pas envi de faire ».
# Du non-libre est nécessaire à terme
Posté par charlieecho . Évalué à -4.
Posons la (fameuse) question des DRM...
Il est clair que tout système de DRM open-source présente un risque critique d'être contourné : si les sources sont disponibles pour lire un flux crypté, alors on peut "extraire" la clé lors d'un décryptage légal, et décrypter le fichier à tout moment (c'est ce que fais, je suppose, le fameux logiciel qui contourne la protection de Windows Media)
Donc, à mon avis, pour l'histoire des DRM, c'est clair, il faut un bout de soft propriétaire : le codec, le module de décryptage, ou autre.
(il existe des éléments "hard" pour décrypter ; ça peut être la solution, certes, mais le temps que ce soit en place, l'Industrie aura totalement adopté le format WIndows).
C'est bien beau de dire "les DRM c'est pas bien". Moi non plus, j'aime pas ça. Mais c'est pas moi qui décide, c'est l'industrie cinématographique...
Alors de deux choses l'une : soit Linux intègre rapidement des solutions propriétaires pour lire des fichiers DRMisés, soit la route du multimédia continuera sans nous...
J'espère me tromper...
[^] # Re: Du non-libre est nécessaire à terme
Posté par Anonyme . Évalué à 6.
[^] # Re: Du non-libre est nécessaire à terme
Posté par Didier Raboud (site web personnel) . Évalué à 5.
Ce n'est absolument pas propre à un système DRM open-source. Les DRM sont inefficaces par conception, parce qu'ils ne vont pas dans l'intérêt de l'utilisateur (contraîrement à ssh, à GnuPG, à SSL, ...). Dès que le contenu original est rendu humainement consultable (la musique est écoutable, le film visionnable, le PDF imprimable, ...), il est copiable, il suffit d'une et une seule clé pour que le contenu original soit copiable dans sa qualité de diffusion (ou presque), mais sans DRM.
À partir du moment où je me suis acquitté de mon droit à l'écoute de ma musique sous DRM (avec ou sans système open-source), j'aurais toujours un moyen de la copier sans DRM (prise Line-out vers un Line-in d'un autre ordi par exemple). Et c'est valable pour tout (scanner un PDF-DRM, PrintScreen de l'écran 24 fois par seconde, ...).
N.B. C'est plus simple avec une implémentation libre, évidemment, mais là n'est pas la question.
Les DRM, c'est juste un moyen désespéré de ceux qui font de l'argent en vendant du contenu multimédia pour ne pas perdre de marché et surtout, continuer à faire de l'argent.
Sous GPL ? Laisse-moi doucement sourire...
Je n'ai pas besoin des DRM pour continuer à écouter de la musique: la route du multimédia surprotégé continuera sans moi...
[^] # Re: Du non-libre est nécessaire à terme
Posté par benoar . Évalué à 5.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.