Journal Et si Android était en fait libre

Posté par (page perso) . Licence CC by-sa
Tags :
8
18
mar.
2011

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 (page perso) . É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 . Évalué à  7 .

      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).

      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

      NOTE! 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".

      • [^] # Re: userland GPL et libc GPL ou non

        Posté par (page perso) . Évalué à  1 .

        that use kernel services by normal system calls

        Quand je dis tape directement c'est sans utiliser la voie normale ;)

        • [^] # Re: userland GPL et libc GPL ou non

          Posté par . É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 (page perso) . Évalué à  2 .

            http://lwn.net/Articles/394399/

            Normally, kernel developers see user space as a different world with its own rules; it is not at all common for kernel maintainers to insist on free licensing for user-space components. Dave's raising of licensing issues might also seem, on its face, to run counter to the above text: he is saying explicitly that closed user-space graphics drivers might be a work derived from the kernel and, thus, a violation of the GPL. These claims merit some attention.

            The key text above is "normal system calls." A user-space graphics driver does not communicate with its kernel counterpart with normal system calls; it will use, instead, a set of complex operations which exist only to support that particular chipset. The kernel ABI for graphics drivers is not a narrow or general-purpose interface. The two sides are tightly coupled, a fact which has made the definition of the interface between them into a difficult task - and the maintenance of it almost as hard. While a program using POSIX system calls is clearly not derived from the kernel, the situation with a user-space graphics driver is not nearly so clear.

      • [^] # Re: userland GPL et libc GPL ou non

        Posté par (page perso) . É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 . Évalué à  2 .

          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.

          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 (page perso) . Évalué à  -1 .

            A priori la glibc est sous LGPL pour éviter justement que le userland ne le devienne aussi.

            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 . Évalué à  -2 .

              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)

              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).

              Puis il y a l'exception "System libraries" dans la GPL et je doute qu'elle ne marche que dans un seul sens

              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 (page perso) . Évalué à  0 .

                Le juge 1) connaît mieux le droit d'auteur que toi 2) a moins de préjugés sur le sujet que toi.

                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.

                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.

                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 . Évalué à  5 .

                  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

                  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:

                  NOTE! 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"."
                  

                  C'est débile et indéfendable.

                  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 (page perso) . É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 (page perso) . Évalué à  -2 .

                    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.

                    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 . Évalué à  1 .

                      Ça va, tu peux te calmer...

                      Mon premier commentaire répondait à cette affirmation de ta part:

                      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)

                      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 (page perso) . É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 (page perso) . É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 (page perso) . É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 . Évalué à  4 .

        on parle de bionic en particulier, qui est distribué sous bsd.

      • [^] # Re: userland GPL et libc GPL ou non

        Posté par . É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 (page perso) . É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 . É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 (page perso) . É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 . É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 (page perso) . Évalué à  0 .

                  Du coup je ne pige plus l’intérêt de la LGPL dans ce cas particulier...

                  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 (page perso) . É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 :

      If Google is proven wrong, pretty much that entire software stack -- and also many popular third-party closed-source components such as the Angry Birds game and the Adobe Flash Player -- would actually have to be published under the GPL.
      

      J'ai lu quelques § de plus mais je n'ai pas encore trouvé d'explication.

  • # Est-ce un Troll?

    Posté par (page perso) . Évalué à  9 .

    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.

    • [^] # Re: Est-ce un Troll?

      Posté par . É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 (page perso) . É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 . É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 (page perso) . É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 (page perso) . Évalué à  4 .

      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 ?

      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 . Évalué à  -1 .

      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.

      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 . É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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.