Soit tu te met à linker des truc proprio avec des lib GPL, et tu violes alors la GPL en beauté
Pas du tout.
En fait il est extrèmement complexe de savoir si un code qui lie une appli GPL devient GPL ou non. C'est pour eviter cela que dans le kernel il y a désormais les EXPORT_SYMBOL_GPL. Celà donne uen bonne indication pour savoir si l'on est en train de plonger un peu trop dans le noyau. Grosso modo il y a eu un audit du code Linux et un certain nombre d'EXPORT_SYMBOL ont été changés en EXPORT_SYMBOL_GPL. Si on a besoin pour faire fonctionner son module de faire appel a des entrées qui ont été exportées par EXPORT_SYMBOL_GPL alor son peut être certain que le module DOIT passer en GPL. Par contre pour les EXPORT_SYMBOL ca n'est pas sur, peut-être que le code du module n'est pas obligé de passer en GPL.
On Thu, 4 Dec 2003, Jason Kingsland wrote:
> > - anything that has knowledge of and plays with fundamental internal
> > Linux behaviour is clearly a derived work. If you need to muck around
> > with core code, you're derived, no question about it.
>
>
> If that is the case, why the introduction of EXPORT_SYMBOL_GPL and
> MODULE_LICENSE()?
It is really just documentation.
This is exactly so that it is more clear which cases are black-and-white,
and where people shouldn't even have to think about it for a single
second. It still doesn't make the gray area go away, but it limits it a
bit ("if you need this export, you're clearly doing something that
requires the GPL").
Note: since the kernel itself is under the GPL, clearly anybody can modify
the EXPORT_SYMBOL_GPL() line, and remove the _GPL part. That wouldn't be
against the license per se. But it doesn't make a module that needs that
symbol any less needful of the GPL - exactly because the thing is just a
big cluehint rather than anything else.
Il n'y a pas énorment de lib bas niveau en GPL, justement pour qu'on puisse faire des appli proprio
Ben les appels du kernel sont bas niveau. Et c'est de celà que l'on parle prioritairement non ? Sinon je citerais les stdio et autres malloc/kalloc qui sont vraiment bas niveau.
Donc on a le droit de faire des appels systèmes au noyau, quelque soit les 2 licences (du noyau et de l'appli)
Tout a fait, quand on bosse en user space, on peut dificilement faire un travail dérivé du kernel. Donc la question ne se pose pas. Néamoins ca n'est pas le seul cas ou on a à faire à un travail qui en utilise un autre sans pour autant être un projet dérivé. Le problème se pose surtout quand on porte une application d'une plateforme quelconque vers une plateforme GNU. On peut dificilement considérer un programme comme un projet dérivé d'une lib si le programe existe depuis plus longtemps que la lib qu'il lie sous Linux.
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'imagine que tu fais allusion aux EXPORT_SYMBOL vu plus haut. dans ce cas je suis tout a fait avec toi, mais ca n'est pas une exception au kernel. Les fonctions qui existaient et etait normés bien avant Linux ou la GPL (maloc(), cat, vi, grep, ed, etc, free() et j'en passe ) ne passe pas en GPL si on les compile avec un lien vers une bibliothèque GPL. Il ne fait aucun doute que ce sont des travaux qui ne sont pas dérivés des librairies qu'ils linkent, et de fait tant qu'on les distribue séparément ils ne sont pas soumis a la GPL.
Par contre le hook du gars est là pour brancher un travail qu'on ne peut que définir par travail dérivé, donc ca à disparu, et c'est normal.
La je suis d'accord avec ton raisonement. Mais par contre je ne le suis pas avec tes hypothéses. Je ne vois pas en quoi la notion de travail dérivé est si évidente que celà....
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 3.
Pas du tout.
En fait il est extrèmement complexe de savoir si un code qui lie une appli GPL devient GPL ou non. C'est pour eviter cela que dans le kernel il y a désormais les EXPORT_SYMBOL_GPL. Celà donne uen bonne indication pour savoir si l'on est en train de plonger un peu trop dans le noyau. Grosso modo il y a eu un audit du code Linux et un certain nombre d'EXPORT_SYMBOL ont été changés en EXPORT_SYMBOL_GPL. Si on a besoin pour faire fonctionner son module de faire appel a des entrées qui ont été exportées par EXPORT_SYMBOL_GPL alor son peut être certain que le module DOIT passer en GPL. Par contre pour les EXPORT_SYMBOL ca n'est pas sur, peut-être que le code du module n'est pas obligé de passer en GPL.
On Thu, 4 Dec 2003, Jason Kingsland wrote:
> > - anything that has knowledge of and plays with fundamental internal
> > Linux behaviour is clearly a derived work. If you need to muck around
> > with core code, you're derived, no question about it.
>
>
> If that is the case, why the introduction of EXPORT_SYMBOL_GPL and
> MODULE_LICENSE()?
It is really just documentation.
This is exactly so that it is more clear which cases are black-and-white,
and where people shouldn't even have to think about it for a single
second. It still doesn't make the gray area go away, but it limits it a
bit ("if you need this export, you're clearly doing something that
requires the GPL").
Note: since the kernel itself is under the GPL, clearly anybody can modify
the EXPORT_SYMBOL_GPL() line, and remove the _GPL part. That wouldn't be
against the license per se. But it doesn't make a module that needs that
symbol any less needful of the GPL - exactly because the thing is just a
big cluehint rather than anything else.
Il n'y a pas énorment de lib bas niveau en GPL, justement pour qu'on puisse faire des appli proprio
Ben les appels du kernel sont bas niveau. Et c'est de celà que l'on parle prioritairement non ? Sinon je citerais les stdio et autres malloc/kalloc qui sont vraiment bas niveau.
Donc on a le droit de faire des appels systèmes au noyau, quelque soit les 2 licences (du noyau et de l'appli)
Tout a fait, quand on bosse en user space, on peut dificilement faire un travail dérivé du kernel. Donc la question ne se pose pas. Néamoins ca n'est pas le seul cas ou on a à faire à un travail qui en utilise un autre sans pour autant être un projet dérivé. Le problème se pose surtout quand on porte une application d'une plateforme quelconque vers une plateforme GNU. On peut dificilement considérer un programme comme un projet dérivé d'une lib si le programe existe depuis plus longtemps que la lib qu'il lie sous Linux.
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'imagine que tu fais allusion aux EXPORT_SYMBOL vu plus haut. dans ce cas je suis tout a fait avec toi, mais ca n'est pas une exception au kernel. Les fonctions qui existaient et etait normés bien avant Linux ou la GPL (maloc(), cat, vi, grep, ed, etc, free() et j'en passe ) ne passe pas en GPL si on les compile avec un lien vers une bibliothèque GPL. Il ne fait aucun doute que ce sont des travaux qui ne sont pas dérivés des librairies qu'ils linkent, et de fait tant qu'on les distribue séparément ils ne sont pas soumis a la GPL.
Par contre le hook du gars est là pour brancher un travail qu'on ne peut que définir par travail dérivé, donc ca à disparu, et c'est normal.
La je suis d'accord avec ton raisonement. Mais par contre je ne le suis pas avec tes hypothéses. Je ne vois pas en quoi la notion de travail dérivé est si évidente que celà....
Kha