Bonjour,
Un petit journal bookmark à propos d'une information intéressante.
Android utilise une libc perso nommée Bionic qui permet sortir le userspace du monde GPL. Pour offrir les include du noyau, ils génèrent de nouveaux include de manière automatique qui d'après eux ne contiennent pas de code sous copyright
Or, d'après Florian Mueller ce n'est pas le cas, ces headers contiennent du code sous GPL ce qui rendrait toutes les applis userland GPL.
Si cela se révèle vrai, on peut imaginer que le modèle actuel d'appli propriétaires sous android deviendrait caduc. S'en suivrait sans doute une massive désaffection des constructeurs et éditeurs qui ne sont pas prêts à embrasser le modèle du libre (enfin, si mais seulement pour le code des autres).
Voila, le petit résumé, désolé, je n'ai pas le temps d'en faire plus aujourd'hui (même pas encore fini l'article, mais j'ai fini mon café).
Et enfin, les liens : - Résumé en français - l'article original - les .h concernés
# userland GPL et libc GPL ou non
Posté par allcolor (site web personnel) . Évalué à 10.
Je comprends pas ce truc de "userland GPL"... une libc (GPL) ne peut pas être propagée vers le userland (ie: imposer la GPL à du code userland) parce que ce userland se link avec elle... vu qu'il existe une tonne de libc (non GPL). Et d'ailleurs sous linux on peut parfaitement faire du userland proprio écrit en C/C++ whatever. Si ce n'était pas le cas, il suffirait d'implémenter une API en GPL pour que tout programme utilisant cette API si compilée pour un système libre se voit de facto passer en GPL ce qui me semble totalement absurde.
Je veux bien que la libc google (bionic) soit obligée de passer en GPL si il est montré que celle-ci utilise du code du noyau linux (lui en GPL)... mais je ne vois absolument pas en quoi ceci impacterait un quelconque prog userland à moins que celui-ci tape directement dans le kernel (donc sans passer par le wrapper libc).
[^] # Re: userland GPL et libc GPL ou non
Posté par jardiland . Évalué à 7.
Même si un prog userland tape directement dans le kernel sans passer par le wrapper libc, ça n'en fait pas un programme GPL. Linus est très clair là dessus :
http://www.kernel.org/pub/linux/kernel/COPYING
[^] # Re: userland GPL et libc GPL ou non
Posté par allcolor (site web personnel) . Évalué à 1.
Quand je dis tape directement c'est sans utiliser la voie normale ;)
[^] # Re: userland GPL et libc GPL ou non
Posté par jardiland . Évalué à 2.
C'est possible ça ?
J'y connais pas grand chose en programmation système, mais il me semblait qu'on pouvait pas appeler du code noyau sans passer par un appel système standard (sécurité, toussa).
[^] # Re: userland GPL et libc GPL ou non
Posté par allcolor (site web personnel) . Évalué à 2.
http://lwn.net/Articles/394399/
[^] # Re: userland GPL et libc GPL ou non
Posté par Éric (site web personnel) . Évalué à 3.
Tel que je le vois ça peut rendre Bionic GPL (parce que Bionic diffuse des morceaux de code GPL, ne fait pas que les utiliser), éventuellement un peu plus si jamais des choses sont trop intimement liées à Bionic et peuvent être considérées comme indissociables de Bionic.
En aucun cas la GPL ne se propage aux programmes utilisateurs. Il y a même un passage là dessus dans la GPL : l'utilisateur des outils de dev de la plateforme, y compris le noyau, n'impose pas les conditions de diffusion de la GPL.
Si c'était le cas, ça s'appliquerait aussi à la GLIBC.
[^] # Re: userland GPL et libc GPL ou non
Posté par Franck V . Évalué à 2.
A priori la glibc est sous LGPL pour éviter justement que le userland ne le devienne aussi.
Tu as un lien vers le passage de la GPL qui autorise ça ?
[^] # Re: userland GPL et libc GPL ou non
Posté par allcolor (site web personnel) . Évalué à -1.
Oui... mais c'est tiré par les cheveux étant donné qu'un programme C link forcément sur une libc je vois mal comment montrer à un juge qu'un programme C compilé sur un système avec une libraire C en GPL est un dérivé de cette même librairie (GPL)... or c'est ça qu'il faudrait montrer et ça c'est tiré par les cheveux, car ça voudrait dire que tout programme écrit en C est forcément en GPL. A la limite je veux bien que ça puisse limiter la distribution d'un programme proprio sur la plateforme (et donc si ton programme est en C et proprio... si tu veux pas le diffuser en GPL alors tu ne peux le distribuer sur la plateforme avec la libc GPL ou si tu le veux vraiment tu dois fournir ta libc à toi non GPL)... mais l'histoire de ces 20 dernières années nous montre que cette théorie ne tient pas à priori.
Puis il y a l'exception "System libraries" dans la GPL et je doute qu'elle ne marche que dans un seul sens (ie: un prog GPL compilé pour un OS proprio et donc linké avec une libc proprio)... car ce serait se donner un droit en plus que les autres (moi je peux linker vers toi parce que je le vaux bien mais toi c'est pouet-pouet :D )
[^] # Re: userland GPL et libc GPL ou non
Posté par Antoine . Évalué à -2.
Le juge 1) connaît mieux le droit d'auteur que toi 2) a moins de préjugés sur le sujet que toi.
Mettre une bibliothèque sous GPL implique qu'on veut interdire la liaison avec autre chose que du code GPL ; c'est une décision qu'il faut respecter (cf. x246 ou ffmpeg).
L'exception "System libraries" est conçue pour permettre l'écriture de logiciels sous GPL pour des systèmes non-libres, pas pour ouvrir une porte dans l'autre sens.
[^] # Re: userland GPL et libc GPL ou non
Posté par allcolor (site web personnel) . Évalué à 0.
On parle de la librairie C... si c'est le cas, alors tu peux attaquer tout le monde en disant qu'ils violent la GPL car clairement si c'est vrai, tout programme C est un dérivé de linux, vu que linux est en GPL, que toute libc pour linux incorporera des headers de linux sous GPL ==> libc en GPL ==> userland en GPL.
C'est débile et indéfendable.
Oui et le sens-unique me semble indéfendable tout autant.
Mais il est vrai IANAL... mais si ce qui est dit dans l'article était possible... ça fait presque 20 ans que la GPL est contournée sans vergogne sous linux par des progs userland.
[^] # Re: userland GPL et libc GPL ou non
Posté par Antoine . Évalué à 5.
Bon, je vois que tu racontes n'importe quoi. Linux n'est pas "la librairie C", c'est la glibc (sous LGPL) qui joue ce rôle. De plus un programme C n'a pas besoin de Linux pour fonctionner, n'importe quel runtime (BSD, Windows ou même GNU/Hurd) implémentant le standard C fait l'affaire.
Quant à Linux il y a une exception très claire qui autorise n'importe quel code userspace à utiliser les appels système du noyau, sans pour autant être sous GPL. Je cite, fichier COPYING:
Encore une fois, tes jugements moraux n'ont aucune incidence sur la façon dont fonctionne le droit d'auteur. Je répète, les bibliothèques sous GPL existent et les lier avec du code non-GPL est une violation de leur licence.
Et je signale que le droit d'auteur, en France, est considéré comme une sorte de droit fondamental. Ce n'est pas avec des arguties du genre "c'est débile" que tu pourras convaincre un tribunal de passer outre.
[^] # Re: userland GPL et libc GPL ou non
Posté par allcolor (site web personnel) . Évalué à -6.
TU fais un homme de paille de sable de la manche.. je n'ai jamais dis ce que tu me fais dire ... donc ce que tu réponds ===> /dev/null.
[^] # Re: userland GPL et libc GPL ou non
Posté par allcolor (site web personnel) . Évalué à -2.
Pour réexpliquer car à mon avis tu vas avoir la flemme de 1) aller lire l'article concerné par ce journal 2) lire les commentaires au-dessus.
Il serait reproché à la libc d'androide (bionic) d'importer des header regénéré du noyau linux et que ceux-ci serait "contaminé" par la GPL du noyau rendant de ce fait la libc d'android GPL qui "contaminerait" à sont tour les programmes userland en GPL... à comparer à la GNU libc (glibc) qui est en LGPL qui incorpore elle aussi (mais là directement) les header du noyau linux mais qui elle par magie ne serait pas touchée...
Alors oui un programme C n'a pas besoin de linux pour tourner (argument donné premier commentaire) oui n'importe quel runtime (BSD, Windows ou même GNU/Hurd) implémentant le standard C fait l'affaire. (argument donné premier commentaire)
Donc l'article raconte n'importe quoi (argument donné premier commentaire).
C'est l'argument 'la libc bionic incorpore des header du noyau GPL ==> libc est GPL ==> userland est GPL qui je me cite "C'est débile et indéfendable." !
Voilà si tu te le demandais pourquoi tu fais un homme de la mer\^W\^Wpaille.
Ou alors je te piges pas (ce qui reste possible) et t'a position serais que tu es d'accord avec l'article mais mon petit poucet me dit que non.
[^] # Re: userland GPL et libc GPL ou non
Posté par Antoine . Évalué à 1.
Ça va, tu peux te calmer...
Mon premier commentaire répondait à cette affirmation de ta part:
qui est clairement erronée ou bien très mal formulée : j'ai donné l'exemple de ffmpeg et x264, qui sont sous GPL précisément pour éviter l'utilisation dans du logiciel proprio. Et apparemment tu n'as pas cherché à réfuter.
Maintenant je suis d'accord que ton affirmation était hors-sujet dans le cadre du sujet traité, mais ça c'est ton problème...
[^] # Re: userland GPL et libc GPL ou non
Posté par allcolor (site web personnel) . Évalué à 0.
je vois pas ce que ton exemple de ffmpeg vient faire là et en quoi il répond à ce que j'ai dit.
Si il y avait deux implémentation de ffmpeg (même API) dont une proprio, je verrai un parrallèle mais pas là. Si il y a 2 impl de la même API, le truc est que tu peux pas dire d'un programme qui utilise la dite API qu'il est un dérivé de la lib implémentant l'API en GPL... je veux bien que ça pose un problème de distribution du dit programme si distribué sur le système n'ayant que la lib en GPL... mais ça n'en fait certainement pas un dérivé pour autant de la lib GPL (et certainement pas si la dite implémentation est postérieur à une impl non GPL).
Et le "tu peux te calmer" s'applique à toi, tu attaques et donc tu te calmes moi je t'ai rien demandé.
[^] # Re: userland GPL et libc GPL ou non
Posté par psychoslave__ (site web personnel) . Évalué à 3.
Comme dit plus haut, si tu utilises que du POSIX, on peut effectivement te reprocher quoi que ce soit. Maintenant s'il y a des extensions propres à la glibc que tu utilises dans ton code, c'est déjà plus défendable.
[^] # Re: userland GPL et libc GPL ou non
Posté par dyno partouzeur de drouate . Évalué à 6.
Ben surtout que la libc est LGPL, pas GPL, donc j'ai l'impression que c'est beaucoup de bruit pour rien
[^] # Re: userland GPL et libc GPL ou non
Posté par Alex . Évalué à 4.
on parle de bionic en particulier, qui est distribué sous bsd.
[^] # Re: userland GPL et libc GPL ou non
Posté par superna (site web personnel) . Évalué à 1.
Oui mais le bout de code "GPL" sont LGPL si tirés de la gnulibc... donc au final ce serait LGPL avec tout ce qui s'en suite, mais mois qu'avec la GPL
[^] # Re: userland GPL et libc GPL ou non
Posté par Franck V . Évalué à 1.
Apparemment c'est du code du noyau lui même qu'ils auraient repris, rien à voir avec la glibc.
Quelqu'un sait si la glibc utilise aussi des headers du noyau ?
[^] # Re: userland GPL et libc GPL ou non
Posté par allcolor (site web personnel) . Évalué à 2.
Sans doute... ou pas, de toutes façons, la glibc étant LGPL et que la LGPL est une licence compatible GPL la question ne se pose pas quand au fait que la glibc puisse le faire... elle le peut ;)
[^] # Re: userland GPL et libc GPL ou non
Posté par Franck V . Évalué à 3.
Non, compatible GPL veut dire que du code LGPL peut être intégré dans du code GPL pas l'inverse.
[^] # Re: userland GPL et libc GPL ou non
Posté par allcolor (site web personnel) . Évalué à 3.
Non, ça veut juste dire que tu dois redistribuer le tout sous GPL... pas que ton prog sous LGPL ne puisse être sous LGPL. (on est d'accord ça rend de facto ton prog GPL si tu ne peux avoir un remplacement pour la lib GPL) mais quelqu'un peut reprendre ton code et le distribuer en pure LGPL si il ne link plus vers la partie sous GPL (ce qui serait impossible si de facto ton code était sous GPL car tu link sur la GPL). Ton code est bien sous LGPL mais la distribution du code fonctionnet (qu'on peut faire tourner) est elle en GPL.
[^] # Re: userland GPL et libc GPL ou non
Posté par Franck V . Évalué à 3.
OK, mais dans ce cas là, ça veut dire que la version compilée de la glibc qui est intégrée dans nos distribution se retrouve au final sous GPL puisqu'elle comporte un mix de codes sources GPL et LGPL.
Du coup je ne pige plus l’intérêt de la LGPL dans ce cas particulier...
La FAQ de la GPL semble indiquer qu'une librairie GPL implique forcement la GPL-isation du code l'utilisant (au contraire de la LGPL).
[^] # Re: userland GPL et libc GPL ou non
Posté par allcolor (site web personnel) . Évalué à 0.
Pour moi comme je dis plus haut ça sert à rien... car je trouverai complêtement absurde qu'on considère un programme C dérivé de la librairie C et donc à fortiori impacté par la GPL si ce prog était compilé sur un OS dont la libc était GPL.
De plus je ne pense pas que les header linux impacte la glibc et donc la force en GPL vu que la glibc est portée sur d'autre kernel il me semble ===> il va être difficile de considérer la libc comme un travail dérivé du kernel.
La GPL est transmise au travaux dérivé et ici que ce soit le link de la libc sur le kernel ou le link de programme userland sur la libc c'est plus qu'absurde de considéré ça comme des travaux dérivé... car à partir de là tout est un travail dérivé du kernel et ça c'est simplement stupide.
Donc pour moi le choix de la licence LGPL fait à l'époque pour la glibc est juste un effet d'annonce pour dire "allez on peut faire aussi du pas libre chez nous.. sûr ;)"
[^] # Re: userland GPL et libc GPL ou non
Posté par jjl (site web personnel) . Évalué à 2.
J'avoue que c'est aussi un point qui me gène. A priori, je suis assez d'accord avec toi.
Mais c'est ce qu'il dit dans son post :
J'ai lu quelques § de plus mais je n'ai pas encore trouvé d'explication.
[^] # Re: userland GPL et libc GPL ou non
Posté par Fulgrim . Évalué à 5.
Ca ressemble beaucoup aux "analyses" faites concernant "la carte et le territoire". Tu trouveras une explication de pourquoi ce n'est sans doute pas vrai la bas :
http://www.maitre-eolas.fr/post/2010/12/26/Lrsquo%3Baffaire-ldquo%3Bla-carte-et-le-territoirerdquo%3B
[^] # Re: userland GPL et libc GPL ou non
Posté par psychoslave__ (site web personnel) . Évalué à 7.
En aucun cas la conclusion donné est correct. Même si effectivement il y a infraction au droit d'auteur, ça ne force pas la distribution du reste du code. Ça veut juste dire que les auteurs du code peuvent porter l'affaire devant un tribunal, qui peut décider d'interdire aux contrevenants de continuer à diffuser les logiciels sans les sources et à payer des dédommagements. Le tribunal ne peut pas, à ma connaissance, prononcer une condamnation à placer le code des contrevenants sous GPL.
# Est-ce un Troll?
Posté par Damien Thébault . Évalué à 9.
L'auteur me semble ignorer un peu comment fonctionne un système complet kernel + userspace.
Par exemple:
Il faudrait lui expliquer que "libc" n'est pas le nom d'une implémentation, mais c'est sa fonction. On peut parler de "BSD libc", de "GNU libc", mais on peut difficilement dire que "Bionic est basé sur le code de libc".
La GNU libc est également basée sur les headers du kernel, qui sont inclus lorsque la libc est installée, sinon il ne serait pas possible d'écrire des programmes user-space utilisant des structures du noyau. Par exemple "linux/input.h".
Et effectivement le copyright qui est inscrit dans le fichier d'origine de linux dit que c'est GPLv2, par contre le fichier COPYING général du kernel mentionne bien qu'il est autorisé d'utiliser les APIs du kernel en utilisant des appels systèmes.
Il y a donc un problème puisque ces headers doivent être distribués avec la libc, mais leur license dans le kernel (GPLv2) ne correspond pas à l'autorisation de les utiliser depuis le userspace.
En fait, si on se dit que cette attaque est fondée, on s'aperçoit que c'est exactement le même cas sur un système GNU/Linux classique.
C'est exactement la même chose. Un programme proprio n'aurait donc pas le droit d'accéder à "linux/input.h".
Perso je suis contre cette interprétation. Comment je peux utiliser un device evdev depuis un programme proprio si je ne peux pas include "linux/input.h"?
Je ne comprends pas bien le message de Linus à l'époque sur LKML http://lkml.org/lkml/2003/12/5/13 , si il parle bien d'applications user-space ou de modules kernel. Si il parle d'applications user-space ça change beaucoup de choses et je ne suis pas sûr de vouloir continuer à utiliser GNU/Linux. Ou sinon c'est juste un message totalement hors contexte, ce qui ressemblerait donc à du Troll de la part de l'auteur de l'article.
Par rapport à la conclusion, je ne vois pas en quoi remplacer Bionic par la GNU libc changerait quoi que ce soit du point de vue des applications user-space, ils vont continuer à inclure des headers GPL du kernel...
Bref, ça me semble plus à du troll qu'à autre chose. Je veux bien voir ce qu'en disent les devs du kernel plutôt que cet article lui-même.
[^] # Re: Est-ce un Troll?
Posté par j_kerviel . Évalué à 9.
Il semble que Florian Mueller, connu pour ses luttes contre les patentrolls, soit lui même un sacré troll.
Il agit beaucoup par intérêt personnel.
Beaucoup de bruit pour pas grand chose j'ai l'impression.
[^] # Re: Est-ce un Troll?
Posté par Jux (site web personnel) . Évalué à 5.
Le fil de discussion sur la LKML parle de modules qui utilisent et link avec des headers/structures internes au kernel.
Le message de Linus dans ce fil, dont Florian Muller cite une partie, discute de la différence entre "avoir le droit d'utiliser un programme" et "avoir le droit de linker avec ce programme". Mais c'est toujours dans le contexte des modules kernel qui linkent avec des structures internes au noyau parce qu'il n'existe pas d'API pour les modules.
Bref, la citation de Linus dans l'article de M. Muller est complètement sortie de son contexte.
[^] # Re: Est-ce un Troll?
Posté par bubar🦥 (Mastodon) . Évalué à 7.
Il y a même un autre troll, caché dans le titre :
Et si Android était en fait libre
Sous entendant ainsi que BSD c'est pas libre.
Bravo, bravo, c'est du haut vol :-)
# Petite comparaison entre bionic et glibc
Posté par Jux (site web personnel) . Évalué à 10.
L'argument sur lequel se fonde Florian Mueller pour dire que la GPL devrait se transmettre à la lib bionic est que cette dernière contient ce genre de fichiers (il s'agit de fcntl.h ici):
http://android.git.kernel.org/?p=platform/bionic.git;a=blob_plain;f=libc/kernel/common/asm-generic/fcntl.h;hb=HEAD
Il s'agit en fait de headers auto-générés qui reprennent les structures nécessaire pour communiquer avec le noyau.
Maintenant, si on s'intéresse à la glibc, que Florian Muller conseille d'utiliser à la place de la lib bionic pour résoudre le problème, on se rend compte qu'elle fait exactement la même chose. Sauf qu'il n'y a pas de notice dans le header qui dit que ça a été généré automatiquement. Par exemple pour fcntl.h, il se trouve là pour la glibc :
glibc-2.9/sysdeps/unix/sysv/linux/i386/bits/fcntl.h
Et on trouve dans les deux fichiers des définitions de macros et de structures similaires. Sauf que pour la bionic ça ne serait pas normal mais pour la glibc oui ?
C'est quoi le problème alors ? Que pour bionic ça a été fait automatiquement ?
Donc pour suivre le raisonnement de ce cher Monsieur, la GPL du kernel va se propager à la glibc qui va se propager à n'importe quelle application tournant sur Linux. Cool, je veux les sources d'Oracle.
Aucun doute, un beau troll bien vellu du vendredi.
(Les sources de la glibc s'obtiennent via git ici : http://www.gnu.org/software/libc/ )
[^] # Re: Petite comparaison entre bionic et glibc
Posté par 태 (site web personnel) . Évalué à 4.
Non, la différence est que les contributeurs du kernel ont accepté que les headers de la glibc soient LGPL (parce que c'est comme ça que ça se passe).
Par contre, ils n'ont jamais accepté que ces headers soient réutilisés dans du code sous BSD. Google se permet de le faire car elle (il ? google est de quel sexe ?) estime que ce code ne peut être soumis au droit d'auteur, donc ne peut être soumis à une licence comme la GPL ou la LGPL.
[^] # Re: Petite comparaison entre bionic et glibc
Posté par Nelis (site web personnel) . Évalué à 6.
En même temps, copyrighter des headers je trouve ça limite dans le sens où ça défini l'interface, pas une implémentation. Rien que pour une raison d'interopérabilité ça n'a pas de sens.
[^] # Re: Petite comparaison entre bionic et glibc
Posté par Franck V . Évalué à 3.
Apparemment c'est aussi l'opinion de la FSF:
http://lkml.indiana.edu/hypermail/linux/kernel/0301.1/0362.html
[^] # Re: Petite comparaison entre bionic et glibc
Posté par 태 (site web personnel) . Évalué à 2.
D'après Florian Mueller, il y a justement de fonctions inline dans le code copié.
[^] # Re: Petite comparaison entre bionic et glibc
Posté par Antoine . Évalué à 2.
Tu oublies le « with substantial bodies ».
[^] # Re: Petite comparaison entre bionic et glibc
Posté par 태 (site web personnel) . Évalué à 2.
Non, je l'associe (en toute mauvaise foi) uniquement aux macros.
[^] # Re: Petite comparaison entre bionic et glibc
Posté par Franck V . Évalué à 2.
Si c'est vrai, qu'est ce qui empêcherai google de reprendre les headers de la glibc (donc sous LGPL) dans leur propre code ?
[^] # Re: Petite comparaison entre bionic et glibc
Posté par Éric (site web personnel) . Évalué à 0.
Hum, j'avoue que je n'en sais rien mais c'est la première fois que j'entends que les contributeurs du kernel auraient donné une exception de licence à la glibc. Ca m'étonne un peu. De ce que j'en avais compris la glibc n'avait aucun droit de plus ou de moins qu'un autre soft au niveau légal. Tu as des sources claires là dessus ?
[^] # Re: Petite comparaison entre bionic et glibc
Posté par pasScott pasForstall . Évalué à -1.
Non, ca voudrait dire que n'importe quelle appli non gpl ne serait plus distribuee pour linux. Les devs ont generalement choisi autre chose que la gpl pour une bonne raison et bien souvent prefereaient ne pas distribuer que distribuer sous GPL.
C'est bien evidemment du gros n'importe quoi, un bon vieux troll du vendredi qui surfe sur la vague du mobile.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
# Moi, j'inclue pas de headers C en Java
Posté par Moogle . Évalué à 3.
Le SDK Android est en Java. La majeure partie des applications disponibles sous Android sont codées en Java. A moins de passer par des appels bas niveau avec JNI, je n'aurais jamais à inclure le moindre fichier .h dans mes programmes Android. Ça fait tomber un peu toute l'argumentation à l'eau, ou je me plante ?
(C'est une vraie question que je me pose)
# du grand delire
Posté par Albert_ . Évalué à 2.
Voici la reponse de Linus sur le sujet:
http://www.groklaw.net/article.php?story=20110322014831856
Et aussi
http://lwn.net/
On pourra noter:
Way back in the early days of Linux, shortly after Linus Torvalds switched the kernel from his own "non-commercial" license to the GPL, he also added an important clarification to the kernel's license. In the COPYING file at the top of the kernel tree since mid-1993, there has been a clear statement that Torvalds, at least, does not consider user-space programs to be derived from the kernel, and thus are not subject to the kernel's license:
This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work".
Florian Muller est bien connu pour etre une sorte de pbpg en plus connu et plus fudeur (et plus fudeur). Il ne faut pas tenir compte de ses avis. Il doit lance un FUD contre linux et le logiciel libre par semaine.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.