• [^] # Re: euhh ... mainteneurs oupsss ?

    Posté par . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 6.

    Bon alors voila je vais t'expliquer calmement.
    Soit tu utilise des appels systèmes, distants, RPC, un protocole, etc, ... et il n'y a pas de link donc on ne pas prétendre à un travail dérivé. Donc pas de problème.

    Soit tu te met à linker des truc proprio avec des lib GPL, et tu violes alors la GPL en beauté (et accessoirement 500 personnes vont te tomber dessus, ta boite mail va etre explosée par des protestations, et un voodoo va te jeter un sort)

    Soit tu link le plus légalement du monde avec de la LGPL.

    Il n'y a pas énorment de lib bas niveau en GPL, justement pour qu'on puisse faire des appli proprio

    Tu parles de biblio std mais LA biblio std est en LGPL et pour ta gouverne il s'agit de la libc.

    Il n'y a rien en dessous de la libc, si ce n'est une API par appel système, et non pas une API par appel de fonctions tournant dans le meme user space.

    Donc on a le droit de faire des appels systèmes au noyau, quelque soit les 2 licences (du noyau et de l'appli)

    PAR CONTRE

    On a pas le droit de linker un truc avec le noyau, qui soit pas sous GPL
    SAUF, si il utilise des fonctions qui ont été considérées comme une interface bien determinée, ne générant pas un travail dérivé.

    J'avoue avoir parlé incorrectement d'exception, car en général une exception c'est l'autorisation d'utiliser une partie proprio avec une partie libre sous GPL. On considère qu'il y a travail dérivé.

    La l'API permettant de linker en kernel space ne fait meme pas considéré qu'il y a travail dérivé. C'est heureux car sinon il devrait y avoir une autorisation par module proprio.

    Par contre le hook du gas est là pour brancher un travail qu'on ne peut que définir par travail dérivé, donc ca à disparu, et c'est normal.