C'est maintenant chose faite. NB: c'est un premier jet.
Guidelines for Free System Distributions :
http://www.gnu.org/philosophy/free-system-distribution-guide(...)
C'est une excellente chose que d'avoir ce document. La FSF est (au moins pour moi) une référence.
Pour les réflexions "fumeuses" sur le bien et le mal, l'éthique selon saint fanatique RMS ou sa philosophie, etc, voir ici :
http://linuxfr.org/~sokol/26643.html
À mon goût, c'est encore incomplet. Ce qui peut être vu comme normal puisque c'est une première version.
La FSF est une référence dans le libre. Pas un référence du paysage du logiciel, mais du libre. Tout jugement sans recul doit être évité. C'est l'avis de la FSF. La FSF ne dit pas ce qu'il faut faire pour gagner des parts de marché chez la ménagère de moins de 50 ans, ni ne s'occupe du bug n°1 d'Ubuntu, etc.
Hors ceux qui ont lu mon autobiographie (en vente à seulement 30 € dans les gares), beaucoup ne savent pas que je suis pro-Fedora.
We would like to thank the Fedora Project for their help in focusing these policies, and allowing us to use their own distribution license guidelines as a basis for this document.
Fedora a beaucoup bossé sur cette question (notamment pour F7) et ça fait plaisir de voir que cet effort a des échos.
Es-ce que Fedora est libre (selon la FSF) ?
Roulement de tambours, j'ouvers l'enveloppe, roulement de tambours :
Non.
Pour la FSF, Fedora n'est pas une distribution libre.
Voir ce blog (et ses commentaires) :
http://rahulsundaram.livejournal.com/19456.html
Les règles Fedora :
http://fedoraproject.org/wiki/Packaging/Guidelines
http://fedoraproject.org/wiki/SIGs/FirmWare
Es-ce que Fedora fera le dernier pas pour être libre (selon la FSF).
Je ne suis pas contre, voire favorable, même si à mon avis c'est d'un intérêt limité pour le libre.
Mais méditons ceci du blog de Rahul Sundaram donné plus haut :
What was most striking in these discussions was that FSF and RMS in particular who was well known in the community for having such adamant and extreme focus on the Free software philosophy turned out to have other not so well known traits too. They were all that and more such as RMS insistence on using just the right words but I also found something quite unexpected hidden beneath the ideology: Pragmatism. If you notice carefully, it is reflected everywhere in their actions as Alan Cox eloquently [ http://www.redhat.com/archives/fedora-devel-list/2008-March/(...) ] observed.
# toujours cette maladie...
Posté par ragoutoutou . Évalué à 5.
les questions à se poser tout de même par rapport aux blobs fournis dans le kernel, avant de les virer maladivement sont:
- est-ce qu'il existe réellement un code source qu'on aurait pu obtenir, ou est-ce du binaire parceque ça a été codé directement en binaire (fréquent pour certains microcontrolleurs)
- dans le cas où un code source existerait, est-il possible de mettre en œuvre une chaine de compilation pour ces éléments sans faire exploser la complexité de la compilation du noyau?
Enfin bon...
[^] # Re: toujours cette maladie...
Posté par IsNotGood . Évalué à 4.
Tu parles de blobs. Mais il y a deux types de blob. Ceux exécutés par le noyau (ou l'OS de façon plus large) et les blob qui sont chargés sur un périphérique et exécuté par le périphérique. Pour ce dernier cas, c'est un firmware.
Même en tant que "libriste", j'ai très peu de problème avec les blob-firmware. Pour moi l'OS est libre (tout proprio que soit le hardware et les périphériques qui utilisent des firmwares chargés par le noyau). Mais la distribution ?
Il y a problème pour la distribution. Le problème se pose lorsque, par exemple, tu conseilles une distribution et dis qu'elle est libre (ce qui veut dire que TOUS les sources (y compris les firmwares) sont disponibles). Ben s'il y a un blob-firmware, elle n'est pas libre. Donc il y a tromperie sur la marchandise. C'est emmerdant car c'est moche d'utilise le mot "libre" pour manifestement quelque chose qui ne l'est pas (je n'évalue pas le problème, je dis seulement qu'il y a problème).
> - est-ce qu'il existe réellement un code source...
Si le firmware n'est pas vraiment un blob (par exemple le développeur utilise un éditeur hexa (ça arrive) et il y a la doc), il n'y a pas de problème.
Mais il y a des vrais blog-firmware (qui sont aussi dans Linux vanilla). C'est ici que le problème ce pose (où commence).
Il y a ici un long thread sur ce problème :
http://www.redhat.com/archives/fedora-devel-list/2008-March/(...)
La tendance globale (mais non ferme) que je perçois est qu'il faut que ce problème soit pris en compte en upstream. Attention, je ne dis pas que l'upstream va virer les blobs. Mais l'upstream doit faire le nécessaire pour permettre de facilement faire des versions de Linux sans blob. Ceci étant maintenu par l'upstream. Après c'est aux distributions de décider si elles veulent ou non intégrer les blob-firmware.
> - dans le cas où un code source existerait, est-il possible de mettre en œuvre une chaine de compilation pour ces éléments sans faire exploser la complexité de la compilation du noyau?
Je ne vois pas où tu veux en venir. On ne va pas demander au noyau de compiler le firmware. On veut qu'il y ait les sources. On n'interdit pas l'existance du blob (qui peut-être compilé ailleurs).
[^] # Re: toujours cette maladie...
Posté par ragoutoutou . Évalué à 3.
Si ce blob est distribué distribué sous gplv2, je ne vois pas en quoi on peut prétendre qu'il n'est pas libre. Certes on a pas les sources (mais dans certains cas il n'y en a pas), mais les conditions de modification, de redistribution, ... sont d'application. C'est moins lisible, mais y a t'il moyen de le rendre plus lisible?
doit faire le nécessaire pour permettre de facilement faire des versions de Linux sans blob
Je pense que c'est surtout ceux en quête de pureté à venir participer au projet upstream plutôt que de poser des exigeances. chacun son projet.
On veut qu'il y ait les sources
Encore une fois, il y en a où il n'y a pas de source parceque ça a été développé directement en binaire. Libre à qui veut de faire de l'ingénierie inverse sur ces petits éléments et de faire une documentation. Ce sera toujours plus productif que de chercher à les virer sans pallier au manque engendré.
[^] # Re: toujours cette maladie...
Posté par IsNotGood . Évalué à 2.
Je n'ai jamais dit que tous posaient problème.
Ce n'est pas car certains ne pose pas problème, qu'il faut ignorer ceux qui posent problème.
Tu parles d'autre chose.
Je n'ai pas envi d'entrer dans ces histoires ou on coupe les cheveux en quatre.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: toujours cette maladie...
Posté par IsNotGood . Évalué à 2.
Je ne doute pas de la sincérité de ton propos. D'ailleurs je pensais la même chose.
Mais il me semble avoir vu Alan Cox dire que certains blobs sont développés avec un éditeur hex (ou un truc style "{ 0x01, 0xF7, ...}").
Le problème par rapport à l'esprit de la GPL n'est alors pas l'absence le source (plus présicément la forme utilisé pour le développement), mais la doc. Par que pour ce type de blob, mais si tu as le source, c'est quasi impossible à modifier (et que ça marche).
> Tous les blobs que j'ai déjà vu sont beaucoup trop gros pour avoir été fait à la main...
Pour ceux dans /lib/firmware probablement. Mais les sources de Linux ont aussi des blogs qui sont très petits.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: toujours cette maladie...
Posté par IsNotGood . Évalué à 2.
blob = Binary blob
http://en.wikipedia.org/wiki/Binary_blob
This article is about drivers.
> Les petits bouts de binaire dont tu parles sont généralement des référencements aux registres, à la mémoire, etc. du hardware.
Non, il y a des petit blob. Je ne vois pas pourquoi il n'y aurait que des gros blob.
> Les petits bouts de binaire dont tu parles sont généralement des référencements aux registres, à la mémoire, etc. du hardware.
Tu parles peut-être d'autres choses. On peut souvent depuis Linux écrite dans des registres d'un périphérique. souvent ceci ne demande pas de blob (de binaire téléchargé sur le périphérique) mais seulement la doc du périphérique.
Notons bien que Linux n'a pas besoin de télécharcher un blob dans le périphérique pour écrire le blob dans le périphérique :-)
Ça serait impossible.
[^] # Re: toujours cette maladie...
Posté par IsNotGood . Évalué à 2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: toujours cette maladie...
Posté par IsNotGood . Évalué à 0.
Dire que la FSF dit des conneries.
Que le fait que Gnewsens et d'autres qui virent les blobs dans les sources du kernel vanilla font du vent.
Etc.
[^] # Re: toujours cette maladie...
Posté par regdub . Évalué à 2.
D'après le lien que tu as donné :
Blobs were originally just amorphous chunks of data invented by Jim Starkey at DEC [...] Then Informix invented an alternative backronym, Binary Large Object[citation needed].
En plus ça ne veut pas dire grand chose : plus de 4-5 octets, je trouve que c'est déjà grand s'il faut le mémoriser.
[^] # Re: toujours cette maladie...
Posté par ragoutoutou . Évalué à 1.
Celui qui veut étudier le fonctionnement de ces blobs peut toujours faire de l'ingénierie inverse et nous faire une belle doc sur le sujet... l'étude n'est pas entravée, c'est juste que l'info ne tombe pas toute cuite dans la bouche de la personne qui lit le code binaire...
Pour pouvoir étudier et comprendre le fonctionnement des applications, il faut maîtriser le langage dans lequel elles sont écrites, sinon, on pourrait voir des hordes de personnes ne connaissant pas le C dire que emacs c'est pas libre parcequ'ils ne comprennent pas le code source.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: toujours cette maladie...
Posté par ragoutoutou . Évalué à 3.
Pourquoi on met pas la doc de C/C++ dans le kernel?
Ici, personne, ne peut comprendre, ni étudier le fonctionnement car il manque quelque chose d'énorme !
Ben c'est là dessus qu'il faudrait bosser, pour les microcontrôleurs dont la doc n'est pas disponible... (parce qu'il y en à où un coup de google devrait suffir)
Ce qui serait intéressant, c'est au lieu d'appliquer une pensée binaire concernant ces "bobs" et de vouloir dicter leur suppression bête et méchante, faire un inventaire, établir un score par "bob", sur sa criticité par rapport au bon fonctionnement du matériel selon le type de public (mobile/serveur/desktop), sur les possibilités de faire l'ingénierie inverse, sur les possibilités de créer une chaîne de compilation, et ensuite d'adresser ces "bobs" au cas par cas: on jette, on démarre un projet de substitution, on documente, on garde tel quel, ...
[^] # Re: toujours cette maladie...
Posté par IsNotGood . Évalué à 2.
Même pas besoin de faire Linux.
Formidable.
[^] # Re: toujours cette maladie...
Posté par ragoutoutou . Évalué à 2.
"et si on suis ton raisonnement, il faudrait attendre que le bios des cartes mères soit libre avant de pouvoir lancer emacs."
[^] # Re: toujours cette maladie...
Posté par IsNotGood . Évalué à 1.
C'est la FSF qui est le mieux placé pour le faire.
Mais peut-être que tu te crois plus balaise que la FSF dans ce domaine.
[^] # Re: toujours cette maladie...
Posté par ragoutoutou . Évalué à 4.
La liberté n'a pas été inventée par la FSF, je ne vois pas en quoi ce concept précis leur appartiendrait plus à eux qu'à n'importe quel bipède doué de deux neurones. Certes, la FSF formalise le concept de libertés au sein du monde logiciel, mais elle ne doit pas avoir le monopole de la réflexion. La FSF, si elle est admirable pour de nombreuses réalisations, ne doit pas rester non critiquée, car elle n'est pas à l'abri de dérives.
Donner le monopole de ses libertés à une seule entité, est-ce rester libre?
[^] # Re: toujours cette maladie...
Posté par IsNotGood . Évalué à 3.
Remettre en cause la FSF ?
Rappeler qu'on n'a le droit de na pas être d'accord avec la FSF ?
Diaboliser la FSF ?
Enfoncer des portes ouvertes ?
Contester l'"autorité" de la FSF dans le domaine du logiciel libre ?
Où discuter de ce que vient de faire la FSF et ses crititères pour être une distribution libre ?
Tu peux ne pas être d'accord avec la FSF qui ne veut pas de blob.
Mais les trucs fumeux type :
- "Ce qui serait intéressant, c'est au lieu d'appliquer une pensée binaire concernant ces "bobs" et de vouloir dicter leur suppression bête et méchante[*], faire un inventaire, établir un score par "bob", sur sa criticité par rapport au bon fonctionnement du matériel selon le type de public (mobile/serveur/desktop), sur les possibilités de faire l'ingénierie inverse, sur les possibilités de créer une chaîne de compilation, et ensuite d'adresser ces "bobs" au cas par cas: on jette, on démarre un projet de substitution, on documente, on garde tel quel, ..."
Bien du plaisir pour mettre ça dans un guide...
Et quel est le critière de ce "truc" ? Le libre ? La popularité ? Un "score" (sur quoi?) ? La ménagère de moins de 50 ans ? Les parts de marché ? Le potentiel pognon ? L'indispensabilité ? Nuire à MS ? Coller à la distribution la plus populaire ? Coller aux maximum de distributions ?
Je doute que le critière soit le libre...
> La liberté n'a pas été inventée par la FSF
Merci pour cette précision.
Je croyais que la FSF avais inventé la liberté.
[*] La FSF ne dicte pas la suppression de blob, elle dit seulement qu'elle ne qualifie pas de libre les distributions avec des blobs. Ne t'inquiète pas, il va rester encore plein de distribution avec des blobs, des drivers proprios, et qui d'auto-proclameront libre (la FSF ne l'interdit pas). Démonstration que la FSF ne dicte rien avec ce guide. Elle ne fait que donner son avis.
[^] # Re: toujours cette maladie...
Posté par IsNotGood . Évalué à 2.
Rappeler qu'on a le droit de ne pas être d'accord avec la FSF ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: toujours cette maladie...
Posté par Jerome Herman . Évalué à 3.
Il existe des circuits intégrés pour lesquels la différence entre le source et le firmware est minime si ce n'est existant. Les circuits logiques/portes programmables par exemple.
De plus il existe encore des gens qui programment directement en assembleur avec une traduction assembleur -> code machine faite sans aucune fioriture et hyper connue (très courant pour les 6800 like). Dans ces cas là le reverse engineering prend 5 minutes chrono en main.
Dans ce genre de cas on peut sérieusement se demander si la GPL a vraiment besoin d'un code source.
A l'inverse il est très facile d'écrire un precompiler bien baleze et de relacher le code source sous GPL sans pour autant mettre à dispo le precompiler.
Autre possibilité faire un code C sans commentaires bien obscur et relacher le code source sans le makefile.
Dans le premier cas on a pas de code source mais c'est tout à fait exploitable par un codeur tiers, et dans les deux autres cas on respecte la GPL mais c'est totalement inexploitable.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: toujours cette maladie...
Posté par Gof (site web personnel) . Évalué à 2.
# Si au moins ils allaient jusqu'au bout...
Posté par proum . Évalué à 3.
Bah tiens... Et puis quoi encore...
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par 2PetitsVerres . Évalué à 1.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par IsNotGood . Évalué à 2.
La FSF n'empêche pas exécuter un programme libre sur un OS proprio.
C'est du "Et puis quoi encore..." pour toi ?
La FSF n'impose pas qu'un source soit compilable uniquement avec du logiciel libre (Avant gcj/icedtea/openjdk, tu pouvais parfaitement faire des programmes libre en java).
C'est du "Et puis quoi encore..." pour toi ?
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par Anonyme . Évalué à 5.
Je trouve ca un peu bizarre de voulloir absolument retirer tous les firmware non libres, mais tolerer des fichiers en shareware.
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par fredix . Évalué à 4.
Bah les fichiers en question ne sont pas du code et l'idéologie de RMS s'arrête au code.
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par IsNotGood . Évalué à 2.
Ce sont des données, ce n'est pas exécuté par un cpu.
> Je trouve ca un peu bizarre de voulloir absolument retirer tous les firmware non libres
C'est du code (binaire), c'est un programme exécuté sur un cpu.
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par Guillaume Savaton (site web personnel) . Évalué à 1.
du bytecode Java, c'est du code, mais il n'est pas exécuté directement par un CPU.
On peut alors considérer que la JVM est bien un programme, et que le bytecode entre dans la catégorie des données.
Concernant les fichiers de type "artwork", dans la mesure où ils sont indispensables au fonctionnement d'un logiciel, je trouverais normal qu'on attache autant d'importance au fait qu'ils soient libres. (n'est-ce pas le même genre de débat qui a entraîné le fork de Firefox en Iceweasel, etc ?)
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par IsNotGood . Évalué à 2.
Et un source en C ce n'est pas un programme mais des données pour un compilateur...
Arrêtons ce genre de masturbation intellectuelle.
> Concernant les fichiers de type "artwork", dans la mesure où ils sont indispensables au fonctionnement d'un logiciel, je trouverais normal qu'on attache autant d'importance au fait qu'ils soient libres. (n'est-ce pas le même genre de débat qui a entraîné le fork de Firefox en Iceweasel, etc ?)
Concernant Firefox, le artwork sous trademark n'est absolument pas nécessaire au fonctionnement du programme.
Contrairement à une certaine propagande... par défaut la compilation de Firefox n'utilise pas le artwork de Firefox.
Il n'y a rien à faire pour ne pas l'utiliser, pas besoin de faire de fork, etc.
En passant, le artwork de Debian est aussi sous la protection des marques...
Donc tu n'es pas libre de faire ce que tu veux avec (comme le artwork de Firefox, de Fedora, d'Ubuntu, de Mandriva, etc).
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par 2PetitsVerres . Évalué à 2.
Ce logo ou une version modifiée peut être utilisé par quiconque voulant se référer au projet Debian, mais il ne signifie pas l'implication de Debian.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par IsNotGood . Évalué à 2.
1. Ce logo ne peut être utilisé que si :
* le produit pour lequel il est utilisé est conçu en utilisant une procédure documentée et publiée sur www.debian.org (par exemple la création de cédéroms officiels) ou ;
* une approbation officielle est fournie par Debian pour l'utiliser à cette fin.
2. Il peut être utilisé si une composante officielle de Debian (décidée en utilisant les règles du 1.) fait partie du produit complet, et à condition qu'il soit clairement précisé que seule cette composante est approuvée officiellement.
3. Nous nous réservons le droit de révoquer la licence pour un produit.
La permission d'utiliser le logo officiel sur les vêtements (chemises, couvre-chefs, etc.) sera accordée à condition qu'ils soient fabriqués par un développeur Debian et qu'ils ne soient pas vendus à des fins lucratives.
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par BAud (site web personnel) . Évalué à 4.
http://www.debian.org/logos/index.fr.html
quitte à copier/coller autant donner la référence :-)
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par IsNotGood . Évalué à 2.
Je le fais quasiment toujours.
Pas ici car 2PetitsVerres ne l'a pas fait (ce qui m'a un peu énervé :-)).
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par Kerro . Évalué à 2.
Tes commentaires sont souvent très bien, interessants et sensés. Mais alors tu es d'un chiant... :-)
Ne le prends pas mal surtout, je suis bien mal placé pour donner des leçons.
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par IsNotGood . Évalué à 2.
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par Guillaume Savaton (site web personnel) . Évalué à 1.
Exactement !
Et un programme exécutable (binaire), ce sont des données que l'OS copie de mon disque dur vers la mémoire pour qu'elles soient exécutées.
Au sens strict, dans un ordinateur, tout est "données".
> Arrêtons ce genre de masturbation intellectuelle.
Je m'attendais bien à ce genre de réponse.
Seulement, pour moi, c'est un vrai problème : la distinction entre données et code est floue. Il y a toujours moyen de tordre le vocabulaire dans le sens qui nous arrange et certains éditeurs de logiciels pourraient abuser de cette distinction "programmes libres"/"données shareware".
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par IsNotGood . Évalué à 2.
On peut le dire.
Mais si on cherche des limites dans la FSF (et la GPL) qui "tolère" du proprio (ou y ressemblant), on en trouve beaucoup.
La FSF tolère qu'un programme libre soit exécuté sur un OS proprio.
La FSF tolère les "sharewares" lorsque que ce ne sont que des données.
Etc.
Es-ce mal ?
Ce n'est pas évident. On ne va pas dire que c'est mal d'utiliser FF sur Windows :-)
# openbsd
Posté par B16F4RV4RD1N . Évalué à 9.
étrange, car la politique d'openbsd contre les blob binaires et son engagement pour le libre est pourtant légendaire...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: openbsd
Posté par Gof (site web personnel) . Évalué à 7.
</humour>
# Merci pour cette information.
Posté par brunus (site web personnel) . Évalué à 4.
Et il manque aussi la Mandriva Free, qui est censée être libre suivant les définissions de la FSF.
Est ce qu'on peut savoir, de l'avis des utilisateur Mandriva, pourquoi la Free aurait elle été mise à l'écart ? Pas 100% free ? Ils (la FSF) ont pas encore pris le temps de la décortiquer ?
Utilisateur d'Ubuntu, je n'ai pas encore pris le temps de tester Gobuntu, et je me demande aussi pourquoi elle est absente de la liste FSF. La concurence sur ce terrain, de la GnewSense ne peut pas expliquer la mise à l'écart de Gobuntu...il doit bien rester quelques trucs pas libres dans le machin.
[^] # Re: Merci pour cette information.
Posté par IsNotGood . Évalué à 2.
Donc elles n'ont à être validé par la FSF.
[^] # Re: Merci pour cette information.
Posté par bubar🦥 (site web personnel) . Évalué à 4.
une référence :
http://www.nabble.com/-Cooker--DVB-firmware-files%2C-license(...)
à lire jusqu' au bout, et suivre les liens ;)
Free (libre sens FSF)
One : livecd installable comportant des facilités.
Powerpack : soutien.
Et cerise sur le gateau, on a un avertissement sur l' utilisation de driver non libre. Exemple avec un driver Nvidia.
Voilà. Mandriva a une politique parfaitement claire sur le sujet.
La Mandriva Free est comparable à Gnewsense, selon les termes de la FSF.
Personnellement, à un utilisateur qui va se retrouver seul au moment de l' installation, je lui conseille la versione One (qui contient firmware et blob non libres) afin de lui faciliter la vie.
Lorsque je peux me charger de l' installation, je prends toujours la version Free. Ainsi je fais une installation la plus clean possible, en n' ajoutant que ce dont la mchine a besoin pour que son utilisateur l' utilise confortablement. (un firmware pour un modem, un autre pour un tuner dvb, un blob pour sa carte graphique).
[^] # Re: Merci pour cette information.
Posté par IsNotGood . Évalué à 2.
J'ai survolé. Mais c'est un autre problème. C'est un problème de licence qui ne permet pas la distribution.
Fedora ne fournit pas de blob si la licence ne le permet pas.
Fedora a le même problème que ce que tu pointes :
http://fedoraproject.org/wiki/SIGs/FirmWare
Corriger ce problème n'est pas suffisant pour être conforme à la définition de distribution libre de la FSF.
[^] # Re: Merci pour cette information.
Posté par IsNotGood . Évalué à 2.
Je ne crois pas.
Gnewsense vire tous les blobs (même ceux dans le kernel vanilla).
Un employé Red Hat a fait un "kernel-libre" pour virer les blob :
http://www.redhat.com/archives/fedora-devel-list/2008-March/(...)
Je crois qu'il y a certains trucs que tu n'as pas compris.
Il faut reconnaitre que ce n'est pas simple .
[^] # Re: Merci pour cette information.
Posté par brunus (site web personnel) . Évalué à 3.
Je ne demandais pas de comparaison avec d'autres distributions, je demandais des informations sur Mandiva Free et Gobuntu...
Est ce que tu peux définitivement essayer de faire un commentaire sans parler de RedHat ou Fedora ?
Désolé d'avoir à le dire comme ça mais tu deviens vraiment pénible, d'autant plus que tu semble omniprésent...t'as pas autres choses à faire que troller sur DLFP ? T'impliquer dans un projet libre, un LUG, de la traduction, de la doc ?
J'ai l'impression d'être sur IsNotGood-Da-Fedora-French-Page.org
[^] # Re: Merci pour cette information.
Posté par IsNotGood . Évalué à 1.
Elles ne sont pas libres selon la FSF.
J'ai voulu t'expliquer pourquoi, ... mais tu t'en branles.
T'es comme MS avec l'ISO, tout ce qui t'importe c'est de savoir si tu as le label ou non afin de l'afficher.
> Est ce que tu peux définitivement essayer de faire un commentaire sans parler de RedHat ou Fedora ?
Ici tous mes commentaires ne parlent que de Red Hat et Fedora.
La FSF a fait un guide uniquement pour Red Hat et Fedora.
Mon journal porte sur le guide de la FSF pour Red Hat et Fedora.
Lorsqu'il est parlé de blob dans le kernel vanilla ça ne conserne que Red Hat et Fedora.
Les blob ne concerne que Red Hat et Fedora.
Il faut être très con pour voir que les choses comme ça.
T'es très con.
[^] # Re: Merci pour cette information.
Posté par brunus (site web personnel) . Évalué à 3.
Si tu avais souhaité répondre sans pour autant comparer les situations de Mandriva Free et de Gobuntu avec celle de Fedora tu pouvais le faire.
Mon post s'adressais, et c'était assez évident (je demandais d'ailleur l'avis d'utilisateurs de Mandriva Free), à des gens qui connaissent assez bien Gobuntu et Mandriva Free pour pouvoir répondre et listant des licenses ou situations incompatibles avec le guideline de la FSF. Fallait pas te sentir obligé de répondre, surtout une réponse vague du genre "Il me semble que ... blob-firmware".
Si tu as des réponses intéressantes, du genre une liste de blob-firmwares proprio ou de docs dont les licenses sont pas des GPL ou libres dans Mandriva Free et Gobuntu...elle seront les bienvenues puisque le but de mon post était de recevoir ce type d'informations.
Il y a assez de contributeurs Mandriva sur ce site pour que je puisse obtenir ce genre de réponses, un peu plus précises et pertinentes que "Il me semble que...gnagnagna blob-firmware". C'est le genre de réponse qui sert à rien. Si on la prend telle-que on a toutes les chances pour partir sur une fause idée.
Bubar par exemple, a écrit cela sur un forum Mandriva (extrait du blog de esfa) :
"Les différences entre un kernel linus "brut de fonderie" (le petit nom est Vanilla) et un kernel Mandriva se situe en effet principalement dans le support matériel. Auparavant, il s'agissait "seulement" de l'ajout de 2 ou 3 trucs, mais aujourd'hui c'est plus de 300 patchs qui sont appliqués pour un meilleur support matériel (et pas seulement des "third parts" mais aussi du bon gros matos, également de la sécurité et qq goodies). "
Et je doute franchement que, même sur la Free édition, Mandriva s'amuse à mettre un noyau vanilla non patché.
[^] # Re: Merci pour cette information.
Posté par fearan . Évalué à 2.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Merci pour cette information.
Posté par brunus (site web personnel) . Évalué à 2.
C'est décrit ici, et ce sont les kernel-linus.
Mais ce n'est pas le kernel par défaut de la Mandriva Free.
[^] # Re: Merci pour cette information.
Posté par brunus (site web personnel) . Évalué à 2.
http://wiki.mandriva.com/fr/Noyau
[^] # Re: Merci pour cette information.
Posté par Misc (site web personnel) . Évalué à 4.
( ie pas de flash, de nvidia, etc ), ou les datas de jeu en shareware.
Ensuite, tout ce qui est sujet à gros tro^W^W discussion sans fin, et surtout sans facilité particuliére , genre les blobs du kernel ou pas, c'est pas fait. Mandriva Free n'a pas pour vocation de devenir la distro plus blanc que blanc de la fsf.
C'est juste pour les types qui comme moi, veulent pas de cochonnerie manifestement proprio, comme flash, comme skype, etc.
Malheureusement, la communauté autour de mandriva n'a pas les ressources dont dispose Debian ou Fedora pour pouvoir faire un tel travail d'audit systématique du code. Et au passage, je doute que la multiplication à tout va des versions apporte quelque chose.
Deja qu'il y a pas grand monde qui refuse les softs clairement proprios, alors le reste...
# Une traduction ?
Posté par MCMic (site web personnel) . Évalué à 1.
Bon bien sûr c'est pas à moi de leur dire quoi faire ^^, mais ça serait utile.
PS : et si une traduction français est déjà disponible quelque part, ça m'intéresse.
# Une position claire
Posté par GeneralZod . Évalué à 2.
Bravo pour Rahul Sundaram qui a lancé le débat et participé activement à l'élaboration du document.
Fedora Linux n'est pas libre selon la FSF, mais elle en respecte l'esprit minus la question des firmwares. On notera que RMS était plus conciliant au sujet de l'inclusion des firmware au début des discussions.
Il serait intéressant pour Fedora de proposer un noyau 100% libre selon la FSF dans les dépôts, voire même un spin dédié (que ce soit via jigdo ou bien un fichier kickstart)
Les firmwares seront probablement la prochaine bataille du logiciel libre et de FedoraProject après les pilotes libres.
[^] # Re: Une position claire
Posté par IsNotGood . Évalué à 2.
J'applaudis aussi.
L'avis de la FSF a toujours une forte valeur.
Ça peut aussi clarifier les choses. Pas dans une logique uniquement binaire (libre/non-libre), mais aussi pour qualifier une distribution.
On peut maintenant dire de Fedora (et d'autres) : "OK elle n'est pas libre selon la FSF, mais uniquement car elle intégre des blob-firmwares". On ne trompe pas sur la marchandise, on qualifie de façon courte mais assez précise et par rapport à une référence qu'est la FSF.
C'est vraiment bienvenu.
J'espère que la FSF ira plus loins dans la précision de la défintion pour aussi inclure quelques éléments du projet (fait-il la promotion du proprio (downloade en un clique sans warning), etc).
> On notera que RMS était plus conciliant au sujet de l'inclusion des firmware au début des discussions.
Je n'ai qu'un vague souvenir, mais il me semble que les propos de RMS étaient plus ciblés. De mon souvenir il disait que les blob-firmware étaient légaux (puisque Linus les accèpte et les considères comme des "données" (pour simplifier)) et donc il n'y a pas de violation de la GPL. En gros ici, RMS respecte l'avis de Linus.
Mais je n'ai pas souvenir qu'il disait que pour une distribution c'était OK pour la qualifier de libre. L'avis de Linus est respecté pour Linux, mais il n'est pas pris en compte pour la distribution (qui contient un nombre indéterminé de logiciels). La FSF ne peut pas dire : pour le projet Linux c'est OK, pour bidule ce n'est pas OK, pour machin c'est ...
Elle ne peut pas nom plus dire que c'est systématiquement OK pour les blobs pour tous les projets. Exemple fictif, imaginons un FS mais dans un blob. Pour l'utiliser il faut le charcher dans un périphérique (une carte raid par exemple) puis le noyau l'utilise via des appels au périphérique. Ça serait clairement une violation de la GPL (au moins dans l'esprit).
Linux a un historique et offre des protections (il n'y a qu'un nombre limité d'API qui n'impose pas la GPL, etc). Mais pour d'autres noyaux ?
Le document de la FSF n'est pas écrit spécifiquement pour GNU/Linux.
> Il serait intéressant pour Fedora de proposer un noyau 100% libre selon la FSF dans les dépôts, voire même un spin dédié (que ce soit via jigdo ou bien un fichier kickstart)
Non :-)
Du moins, pas comme ça.
Ce que tu proposes, c'est comme si Fedora avait livna par défaut et qu'il existait des spins (pour caricaturer des "sous-distributions") sans livna.
A mon avis, si Fedora veut virer les blobs, la distribution officielle Fedora (c'elle supportée et développée par Fedora) ne doit pas avoir de blobs.
Le noyau avec les firware (ou seulement les firmwares) doivent être ailleurs (par exemple livna). Idem pour les spins (notons qu'on peut aussi ajouter des dépôts lors de l'installation ce qui rend les spins non indispensables pour la majorité des installations).
La version la plus libre de Fedora ne doit pas être le parent pauvre de Fedora, la moins supporté/testé/développé par Fedora. Bien au contraire.
Après chaqu'un est libre, de sa propre initiative, en fonction de son matériel, de "polluer" la distribution avec des blobs, Flash, des drivers proprio, etc.
Ce modèle, même s'il est beaucoup critiqué car il demande des actions supplémentaier à beaucoup l'utilisateur, marche. Les contributeurs le respectent très bien. La communcation de Fedora gagne en cohérence en gardant ce modèle. Je ne veut pas d'un GoFedora parent pauvre de Fedora :-)
[^] # Re: Une position claire
Posté par IsNotGood . Évalué à 2.
Ni la GPL.
[^] # Re: Une position claire
Posté par IsNotGood . Évalué à 2.
http://www.redhat.com/archives/fedora-devel-list/2008-March/(...)
kernel-libre (hopefully 100% Free) for Fedora 8 and rawhide
Le fil de discussion est très intéressant, mais diablement long.
[^] # Re: Une position claire
Posté par benoar . Évalué à 5.
[^] # Re: Une position claire
Posté par IsNotGood . Évalué à 3.
Fedora-devel est une mailing ouverte. Donc forcément.
> et qui font chier tout le monde en disant que leur travail ne sert à rien
On le voit assez peu dans ce thread.
Alexandre Oliva (qui a fait et proposé kernel-libre, et qui est aussi à l'origine du thread) était un peu têtu ou c'est trop braqué.
En effet, beaucoup ne voit pas l'intérêt de virer les firmware. Par contre, il y a eu plus d'ouverture que tu ne le crois.
Alexandre Oliva veut garder son "fork". Ce qui lui est proposé comme direction, et à plusieurs reprise, est de bosser avec les mainteneurs noyaux, en upstream Linux, afin de trouver une vraie solution.
Même les développeurs qui n'ont rien à foutre des firmwares, accèptent cette démarche. Mais Alexandre Oliva ne veut rien entendre et c'est bien dommage.
L'un des gros problèmes est qu'il faut patcher le paquet upstream.
On pourrait imaginer, et ce directement upstream (sur http://www.kernel.org/), un paquet linux-2.6.28.tar.gz avec à côté et optionnellement linux-firmware-nonfree-2.6.28.tar.gz.
Il faudrait développer un mécanisme pour avoir les firmwares dans le noyau (c'est pour l'embarqué et réalisé à la compilation) ou hors du noyau (typiquement dans /lib/firmware). Le noyau Fedora étant construit que depuis linux-2.6.28.tar.gz. Après libre à chaqu'un de packager linux-firmware-nonfree si ça le chante. Comme d'autres sont libre de packager le driver proprio NVidia.
Cette démarche (dans les très très grandes lignes) est proposée à
Alexandre Oliva mais il fait la sourde oreille. Démarche aussi proposée par des gens qui n'ont rien à foutre des firmwares.
Espérons qu'Alexandre Oliva soit plus ouvert et qu'un consensus s'installe.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.