Le firmware ne fait pas parti de l'OS. Le fait qu'un firmware ne soit pas opensource n'implique pas que l'OS ne l'est pas.

Ceci dit, il y a effectivement des drivers pseudo opensource dans les distrib linux, comme par exemple le driver nv (soit disant libre) pour les cartes graphiques nvidia mais ce code est un bon gros binaire dont on n'a pas vraiment le source.

Poste le Sunday 24 June 2007 16:36:36

Y a-t-il une liste précise et exhaustive des fichiers sources du kernel Linux qui ne sont pas publiées sous licence GPL?

Poste le Friday 29 June 2007 00:20:17

extrait du README des sources du kernel :

Citation

WHAT IS LINUX?

Linux is a clone of the operating system Unix, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers across
the Net. It aims towards POSIX and Single UNIX Specification compliance.

It has all the features you would expect in a modern fully-fledged Unix,
including true multitasking, virtual memory, shared libraries, demand
loading, shared copy-on-write executables, proper memory management,
and multistack networking including IPv4 and IPv6.

It is distributed under the GNU General Public License - see the
accompanying COPYING file for more details.

Et dans le copying en question, il n'est question que de la GPLv2 (et pas plus)

D'autre par un petit :

grep -riE 'Licence\s*:' /usr/src/linux

montre bien qu'il n'y pas d'autre licence dans le kernel.

Poste le Friday 29 June 2007 11:21:19

alors où sont les firmware non libres? Je n'ai critiqué aucun OS, je veux seulement savoir où est le code non-libre. Ou est le source de nv pour pouvoir dire qu'il est non libre? Je peux le voir où ce binaire précompilé? (nv est bien un pilote pour X, mais je n'ai pas l'impression qu'il soit non-libre, peut être parlez vous de son pendant binaire nvidia le bon gros pilote des familles)

Poste le Friday 29 June 2007 14:21:08

ils ne font pas parti du kernel.

Poste le Saturday 30 June 2007 18:19:45

Alors comment fonctionnent-ils sur une machine? ?-( Les pilotes nvidia dédiés sont non libres car binaires, mais d'où vient le code non-libre autrement qui fonctionne sur linux?

Poste le Saturday 30 June 2007 19:33:20

Pour les cartes wifi Intel pro wireless 2200, par exemple, un pilote libre est intégré au noyau Linux. Mais il ne fonctionne que si on installe par ailleurs un firmware.

Poste le Saturday 30 June 2007 23:40:25

En fait, si je ne me trompe pas, tout ça doit provenir des discussions sur les pilotes en userspace (lire le Linux Mag France de Mars pour plus d'infos), mais ça ne change absolument rien pour l'instant : le noyau est 100 % GPL. Par contre, les distributions qui incluent les pilotes propriétaires ne le sont pas, elles.

[catwell.info]

Poste le Sunday 1 July 2007 10:40:12

ils fonctionnent de la même façon que fonctionnent les logiciels libres sous windows.
L'OS peut être libre et les programmes qui l'utilise ne pas l'être.
L'OS peut ne pas être libre et les programmes qui l'utilise l'être.
Ou les deux ou ni l'un ni l'autre.

Linux est Libre, il peut utiliser des périphériques qui ont firmware libre ou pas. En l'occurrence les périphériques ayant un firmware libre ne sont pas légion.

Pour ce qui est des drivers NVidia ils sont constitué deux deux parties (principales) :
* un module (nvidia.ko) qui est chargé de l'interface entre le matériel et la seconde partie.
* un driver X (nvidia_drv.so).
Les deux sont propriétaires.

Mais si tu charge le driver propriétaire, le kernel te le dis :

nvidia: module license 'NVIDIA' taints kernel.

Ce qui signifie que à partir du moment ou tu charges ce module : les développeurs ne répondrons pas à tes rapports de bug car ils ne peuvent pas utiliser leurs outils de débugage pour savoir si le bug vient du kernel ou du driver.

Poste le Sunday 1 July 2007 14:24:43

Citation

le noyau est 100 % GPL. Par contre, les distributions qui incluent les pilotes propriétaires ne le sont pas, elles.

quand meme quand l'info vient de stallman je pense naturellement qu'on nous cache des choses ....et que c'est un ABUS de GPL et que donc l'usage fait de la licence sur le noyau pose probleme a cause de code clos deguise en source... comme par exemple les procedures assembleur inline ou lee code a manipulation de byte directement dans la memoire permettant ensuite d'appeler une suite de byte au meme titre qu'un programme binaire charge ....

ce qui est tout a fait possible et le code qui execute la manipulation peut etre gpl dans sa V2 mais le code reellement executer contient bien alors un executable binaire autogenere par le code mais dont le code n'est pas vraiment fourni...

de la meme maniere qu'un script batch peut generer un autre script batch pour le lancer....

a titre d exemple

#!/bin/sh
echo "echo toto" > t
sh ./t 
rm t

mais avec un traitement de 250Ko immaginez a quel point il est impossible ou presque de maitriser ce qui est reelement cree et execute dans ces 250Ko...

si le noyau passe en GPL v3 un jour le probleme n'existera plus car cette pratique y est interdite...

Poste le Sunday 1 July 2007 19:44:55

Torvalds s’est opposé au passage du noyau à la GPL 3.

--
On ne prête qu’aux riches, et on a bien raison, parce que les autres remboursent difficilement.
-+- Tristan Bernard (1866-1947) -+-

Poste le Monday 2 July 2007 06:37:05

Citation
francoisp
je pense naturellement qu'on nous cache des choses

Ça doit être un complot des Judéo-Maçons ) ....

Sans rire, parce que Stallman le dit, alors c'est vrai ... Je ne crois pas que Stallman soit le messie. Il lui arrive de dire des conneries et surement d'en faire.

Le code de Linux est 100% GPLv2 et par contre il peut charger des firmwares non libre dans les périphériques.

Ça peut ne pas te plaire : c'est ton droit le plus stricte, et je ne peux le contester. Mais ça ne rend pas le code de Linux non GPL. Que le code de certains firmware soit non libre c'est aussi un fait. Mais en même temps le firmware de ma HP Laserjet 1100 non plus il n'est pas libre et pourtant c'est pas en utilisant le HURD (pourtant 100% GPL au sens où tu sembles l'entendre) que je pourrais le rendre libre vue qu'il n'est pas (facilement) modifiable.

Un autre exemple : quelle différence entre un périphérique qui refuse de faire quoi que ce soit avant qu'on lui envoie le nombre 12 et un périphérique qui refuse de faire quoi que ce soit avant qu'on lui envoie le nombre 12121212121212121212121212121212121212121212121 qui correspond en fait au firmware du dit périphérique ? Dans les deux cas, il faut leur envoyer un nombre : un petit pour le premier, un grand pour le second mais bon ce ne sont que des nombres "magiques" (ie: ils servent à initialiser le périphériques et leur valeur est définie par le constructeur). Si mon OS utilise le premier : tu t'en fout, mais si il utilise le second, tu vas me dire que mon OS n'est pas GPL parce que le nombre 12121212121212121212121212121212121212121212121 contient un code non GPL ...

La controverse vient ici du fait que le firmware de certains périphériques n'est pas chargé en dure dans le périphérique mais a posteriori lors de l'initialisation du dit périphérique.
Vouloir absolument des firmwares libres revient à jeter pratiquement 100% des périphériques que nous utilisons ou alors à ne vouloir des firmwares libres que pour les périphériques dont le firmware est envoyé lors de l'initialisation...

J'aimerais bien des firmwares libres. Tu peux être « intégriste » (note les guillemets) mais quoi que tu (ainsi que Stallman) en dises le code des firmware NE fait PAS parti du code de l'OS pas plus que le code du firmware de ma HP LaserJet 1100 ne fait parti du code d'aucun OS qui est capable de l'utiliser. Et donc la liberté de CE code ne change rien à la liberté (ou non) de l'os utilisant ce firmware.

Poste le Monday 2 July 2007 17:16:41

En fait je comprends assez bien cette situation.

Imaginons que je veuille créer un périphérique dédié à mes besoins, basé sur un pic USB spécialisé. Je vais donc utiliser le firmware du PIC (bien obligé), qui n'est pas libre, bien qu'ayant des spécifications particulièrement bien documentées. (Je me permet de remarquer qu'à ce niveau, ça touche vraiment au hardware, difficile de crier au loup, il faut bien que microchip vende des puces un tant soit peu utilisables) .

Donc je vais écrire un code assembleur ou C pour ce pic, qui ne fonctionnera pas sur mon PC mais bien sur le pic exclusivement. Seulement, pour que mon périphérique soit utilisable, je vais coder un driver en utilisant l'API dédiée à l'USB du kernel Linux (qui est sous GPLv2, le kernel Linux). Conséquence : mon driver sera sous GPLv2.

Le résultat c'est que j'invoque un système d'interfaçage logiciel/matériel basé sur du code sous GPL et sur du code qui n'est pas sous GPL, celui qui est dans le PIC.

Le problème est de considérer ce qui se passe lorsque j'utilise ce périphérique : la somme des composantes logicielles utilisent du code qui est sous GPL, le kernel Linux, ce qui oblige d'après la GPL à publier l'ensemble de mon code qui se trouve en mémoire code du PIC sous GPL. Est-ce que c'est quelque chose de raisonnable? Dans la mesure où n'importe qui a tout loisir d'acheter des PIC et de recopier le code qui est sous GPL dedans, donc de réaliser la même opération commerciale que la personne qui a mis son matériel sur le marché en premier, ça favorise la contrefaçon de quelque chose qui a plus un aspect matériel que logiciel. (Une souris, bien qu'il y ait des µcontrôleurs et du code proprio dedans, ça reste un matériel à mon avis).

Donc le problème, c'est bien que le code du kernel Linux (sous GPL) invoque du code non GPL pour faire fonctionner les périphériques. Mais si la norme USB existe, je pense qu'elle permet de s'affranchir de ce genre de problèmes.

Tout ça est compliqué, mais quand même, je ne pense pas être obligé de disposer du code interne de ma souris pour la faire fonctionner. ça serait un peu trop difficile de faire marcher mes périphériques dans ce cas. #%b

Après, il y a toujours le problème des périphériques qui ne sont pas normés et qui demandent une initialisation en mémoire interne pour fonctionner, ouais, c'est pas terrible comme système, en plus c'est pas fait pour faciliter l'interfaçage avec n'importe quel noyau, à moins d'avoir les spécs Ultra-secrète classée défense (!) attention.

En fait à mon avis, ça reste le problème du code non libre qui tourne sur le PC, et à part les logiciels qui te demandent d'accepter une licence, je ne vois pas ce qui dans le kernel Linux est non-opensource. Tant qu'il y a du code C lisible, et copyrighté sous GPL, on a bien un kernel linux Opensource.

On revient donc au problème des gros pilotes non-libres de type nvidia et fglrx pour ati. Quant au microcode qui tourne sur les périphériques, je crois que c'est essentiellement le problème des pilotes libres qui obligent pour utiliser le périphérique à utiliser certaines fonctionnalités restrictives vis-à-vis de l'utilisateur codées dans le périphérique même, par exemple le contrôle du niveau d'encre pour une imprimante, ce genre de choses.

Autrement, j'aurai du mal à voir où est le problème de faire marcher du microcode d'un périphérique :-o . Faut bien que les périphériques marchent quand même :-/.

Merci de me corriger si je dis n'importe quoi.

Poste le Tuesday 3 July 2007 03:52:52

Je me demande également, comment le kernel Linux peut-il charger des firmwares dans les périphériques? Je n'ai pas encore vu de fichiers binaires dans un tarball du noyau. À moins que ce ne soit les patchs des distribs qui introduisent les fichiers binaires, je ne vois toujours pas ou est le code non-libre chargé par l'OS. Enfin... Tout ça pour dire que je ne vois pas où est le binaire non-libre mis en mémoire code des périphériques lors de leur utilisation, à part encore une fois pour les nvidia et fglrx pilots proprios ds cartes graphiques et autres logiciels qui demandent d'accepter une licence interdisant l'ingénierie inverse à l'installation.

Poste le Tuesday 3 July 2007 03:59:17

Encore une fois, pour les cartes wifi Intel pro wireless 2200, le pilote libre fourni avec le noyau ne suffit pas à utiliser la carte. Il faut aller chercher sur le Web un firmware et le placer au bon endroit.

Poste le Tuesday 3 July 2007 09:02:53

d'accord, mais le firmware est en mémoire code du périphérique, pas dans la RAM de l'ordinateur? Oui, il y a quelque chose de semblable avec les Stick TV USB Terratec, c'est vrai, un firmware à charger.

C'est vrai également que d'obliger l'utilisateur à charger un binaire dans la mémoire code du périphérique pour le faire marcher, cela semble être un moyen de limiter l'utilisateur s'il n'a pas le bon pilote certifié.

Poste le Tuesday 3 July 2007 11:22:09

je ne connais pas grand chose en firmware et tout ce bataclant... mais pour un de mes périférique, un carte usb wifi, une dell wireless 1450, des développeurs on écrit un firmware pour entre autre cette carte grace aux infos propriétaire de la/les puces... j'ai donc (je pense) pour ma carte, tout en gpl (si bien entendu mon driver est sous licence gpl) non? le driver est islsm...

Poste le Tuesday 3 July 2007 13:16:09

Il suffit de regarder l'en tête des fichiers de code source pour savoir si celui-ci est publié sous GPL.

Poste le Tuesday 3 July 2007 13:39:36

Mon modem ADSL F@st800 nécessite un firmware propriétaire aussi, bien que le pilote soit libre (ueagle-atm).

.:! L'être humain est au sommet de la chaîne alimentaire. Certes. Mais il est surtout au sommet de la connerie et de la bêtise... !:.
-- Pour les nouveaux linuxiens : Ce n'est pas en continuant de faire ce que l'on connaît que l'on pourra faire ce que l'on ne connaît pas --

Poste le Tuesday 3 July 2007 13:49:16