A mon sens, ca n'est pas vraiment un problème GPL. Il y a peut_être un rpob GPl, mais les différents flames et autres trolls qui ont encombré la mailing liste du kernel de nombreuses fois ne viennent pas d'un problème GPL.
Il a un code sous GPL il appèle un truc non GPL. C'est tout.
En fait il a du code GPL qui lui ouvre un tuyeau vers le periph en direct sans passer par le kernel. C'est bien le problème. ce n'est pas tant une exception a la GPl, qu'une exception au kernel qui ouvre grand les portes pour laisser passer un module fermé.
Et puisse que tu cites le copying.modules, je te renvois a uen discussion assez passionante sur le kernel trap qui défini assez bien pourquoi un driver non GPL peut parfaitement être appelé/chargé par le noyau sans qu'il y est la moindre infraction a la GPL...
Basically:
- anything that was written with Linux in mind (whether it then _also_ works on other operating systems or not) is clearly partially a derived work.
- 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.
Par M Linus lui même.
Le problème dans le cas qui nous interresse est que 1) PWCX n'utilise pas les fonctions standard du kernel, il utilise une fonction spécifique pour pouvoir paser au travers du kernel pour les accès périphs, par contre il utilise une connection USB via le kernel donc il est sur la tangente. 2) Les algos de compression et de décompression ainsi que les initialisations diverses n'ont pas été faites spécifiquement pour Linux. Elle marcherait sous n'importe quel système pour peu qu'elles soient envoyés en direct sur le port USB, cependant ces algos ont étés portés sous Linux, notamment pour la compatibilité V4L...
Bref on a un truc qui est un poil entre deux chaises. Sans utiliser les fonctions du kernel, il profite quand même d'un accès port USB ouvert par le kernel, sans avoir été écrit pour Linux, il a été retouché de ci de là pour mieux s'integrer.
Le problème c'est déjà présenté une fois :
Historically, there's been things like the original Andrew filesystem module: a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. Is that derived just because it got ported to Linux that had a reasonably similar VFS interface to what other UNIXes did? Personally, I didn't feel that I could make that judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray area.
Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so.
Maintenant savoir si PWCX doit être considéré comme un travail dérivé ou non me passe très loin au dessus de la tête. Mon opinion perso est que non, et je ne pense pas que ce soit trivial...
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 1.
Il a un code sous GPL il appèle un truc non GPL. C'est tout.
En fait il a du code GPL qui lui ouvre un tuyeau vers le periph en direct sans passer par le kernel. C'est bien le problème. ce n'est pas tant une exception a la GPl, qu'une exception au kernel qui ouvre grand les portes pour laisser passer un module fermé.
Et puisse que tu cites le copying.modules, je te renvois a uen discussion assez passionante sur le kernel trap qui défini assez bien pourquoi un driver non GPL peut parfaitement être appelé/chargé par le noyau sans qu'il y est la moindre infraction a la GPL...
http://kerneltrap.org/node/view/1735/5354(...)
On y trouve notamment :
Basically:
- anything that was written with Linux in mind (whether it then _also_ works on other operating systems or not) is clearly partially a derived work.
- 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.
Par M Linus lui même.
Le problème dans le cas qui nous interresse est que 1) PWCX n'utilise pas les fonctions standard du kernel, il utilise une fonction spécifique pour pouvoir paser au travers du kernel pour les accès périphs, par contre il utilise une connection USB via le kernel donc il est sur la tangente. 2) Les algos de compression et de décompression ainsi que les initialisations diverses n'ont pas été faites spécifiquement pour Linux. Elle marcherait sous n'importe quel système pour peu qu'elles soient envoyés en direct sur le port USB, cependant ces algos ont étés portés sous Linux, notamment pour la compatibilité V4L...
Bref on a un truc qui est un poil entre deux chaises. Sans utiliser les fonctions du kernel, il profite quand même d'un accès port USB ouvert par le kernel, sans avoir été écrit pour Linux, il a été retouché de ci de là pour mieux s'integrer.
Le problème c'est déjà présenté une fois :
Historically, there's been things like the original Andrew filesystem module: a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. Is that derived just because it got ported to Linux that had a reasonably similar VFS interface to what other UNIXes did? Personally, I didn't feel that I could make that judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray area.
Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so.
Maintenant savoir si PWCX doit être considéré comme un travail dérivé ou non me passe très loin au dessus de la tête. Mon opinion perso est que non, et je ne pense pas que ce soit trivial...
kha.