L'auteur me semble ignorer un peu comment fonctionne un système complet kernel + userspace.
Par exemple:
Note that the text mentions libc, which is a different library than glibc. It's BSD-licensed. Bionic is based on libc, and the header files with the above notice are added to Bionic.
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.
The GPL's copyleft nature requires all derivative works of a GPL'd program to be made available on the same terms. Google, however, very intentionally publishes Android as a multi-license potpourri of
* GPL'd software (the Linux kernel),
* permissively-licensed open source software (programs under open source licenses such as the Apache Software License or BSD/MIT licenses, which don't come with copyleft), such as the Dalvik virtual machine (which is at the heart of Oracle's lawsuit), and
* closed-source programs.
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.
# Est-ce un Troll?
Posté par Damien Thébault . En réponse au journal Et si Android était en fait libre. É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.