En fait il y a un passage pour les profanes et les non juristes : l'intention de loi :
La transposition stricte de la directive, objet du titre Ier du présent projet de loi, ne nécessite que des modifications très limitées du code de la propriété intellectuelle. Il s’agit essentiellement, d’une part, de l’introduction de sanctions en cas de contournement des mesures techniques de protection et d'identification des ½uvres et, d’autre part, de l’institution d’une exception au droit d'auteur en faveur de certains types de copies techniques effectuées lors des transmissions de contenus sur les réseaux numériques.
Pour faire court, les modification de la loi relative au droit d'auteur sont là pour
1) permettre de taper sur les dispositifs de contournement de protection lorsqu'ils sont appliqués a des oeuvres protégées par le droit d'auteur (Donc rien a voir avec le DMCA qui tape sur le dispositif de contournement lui-même)
2) Permettre de taper sur les dispositifs qui empêchent ou masquent l'identification d'une oeuvre. Là c'est un peu plus grave, et n'étant pas juriste je ne comprend pas trop la portée de cette loi. Mais manifestement faire du peer to peer via des tuyeaux cryptés semble compromis. Il y a déjà des lois très forte contre le plagiat et l'usurpation en France, donc ca ne peut pas être juste pour empecher qu'une oeuvre soit publiée par une personne se faisant passer pour l'auteur mais ne l'étant pas.
3) Définir une exception à ce droit pour l'échange de doccuments via les réseaux numériques.
Ca, ca me gène beaucoup, ca tend a vouloir dire qu'une oeuvre protégée par le droit d'auteur (donc une oeuvre, soyons clair le domaine public est passionant mais souvent peu présent sur internet) n'a pas le droti de transiter par un réseau numérique en dehors d'un cadre bien défini et exceptionel.
Bref c'est d'une clareté aveuglante, de celles que l'on ne trouve qu'au plus profond d'Erebes.
Ah, OK excuse moi, tu parles une langue qui ressemble a la mienne, amsi qui repose sur une semantique qui m'est entrangère.
Dans la phrase "Lorsqu'il faut le changer" en réponse à "Dans quel cas faut-il recompiler un noyau ?". Je comprend il faut recompiler le noyau quand on change de noyau. Parceque sinon dire qu'il faut recompiler le noyau quand on veut changer des paramètres et des réglages du noyeau je ne vois pas l'interet.
Pour la question 6 a)
a)Sachant qu'un nouveau driver ne demande pas de changer de noyau, faut-il recompiler un noyau ?
la réponse reste parfois oui si on prend changer au sens auquel je l'ai pris (a savoir utiliser un autre noyau) et est non si on le prend au sens ou tu semble le prendre (a savoir faire des modifications et des reglages au sein d'un même noyau). Effectivement si on ne change rien dun un kernel donné il faudrait être bien abruti pour le recompiler (à la limite recompiler les modules parcequ'on les a corrompus je comprend, mais le kernel entier...)
En d'autres termes, quand on n'a besoin de toucher a rien, il n'y a pas besoin de mettre les maisn dans le cambouis.
Si c'est le sens que tu donnais a tes phrases je te prie de m'excuser de mon entrée dans le troll et de mon attitude un peu agressive. Mais cependant même si "ce qui va sans dire va encore mieux en le disant", là on est quand même en plein dans les lapalissades...
En ce qui concerne ta définition de patch, je en met pas en doute sa validité, je dis juste que la plupart des gens que je connais on tendance a remplacer les fichiers plutot qu'à les patcher passé un certains pourcentage de divergence... Donc patcher du 3.1 en 2000 ....
L'exception de certains modules est due à la nature non-dérivée de leur code vis à vis du kernel, car porté à partir d'un autre OS (e.g. drivers Nvidia).
Tu peux avoir des modules non dérivés même si non portés depuis un autre OS. a GPL dit explicitement que les travaux que l'on peut raisonablement considéré comme indépendant n'ont pas à être en GPL si ils sont distribués séparément.
Ca n'est pas uen fleur faite pas les dev du kernel, c'ets la GPL.
La question est donc de savoir si le driver PCWX est indépendant du kernel ou si c'est un travail dérivé.
NB : il faut monter en version et passer à Win 98.
Ou donc changer de système. A noter qu'avec ta définition ultralarge de "patcher" on peut aussi patcher Win95 en linux 2.6.8 et le tour est joué.
A noter encore que quand on patche on ne recompile pas le même noyau, on en compile un nouveau...
qui comme tout le monde sait n'a rien à voir avec le driver TRALALA de Red Hat de l'exercice 3)
Tout le monde c'est toi ? Ou bien je me suis planté d'univers en me levant ce matin ?
a) Lorsqu'il faut le changer
b) Lorsqu'on ne le change pas
MWAHAHAHA....
Bon tu me diras je t'ai poussé a la faute, masi celle là elle est belle quand même.
Alors voila j'ai un PC avec 1Go de ram, mon kernel qui peut supporter jusqu'à 64Go de ram a été compilé avec une option qui ne gére pas la ram au delà d'1Go. J'ai envie de mettre 4Go de ram sur mon PC, devine comment je vais faire pour résoudre ce problème sans changer ni mon système ni mon kernel ....
Et je te laisse déduire de l'exemple précédent les réponses a la question 6 a).
Pour la 6 b) je te conseille les *BSD ou même le Hurd ou éventuellement QNX dans lesquelles il existe une version bianire du noyeau que quasiment personen ne touche. Pour me faire bien comprendre : il y a compilation du noyau par les équipes concernés mais jamais REcompilation d'un même noyau (ou presque).
Ceci étant ta definition de recompilation étant aussi farfelue que celle de patch....
La GPL n'autorise pas d'avoir un module binaire car il s'agit de code dérivé
Non La GPL n'autorise pas d'avoir un module binaire livré avec le code GPL QUAND il s'agit de code dérivé.
Bon ceci étant aparament le pilote propio faisait massivement appels aux fonctions USB du kernel d'après Andrew Morton. Et dans ce cas là crack il y a violation de licence.
Par contre ce qui me chagirne c'est que le code a été enlevé d'abord dans une guerre d'egos et que la faute a été trouvée après (et manifestement a demandé a Andrew pas mal de temps).
Faudrait savoir. S'il est l'égal, pourquoi il faut le modifier alors ?
Je suis impatient de connaitre ta réponse.
Ben j'attend toujours celel de greg donc...
Apparament Linus aurait déclaré que l'on ne faisait pas de hook dans le kernel seulement pour des binaires proprios. Pour que le hook existe et reste il fallait qu'il y ait aussi des applis GPL qui utilisent ce hook. Et comme pour le hook de PWC il n'y a que PWCX qui l'utilise, paf dehors...
Le problème est que Linus a dit en fait qu'il ne fallait pas rajouter de hook au kernel seulement pour un binaire proprio, or le hook en question n'a pas été rajouté récamment (du moins après les paroles de Linus) mais bien avant...
Quand a la légalité du truc elle est inconnu vu que c'est justement en faisant l'audit des exports que les devs sont tombés la dessus. En fait ils l'ont giclé avant de l'auditer...
Allez pour le fun. Il est beau ce trol ca serait dommage qu'il meure :
Exercice 1 :
Soit windows 95 ne voit pas le périph du tout et le discarde au quel cas uen recompilation ne servirait a rien, un changement d'architecture s'impose pour supporter la gamme SATA, soit windows 95 voit le périph, son IRQ et ses zones mémoires auquel cas un pilote peut-être écrit qui prenne en charge le périph (éventuellement en s'aidant d'un wrapper vers SCSI)
Réponse : Non, recompiler le kernel ne servira a rien.
Exercice 2
Si windows 98 est capable de reconnaitre et de faire fonctionner du SATA sans l'intervention de microsoft, on peut en déduire que windows 98 n'a pas besoin d'être recompilé. Dans le cas ou il faille uen version modifiée du kernel pour que ca marche cf première partie de la réponse a l'exercice 1.
Réponse : Non, recompiler le kernel ne servira a rien.
Exercice 3
Comme RHEL assure la compatibilité binaire entre les versions. Si la versions 01/2004 ne supporte pas des périphs que la version 01/2005 supporte celà ne peut que vouloir dire que le pilote ne supporte pas la modularisation. La prise en charge de TRALALA nécessite donc de la part de Red Hat l'activation dans le kernel de la bonen option pour le support de TRALALA.
Réponse : Oui, une activation dans le kernel d'une nouvelle option et la recompilation du kernel ont été necessaire pour le support de TRALALA
Exercice 4
On sait que le pilote de TRALALA n'est pas modularisable, au moins en environement RHEL (cf exercice 3). la fourniture du pilote en binaire n'apporte donc rien, a mois qu'il ne s'agise d'un patch binaire du noyau RHEL3 update 3. Suposons que la probabilité du patch binaire est nulle. On se retrouve donc dasn le cas de l'exercice 3
Réponse : Oui, mais la recompilation a déjà été effectuée par Red Hat (cf exercice 3).
Exercice 5
Sous Windows il ne faut jamais recompiler une noyau, la prise en charge de nouveaux périphs impliquent un changement d'architecture ou un ajout de code. Une simple recompilation n'ammenera probablement nulle part. Celà s'explique par le fait que le noyau windows n'a pas d'options de prise en charge pilote désactivés.
Sous Linux la recompilation du noyeau est necessaire a cause du système de pilotes intégrés au noyau, pour tous les pilotes non modularisables (comme ceux vu dans les exercice 3 et 4).
Exercice 6
a) Oui si le pilote en question n'est pas modularisable et que l'option n'a pas été activée en première compil. Non dans les autres cas.
b) Non, deux noyaux différents peuvent être compatibles vis a vis des pilotes même si ce cas n'a pas été vu en exercice. Dans cette optique un module pour un noyau peut être transposer dans un autre.
Par contre prennez une distribution bien supporté type RHEL et là vous aurez 5 ans d'api absolument stable et aussi la compatibilité avec la version N-1.
En 5 ans, la gestion de mémoire a complètement changé 2 fois, la gestion de périphs a complètement changé, la gestion des modules a complètement changé, le support VesaFB a été mis au ban puis remplacé par directFB en user space puis remis pour debug only.
Le protocole X a grandement évoulé, notament au niveau des methodes de chargement et d'affichage des bitmaps et de la gestion des extensions. Les TTYs on changé, les pseudos TTYs ont changés aussi. Les Files Sytem ont évolués dans des proportions dantesques. La gestion de l'IDE en a pris plein la tête. Les threads ont complètements changés.
Et là je parle seulement du fondamental, parceque si il fallait aller jeter un oeuil sur les libs plus haut niveau ca serait la fête.
Alors de deux choses l'une : soit RHEL tourne sur un noyau 2.2.12 ou inférieur, soit ils ont codés tellement de wrappers en kernel space que leur noyau explose les 100Mos soit tu racontes n'importe quoi.
Il reste quoi en "incontrôlable" => le noyau.
Ce n'est pas le bout du monde.
Euh.... Si ?
Parceque le noyau c'est la base. Le noyau peut peter l'esemble des APIs quand il veut. Un changement de droit et paf il faut reprendre tous les programmes a aller ajouter les modifs qui vont bien....
Je croyais que les droits d'auteurs étaient inalienables ?!?
Ils le sont, il reste toujours l'auteur du code. Par contre le fait de faire ceci le sort des contributeurs du noyau. C'est juste un problème de decorum dans le noyau. Ca ne change rien a ses droits sur le code.
Pas du tout, le fichier en GPL (ie le pilote PWC) est parfaitement légal et ne pose aucun problème. C'est juste que le hook qu'il créé a été retiré parcqu'il était utilisé seulement par un binaire propriétaire.
On ne parle pas d'un modules séparé (quoique maintenant il a été viré Linux :-)).
Et bien ci, PCWX (le binaire proprio) est séparé.
Pour le reste, je suis fatigué.
Menteur, je viens de lire ton troll contre PBPG, tu tiens plutôt la forme...
le seul moyen de savoir si on est en dérivation ou pas est à mon avis de croire l'auteur :)
Pas du tout. Ca a d'ailleurs été le but de l'audit de Linux. Grosso modo charger un plug-in, le laisser s'executer et lui envoyer les infos qu'il demande sans les avoir traitées par une logique en GPL permet au plug-in et au programme de garder les licences qu'ils veulent.
Ensuite les trucs qui existent depuis longtemps (Posix par exemple), pour lesquels il existe dans le programme une logique en GPL, peuvent être utilisés par des programmes non GPL (On a pas la spécificité du code GPL, là c'ets juste l'implémentation d'une norme)
Pour finir les trucs qui ont une logique GPL spécifique, mais qui sont obligatoires et n'apportent rien au programme (Gestion de mémoire virtuelle pour un programme qui fait juste des allocations/libérations, file system pour un programme qui utilise l'API pour créer/déplacer/détruire des fichiers) ne compte pas non plus et on peut les appeler depuis du non GPL.
Par contre créer un demi module non GPL qui utilise de la logique spécifique en GPL est interdit.
du code GPL peut-il charger des trucs propriétaires ? (je pense notamment aux codecs)
Grosso-modo, si tu as deux programmes un en GPL et l'autre pas, ils ont le droit d'interagir ensemble si et seulement si les seuls fonctions qu'un des programmes appelle chez l'autre sont des fonctions de
- chargement en mémoire
- notification de présence/ d'éxecution
- demande d'accès a des données ou des flux sous forme brute (ie sans que la logique de l'autre programme ne les ait mis en forme, execpetion faite des cas ou cette mise en forme est necessaire au fonctionnement (par exemple l'adressage virtuel de mémoire fait par un kernel))
- ou des fonctions standards définies hors du programme (RFC, POSIX, X Protocol etc.)
Donc si un programme GPL appelle chez un programme non GPL de la logique qui ne rempli pas les conditions ci dessus il y a faute. Même chose si un programme propriétaire ne remplit pas les même conditions.
Pour simplifier encore la formulation : tant que deux programmes n'apellent pas la logique spécifique de l'autre ils peuvent raisonablement être considérés comme indépendants. Et donc tant qu'on ne les distribue pas ensemble on a le droit d'en avoir un seul des deux en GPL.
Mais le fond, c'est à dire l'origine de cette décision, me semble tout de meme provenir, du moins indirectement, d'un problème de compatibilité de licence. Parce que si le truc proprio n'aurait pas constitué un travail dérivé, alors il n'y aurait pas eu besoin effacer le hook, non ?
C'est ce qui m'ennuie. Soit le hook est effacé pour un problème de licence mais je ne vois pas lequel et les demandes qui fusent sur le flame de la LKML aident pas vraiment. Soit il a été retiré parcequ'un des mainteneurs interprete une phrase de Linus qui dit : "Pas de hook pour du propriétaire seul." Le fait de se charger dans le l'espace mémoire d'une autre appli et de s'y executer ne constitue pas de facto une violation de la GPL. Il faut encore que le programme ainsi chargé fasse appel a des fonctions spécifiques du programme chargeant. Or là j'ai un peu de mal a voir le coté "spécifique Linux" du binaire, surtout que les algos utilisés on été écrit a la base pour Windows et Mac.
D'un autre coté je n'ai pas la certitude non plsu que le binaire en question ne fasse pas un appel un peu trop spécifique suite au modifs. mais j'aimerais juste qu'on me dise lequel dans ce cas là...
Par contre ce contre quoi je me bats personellement dans ce long threads c'est juste les personnes qui déclarent : "Ca linke du GPL sans être soit même en GPL donc il y a forcément violation."
Parceque ca n'est pas vrai (même si dans 99% des cas ca se vérifie.)
Ca aurait du te suffire pour te convaincre qu'on parle bien ici d'un travail dérivé.
Et non...
Le fait d'intégrer un module (binaire ou non) dans un programme ou dans une lib ne fait pas du module un produit dérivé.
Typiquement si je créé un editeur de texte que j'apelle totoEdit et que je place sous GPL, et que dans cet éditeur de texte je créé un système de plugins. Maintenant un autre programmeur aime bien certaines fonctionnalités de mon éditeur (comme le broswer et les joulies icones) mais pas du tout l'interface de saisie, et il décide de créer mod_vi_bsd parcequ'il aime bien la version BSD de vi. mais comme c'est un mechant vilain pas beau, il ne distribue pas le code source et fait payer les autres pour ce plug-in (ce que la licence BSD permet)
Ben déjà je vais avoir du mal a prétendre que vi devient un travail dérivé de totoEdit (genre beaucoup même), je pense même que si j'essaye on va violamment se fiche de moi.
Ensuite si le mec qui a utilisé mon système de plugins pour changer l'interface de sasie n'utilise que des appels non spécifiques à mon appli (genre utiliser ma trappe a évènements) et bien il ne violera même pas la GPL. Il suffit juste qu'il ne distribue pas l'ensemble appli+plug-in sur le même support...
Le gros problème est cic de savoir quand il dépasse la limite en faisant un appel a une fonction qui est trop aprticulière a mon prog pour qu'on puisse encore raisonablement considérer son travail comme indépendant... Là c'est le hic.
Dans le cas qui nous interresse les mecs qui ont filés les specs pour faire pwcx en avait rien a faire de Linux, il est donc très probable qu'aucun algo dans ce qu'ils ont filé ne soit spécifique Linux. A partir de la si tout ce que fait le module binaire c'est de se charger en mémoire kernel et d'acceder en direct au la webcam, normalement il ne viole pas non plus la GPL...
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à....
Au contraire, la LKML montre clairement que la propreté est du coté de la suppression de tout code de transformation de format du kernel space, et la transposition vers le user space.
Mais je suis tout a fait d'accord avec celà. Seulement il y a des fois ou ca n'est pas possible. Dans le cas présent il faut remonter des informations du kernel space (pilote V4L) et de l'User space (lancement de gnome meeting dans une certaine résolution, en overlay a une certaine vitesse) directement vers le device pour le réinitialiser comme il faut...
Ne pas se coller en kernel space, voudrait dire laisser une appli user space acceder directement a un périphérique. Tout le problème est là, le code d'initialisation de la webcam était sous NDA....
Parce que les modules proprio, ils ont le droit de se servir que de choses d'API bien définies, si ils ne font pas ca les modules ils deviennent travail dérivé du noyau et donc sous GPL ou rien.
Oui mais là encore c'est un peu plus complexe, les accès direct au matériel sont authorisés dans une certaine mesure qui varien en fonction du dit matériel. On ne pourra jamais avoir un accès direct a de la ram alors qu'un accès direct au disque dur pose peu de problèmes. Mais dans le cas de la webcam, c'est un accès direct non pas a la webcam, mais au port USB... Donc il y a problème. Ceci étant ce problème a été considéré comme négligeable pendant 3 ans. Et c'est définitvement pas parceque les mainteneurs du kernel ne l'avait pas vu...
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...
1) stand alone ?? en dehors du noyeau ? L'un sans l'autre ?
Ca change rien.
Ca change tout, parceque si il peut fonctionner sans utiliser le noyeau (ce qu'il fait déjà, mais bon) ca veut dire qu'on peut quand même raisonablement le considérer comme indépendant. Par suite si il est distribué séparément du noyeau, il n'a pas a se soumettre a la GPL et c'est de ca qu'on parle.
2) Non.
Le propriétaire est simplement toléré dans le noyeau sous certaines conditions.
Le propriétaire, ou les licenses non compatibles sont authorisées a utilsier des programmes GPL sous reserve que "l'on puisse raisonablement le considerer comem indépendant". Je veux bien que l'on m'explique que cette condition n'est pas ou plus satisfaite pour pwcx, mais que l'on ne vienne pas parler de tolérance : c'est dans le texte de la GPL !
Ben deja utiliser nux ca pénalise les users à la base. Faut commencer a comprendre que nux c'est aussi la GPL, pas simplement un superbe noyeau sur lequel tout le monde peut linker un module sous n'importe quelle licence.
Une fois de plus la GPL présente une option qui peut être remplie par des modules sous n'importe quelle license.
Qu'est ce qui jusitifie que les spec d'une webcam ne soit pas publiques
A priori pas grand chose. Les formats de couleur et de compression sont pour la plupart connus. Un mémlange de NDA croisés et d'accord tacites j'imagine.
(note on ma déjà fait le coup avec les CG et j'y ai meme cru à moitié pendant 5 minutes ;)
Si c'est a un de mes posts précédent que tu fais référence, je susi désolé que ca n'ait pas marché plus de 5 minutes...
C'est un autre problème dans la mesure ou contrairement a ATI et Nvidia, pwcx peut fonctionner avec un feed raw qui ne vient pas du noyeau, et peut de fait être considéré comme raisonablement indépendant. Le gros problème c'est que pour faire ca ca implique de passer l'initialisation de la webcam en userspace et de faire un trou de sécurité dans le kernel pour qu'il laisse l'appli aller taper le hardware directement.
En fait la seule chose que fait le hook de pwc c'est de permettre a pwcx de "voir" le flux de données vidéos au travers du kernel et d'initialiser la camera dans un mode ou un autre.
Après on peut partir dans de grands debats sur ce que "raisonablement indépendant" veut dire dans les faits, mais très sincèrement une appli qui ne fait que demander un moyen d'acceder directement au matériel, non pas en utilisant les fonctions du kernel mais en passant au travers, rentre définitivement dans la définition.
Alors tes gentils, mais va apprendre la difference entre GPL et LGPL et revient dire tes conneries après.
Bon ben je vais en dire une dernière quand même.
Le kernel est en GPL, c'est le seul à gerer les accès a la mémoire physique. Donc toutes les applis qui tuilsent les APIs du kernel pour obtenir une allocation mémoire (en kernel ou en userspace) sont donc soit en GPL, soit sont des exceptions. (La LGPL n'a pas le droit de lier la GPL)
Donc toutes les applis qui fonctionnent sous Linux sont soit en GPL soit tirent parti d'une exception d'une appli ou d'un bibliothèque en dessous d'elles.
Le truc c'est que c'est bien des exceptions, mais pas du tout des entorses a la GPL, mais une non application ou une application parteilel de la protection contre les éléments non GPL. Et ces exceptions sont présente dans la GPL : These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.
La clef c'est can be reasonably considered independent Si on considére que d'utiliser des bibliothèques GPL bas niveau d'un système c'est mettre son programme sous GPL, alors aucun programme en peut être raisonablement considéré comme indépendant.
Le terme Bibliothèques standard te gène peut-être. Remplaçons le par "bibliothèques fondamentales". Et dans ce cas de même qu'un programme GPL sous windows peut faire appel a l'API win32 (et heureusement), un programme non GPL sous Linux peut allouer de la mémoire (et heureusement aussi, il y a pas de raison.)
En ce qui concerne readline, la Glibc, la libc ou QT les remarques du thread sont tout a fait valables, mais parce que ce sont des bibliothèques et des applis de trop haut niveau.
Oui mais le monsieur ce qu'il voudrait c'est une dérogation sur mesure à la GPL.
Il n'ay a AUCUNE dérogation a la GPL a fournir un hook qui permet un accés direct au matériel. Et il n'y a aucne derogation a la GPL a ce qu'un modules ou une appli propriétaire utilise ce hook.
Les applis propriétaires ont le droit d'utiliser les API et les appels fondamentaux du système. Prétendre le contraire revient a dire qu'un programme non GPL n'a pas le droit de demander une allocation mémoire physique.
En ce qui concerne l'argument du kernel space/ User space c'ets très simple on a deux solutions :
- Soit on se permet de lancer des bribes d'applicatifs en kernel space et c'est pas très propre.
- Soit on place les accès direct hardware et les inits de périphs en user space et là c'est carrément immonde et en plus ca fait un trou de sécurité assez grand pour y fourrer Jupiter et tous ses satellites.
Ça marche si le noyau est proprio et le driver GPL. Mais là, c'est l'inverse.
Mince, il va falloir le dire a NVidia, Connexant, ATI et pleins d'autres.
Le noyau est plus "inhérent au système" qu'un driver.
Dans un kernel monolithique, ca me ferait un peu mal.... Tu savais que la gestion mémoire par exemple c'était un driver ?
De toute facon je peux lier une appli complètement propriétaire aux bibliothèques standards en GPL. Et ca tombe un peu bien d'ailleurs, parceque sinon pour faire du proprio sur Linux il faudrait y aller franco...
Le fait d'utiliser les APIs standards, les bibliothèques standards ou les appels standards d'un système ne peut pas constituer une violation de la GPL. Si ca n'était pas le cas on ne pourrait soit pas écrire de programmes GPL sous des OS propriétaires, soit pas écrire de programmes propriétaires sous des OS GPL.
Et pourquoi un drivers linux est plus dur a dévelloper qu'un drivers windows ??? (c'est une vrai question :)
Disons que c'est a la fois complètement vrai et totalement faux. Pour developper un module linux il suffit 9 fois sur 10 de reprendre 3 bouts de codes a d'autres modules et de changer les déclarations ainsi que l'enregistrement.
Le plus dur est souvent de savoir quel appel système sert a quoi et ensuite derrière c'est du velour.
Par contre Linux n'est pas stable au niveau des interfaces. Tant au niveau du noyeau (en ce moment par exemple c'est la fête a l'IDE) que de l'environement de compilation ou encore que des bibliothèques. Bref parti pour écrire un module on se retrouve souvent a en ecrire 10, subtilement différents ou a faire des automakes de 100 pieds de long pour que les APIs linux fonctionnent (OSS -> Alsa, XFree86 -> X.org, lpr-> gimp print, Defvfs -> Udev etc.)
Généralement quand on met une équipe réduite sur un driver Linux un peu baleze (Une carte d'aquisition temps réel, pour prendre un exemple que je connais) on a pas le temps de finir les specs qu'on peut déjà les mettre a la poubelle. En bref sous Linux on a le droit a grand maximum 8 mois pour faire l'ensemble pilote/interfaces/outils. Et après on est bon pour le maintenir 24h/24 au gré des variations subtiles de la gestion des registres et des appels mémoires.
Mossieu ne veut pas diffuser son module hors du noyau parce que le projet de mossieu serait considéré comme un projet de second plan...
Le Mossieu vient d epasser trois ans de sa vie a ecrire patch sur patch et a faire demandes sur demandes au dev du kernel pour que telle ou telle fonction soit prise en compte/authorisée/réactivée. Le mossieur il en a pris pleins les dents sur la mailing liste et dans les faits pendant qu'il s'occupait d'un module de premier plan. On lui a peter son module cinq ou six fois au cours des dernières années dont au moins deux fois exprès. Alors le mossieur il veut même pas savoir ce que ca ferait de continuer le même boulot en etant considéré par les devs de premier plan comme accessoire, de seconde zone, facultatif.
Et moi le Mossieur je le comprend un peu au moins sur ce plan là.
[^] # Re: Ce serait encore mieux avec un lien sur ladite proposition
Posté par Jerome Herman . En réponse à la dépêche Réforme du droit d'auteur : motivation et traduction législative. Évalué à 10.
La transposition stricte de la directive, objet du titre Ier du présent projet de loi, ne nécessite que des modifications très limitées du code de la propriété intellectuelle. Il s’agit essentiellement, d’une part, de l’introduction de sanctions en cas de contournement des mesures techniques de protection et d'identification des ½uvres et, d’autre part, de l’institution d’une exception au droit d'auteur en faveur de certains types de copies techniques effectuées lors des transmissions de contenus sur les réseaux numériques.
Pour faire court, les modification de la loi relative au droit d'auteur sont là pour
1) permettre de taper sur les dispositifs de contournement de protection lorsqu'ils sont appliqués a des oeuvres protégées par le droit d'auteur (Donc rien a voir avec le DMCA qui tape sur le dispositif de contournement lui-même)
2) Permettre de taper sur les dispositifs qui empêchent ou masquent l'identification d'une oeuvre. Là c'est un peu plus grave, et n'étant pas juriste je ne comprend pas trop la portée de cette loi. Mais manifestement faire du peer to peer via des tuyeaux cryptés semble compromis. Il y a déjà des lois très forte contre le plagiat et l'usurpation en France, donc ca ne peut pas être juste pour empecher qu'une oeuvre soit publiée par une personne se faisant passer pour l'auteur mais ne l'étant pas.
3) Définir une exception à ce droit pour l'échange de doccuments via les réseaux numériques.
Ca, ca me gène beaucoup, ca tend a vouloir dire qu'une oeuvre protégée par le droit d'auteur (donc une oeuvre, soyons clair le domaine public est passionant mais souvent peu présent sur internet) n'a pas le droti de transiter par un réseau numérique en dehors d'un cadre bien défini et exceptionel.
Bref c'est d'une clareté aveuglante, de celles que l'on ne trouve qu'au plus profond d'Erebes.
Kha
[^] # Re: Relis ca phrase
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Dans la phrase "Lorsqu'il faut le changer" en réponse à "Dans quel cas faut-il recompiler un noyau ?". Je comprend il faut recompiler le noyau quand on change de noyau. Parceque sinon dire qu'il faut recompiler le noyau quand on veut changer des paramètres et des réglages du noyeau je ne vois pas l'interet.
Pour la question 6 a)
a)Sachant qu'un nouveau driver ne demande pas de changer de noyau, faut-il recompiler un noyau ?
la réponse reste parfois oui si on prend changer au sens auquel je l'ai pris (a savoir utiliser un autre noyau) et est non si on le prend au sens ou tu semble le prendre (a savoir faire des modifications et des reglages au sein d'un même noyau). Effectivement si on ne change rien dun un kernel donné il faudrait être bien abruti pour le recompiler (à la limite recompiler les modules parcequ'on les a corrompus je comprend, mais le kernel entier...)
En d'autres termes, quand on n'a besoin de toucher a rien, il n'y a pas besoin de mettre les maisn dans le cambouis.
Si c'est le sens que tu donnais a tes phrases je te prie de m'excuser de mon entrée dans le troll et de mon attitude un peu agressive. Mais cependant même si "ce qui va sans dire va encore mieux en le disant", là on est quand même en plein dans les lapalissades...
En ce qui concerne ta définition de patch, je en met pas en doute sa validité, je dis juste que la plupart des gens que je connais on tendance a remplacer les fichiers plutot qu'à les patcher passé un certains pourcentage de divergence... Donc patcher du 3.1 en 2000 ....
Kha
[^] # Re: Les faits, rien que les faits...
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 1.
Tu peux avoir des modules non dérivés même si non portés depuis un autre OS. a GPL dit explicitement que les travaux que l'on peut raisonablement considéré comme indépendant n'ont pas à être en GPL si ils sont distribués séparément.
Ca n'est pas uen fleur faite pas les dev du kernel, c'ets la GPL.
La question est donc de savoir si le driver PCWX est indépendant du kernel ou si c'est un travail dérivé.
Kha
[^] # Re: Relis ca phrase
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Ou donc changer de système. A noter qu'avec ta définition ultralarge de "patcher" on peut aussi patcher Win95 en linux 2.6.8 et le tour est joué.
A noter encore que quand on patche on ne recompile pas le même noyau, on en compile un nouveau...
qui comme tout le monde sait n'a rien à voir avec le driver TRALALA de Red Hat de l'exercice 3)
Tout le monde c'est toi ? Ou bien je me suis planté d'univers en me levant ce matin ?
a) Lorsqu'il faut le changer
b) Lorsqu'on ne le change pas
MWAHAHAHA....
Bon tu me diras je t'ai poussé a la faute, masi celle là elle est belle quand même.
Alors voila j'ai un PC avec 1Go de ram, mon kernel qui peut supporter jusqu'à 64Go de ram a été compilé avec une option qui ne gére pas la ram au delà d'1Go. J'ai envie de mettre 4Go de ram sur mon PC, devine comment je vais faire pour résoudre ce problème sans changer ni mon système ni mon kernel ....
Et je te laisse déduire de l'exemple précédent les réponses a la question 6 a).
Pour la 6 b) je te conseille les *BSD ou même le Hurd ou éventuellement QNX dans lesquelles il existe une version bianire du noyeau que quasiment personen ne touche. Pour me faire bien comprendre : il y a compilation du noyau par les équipes concernés mais jamais REcompilation d'un même noyau (ou presque).
Ceci étant ta definition de recompilation étant aussi farfelue que celle de patch....
Kha
[^] # Re: Les faits, rien que les faits...
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Non La GPL n'autorise pas d'avoir un module binaire livré avec le code GPL QUAND il s'agit de code dérivé.
Bon ceci étant aparament le pilote propio faisait massivement appels aux fonctions USB du kernel d'après Andrew Morton. Et dans ce cas là crack il y a violation de licence.
Par contre ce qui me chagirne c'est que le code a été enlevé d'abord dans une guerre d'egos et que la faute a été trouvée après (et manifestement a demandé a Andrew pas mal de temps).
Mais bon.
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Je suis impatient de connaitre ta réponse.
Ben j'attend toujours celel de greg donc...
Apparament Linus aurait déclaré que l'on ne faisait pas de hook dans le kernel seulement pour des binaires proprios. Pour que le hook existe et reste il fallait qu'il y ait aussi des applis GPL qui utilisent ce hook. Et comme pour le hook de PWC il n'y a que PWCX qui l'utilise, paf dehors...
Le problème est que Linus a dit en fait qu'il ne fallait pas rajouter de hook au kernel seulement pour un binaire proprio, or le hook en question n'a pas été rajouté récamment (du moins après les paroles de Linus) mais bien avant...
Quand a la légalité du truc elle est inconnu vu que c'est justement en faisant l'audit des exports que les devs sont tombés la dessus. En fait ils l'ont giclé avant de l'auditer...
Kha
[^] # Re: Relis ca phrase
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 3.
Exercice 1 :
Soit windows 95 ne voit pas le périph du tout et le discarde au quel cas uen recompilation ne servirait a rien, un changement d'architecture s'impose pour supporter la gamme SATA, soit windows 95 voit le périph, son IRQ et ses zones mémoires auquel cas un pilote peut-être écrit qui prenne en charge le périph (éventuellement en s'aidant d'un wrapper vers SCSI)
Réponse : Non, recompiler le kernel ne servira a rien.
Exercice 2
Si windows 98 est capable de reconnaitre et de faire fonctionner du SATA sans l'intervention de microsoft, on peut en déduire que windows 98 n'a pas besoin d'être recompilé. Dans le cas ou il faille uen version modifiée du kernel pour que ca marche cf première partie de la réponse a l'exercice 1.
Réponse : Non, recompiler le kernel ne servira a rien.
Exercice 3
Comme RHEL assure la compatibilité binaire entre les versions. Si la versions 01/2004 ne supporte pas des périphs que la version 01/2005 supporte celà ne peut que vouloir dire que le pilote ne supporte pas la modularisation. La prise en charge de TRALALA nécessite donc de la part de Red Hat l'activation dans le kernel de la bonen option pour le support de TRALALA.
Réponse : Oui, une activation dans le kernel d'une nouvelle option et la recompilation du kernel ont été necessaire pour le support de TRALALA
Exercice 4
On sait que le pilote de TRALALA n'est pas modularisable, au moins en environement RHEL (cf exercice 3). la fourniture du pilote en binaire n'apporte donc rien, a mois qu'il ne s'agise d'un patch binaire du noyau RHEL3 update 3. Suposons que la probabilité du patch binaire est nulle. On se retrouve donc dasn le cas de l'exercice 3
Réponse : Oui, mais la recompilation a déjà été effectuée par Red Hat (cf exercice 3).
Exercice 5
Sous Windows il ne faut jamais recompiler une noyau, la prise en charge de nouveaux périphs impliquent un changement d'architecture ou un ajout de code. Une simple recompilation n'ammenera probablement nulle part. Celà s'explique par le fait que le noyau windows n'a pas d'options de prise en charge pilote désactivés.
Sous Linux la recompilation du noyeau est necessaire a cause du système de pilotes intégrés au noyau, pour tous les pilotes non modularisables (comme ceux vu dans les exercice 3 et 4).
Exercice 6
a) Oui si le pilote en question n'est pas modularisable et que l'option n'a pas été activée en première compil. Non dans les autres cas.
b) Non, deux noyaux différents peuvent être compatibles vis a vis des pilotes même si ce cas n'a pas été vu en exercice. Dans cette optique un module pour un noyau peut être transposer dans un autre.
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 4.
En 5 ans, la gestion de mémoire a complètement changé 2 fois, la gestion de périphs a complètement changé, la gestion des modules a complètement changé, le support VesaFB a été mis au ban puis remplacé par directFB en user space puis remis pour debug only.
Le protocole X a grandement évoulé, notament au niveau des methodes de chargement et d'affichage des bitmaps et de la gestion des extensions. Les TTYs on changé, les pseudos TTYs ont changés aussi. Les Files Sytem ont évolués dans des proportions dantesques. La gestion de l'IDE en a pris plein la tête. Les threads ont complètements changés.
Et là je parle seulement du fondamental, parceque si il fallait aller jeter un oeuil sur les libs plus haut niveau ca serait la fête.
Alors de deux choses l'une : soit RHEL tourne sur un noyau 2.2.12 ou inférieur, soit ils ont codés tellement de wrappers en kernel space que leur noyau explose les 100Mos soit tu racontes n'importe quoi.
Il reste quoi en "incontrôlable" => le noyau.
Ce n'est pas le bout du monde.
Euh.... Si ?
Parceque le noyau c'est la base. Le noyau peut peter l'esemble des APIs quand il veut. Un changement de droit et paf il faut reprendre tous les programmes a aller ajouter les modifs qui vont bien....
Kha
[^] # Re: pwc vs pwcx
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Ils le sont, il reste toujours l'auteur du code. Par contre le fait de faire ceci le sort des contributeurs du noyau. C'est juste un problème de decorum dans le noyau. Ca ne change rien a ses droits sur le code.
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Pas du tout, le fichier en GPL (ie le pilote PWC) est parfaitement légal et ne pose aucun problème. C'est juste que le hook qu'il créé a été retiré parcqu'il était utilisé seulement par un binaire propriétaire.
On ne parle pas d'un modules séparé (quoique maintenant il a été viré Linux :-)).
Et bien ci, PCWX (le binaire proprio) est séparé.
Pour le reste, je suis fatigué.
Menteur, je viens de lire ton troll contre PBPG, tu tiens plutôt la forme...
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Pas du tout. Ca a d'ailleurs été le but de l'audit de Linux. Grosso modo charger un plug-in, le laisser s'executer et lui envoyer les infos qu'il demande sans les avoir traitées par une logique en GPL permet au plug-in et au programme de garder les licences qu'ils veulent.
Ensuite les trucs qui existent depuis longtemps (Posix par exemple), pour lesquels il existe dans le programme une logique en GPL, peuvent être utilisés par des programmes non GPL (On a pas la spécificité du code GPL, là c'ets juste l'implémentation d'une norme)
Pour finir les trucs qui ont une logique GPL spécifique, mais qui sont obligatoires et n'apportent rien au programme (Gestion de mémoire virtuelle pour un programme qui fait juste des allocations/libérations, file system pour un programme qui utilise l'API pour créer/déplacer/détruire des fichiers) ne compte pas non plus et on peut les appeler depuis du non GPL.
Par contre créer un demi module non GPL qui utilise de la logique spécifique en GPL est interdit.
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Grosso-modo, si tu as deux programmes un en GPL et l'autre pas, ils ont le droit d'interagir ensemble si et seulement si les seuls fonctions qu'un des programmes appelle chez l'autre sont des fonctions de
- chargement en mémoire
- notification de présence/ d'éxecution
- demande d'accès a des données ou des flux sous forme brute (ie sans que la logique de l'autre programme ne les ait mis en forme, execpetion faite des cas ou cette mise en forme est necessaire au fonctionnement (par exemple l'adressage virtuel de mémoire fait par un kernel))
- ou des fonctions standards définies hors du programme (RFC, POSIX, X Protocol etc.)
Donc si un programme GPL appelle chez un programme non GPL de la logique qui ne rempli pas les conditions ci dessus il y a faute. Même chose si un programme propriétaire ne remplit pas les même conditions.
Pour simplifier encore la formulation : tant que deux programmes n'apellent pas la logique spécifique de l'autre ils peuvent raisonablement être considérés comme indépendants. Et donc tant qu'on ne les distribue pas ensemble on a le droit d'en avoir un seul des deux en GPL.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
C'est ce qui m'ennuie. Soit le hook est effacé pour un problème de licence mais je ne vois pas lequel et les demandes qui fusent sur le flame de la LKML aident pas vraiment. Soit il a été retiré parcequ'un des mainteneurs interprete une phrase de Linus qui dit : "Pas de hook pour du propriétaire seul." Le fait de se charger dans le l'espace mémoire d'une autre appli et de s'y executer ne constitue pas de facto une violation de la GPL. Il faut encore que le programme ainsi chargé fasse appel a des fonctions spécifiques du programme chargeant. Or là j'ai un peu de mal a voir le coté "spécifique Linux" du binaire, surtout que les algos utilisés on été écrit a la base pour Windows et Mac.
D'un autre coté je n'ai pas la certitude non plsu que le binaire en question ne fasse pas un appel un peu trop spécifique suite au modifs. mais j'aimerais juste qu'on me dise lequel dans ce cas là...
Par contre ce contre quoi je me bats personellement dans ce long threads c'est juste les personnes qui déclarent : "Ca linke du GPL sans être soit même en GPL donc il y a forcément violation."
Parceque ca n'est pas vrai (même si dans 99% des cas ca se vérifie.)
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Et non...
Le fait d'intégrer un module (binaire ou non) dans un programme ou dans une lib ne fait pas du module un produit dérivé.
Typiquement si je créé un editeur de texte que j'apelle totoEdit et que je place sous GPL, et que dans cet éditeur de texte je créé un système de plugins. Maintenant un autre programmeur aime bien certaines fonctionnalités de mon éditeur (comme le broswer et les joulies icones) mais pas du tout l'interface de saisie, et il décide de créer mod_vi_bsd parcequ'il aime bien la version BSD de vi. mais comme c'est un mechant vilain pas beau, il ne distribue pas le code source et fait payer les autres pour ce plug-in (ce que la licence BSD permet)
Ben déjà je vais avoir du mal a prétendre que vi devient un travail dérivé de totoEdit (genre beaucoup même), je pense même que si j'essaye on va violamment se fiche de moi.
Ensuite si le mec qui a utilisé mon système de plugins pour changer l'interface de sasie n'utilise que des appels non spécifiques à mon appli (genre utiliser ma trappe a évènements) et bien il ne violera même pas la GPL. Il suffit juste qu'il ne distribue pas l'ensemble appli+plug-in sur le même support...
Le gros problème est cic de savoir quand il dépasse la limite en faisant un appel a une fonction qui est trop aprticulière a mon prog pour qu'on puisse encore raisonablement considérer son travail comme indépendant... Là c'est le hic.
Dans le cas qui nous interresse les mecs qui ont filés les specs pour faire pwcx en avait rien a faire de Linux, il est donc très probable qu'aucun algo dans ce qu'ils ont filé ne soit spécifique Linux. A partir de la si tout ce que fait le module binaire c'est de se charger en mémoire kernel et d'acceder en direct au la webcam, normalement il ne viole pas non plus la GPL...
Kha.
[^] # 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
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 4.
Mais je suis tout a fait d'accord avec celà. Seulement il y a des fois ou ca n'est pas possible. Dans le cas présent il faut remonter des informations du kernel space (pilote V4L) et de l'User space (lancement de gnome meeting dans une certaine résolution, en overlay a une certaine vitesse) directement vers le device pour le réinitialiser comme il faut...
Ne pas se coller en kernel space, voudrait dire laisser une appli user space acceder directement a un périphérique. Tout le problème est là, le code d'initialisation de la webcam était sous NDA....
Parce que les modules proprio, ils ont le droit de se servir que de choses d'API bien définies, si ils ne font pas ca les modules ils deviennent travail dérivé du noyau et donc sous GPL ou rien.
Oui mais là encore c'est un peu plus complexe, les accès direct au matériel sont authorisés dans une certaine mesure qui varien en fonction du dit matériel. On ne pourra jamais avoir un accès direct a de la ram alors qu'un accès direct au disque dur pose peu de problèmes. Mais dans le cas de la webcam, c'est un accès direct non pas a la webcam, mais au port USB... Donc il y a problème. Ceci étant ce problème a été considéré comme négligeable pendant 3 ans. Et c'est définitvement pas parceque les mainteneurs du kernel ne l'avait pas vu...
Kha
[^] # 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.
[^] # Re: alternatives ?
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Ca change rien.
Ca change tout, parceque si il peut fonctionner sans utiliser le noyeau (ce qu'il fait déjà, mais bon) ca veut dire qu'on peut quand même raisonablement le considérer comme indépendant. Par suite si il est distribué séparément du noyeau, il n'a pas a se soumettre a la GPL et c'est de ca qu'on parle.
2) Non.
Le propriétaire est simplement toléré dans le noyeau sous certaines conditions.
Le propriétaire, ou les licenses non compatibles sont authorisées a utilsier des programmes GPL sous reserve que "l'on puisse raisonablement le considerer comem indépendant". Je veux bien que l'on m'explique que cette condition n'est pas ou plus satisfaite pour pwcx, mais que l'on ne vienne pas parler de tolérance : c'est dans le texte de la GPL !
Ben deja utiliser nux ca pénalise les users à la base. Faut commencer a comprendre que nux c'est aussi la GPL, pas simplement un superbe noyeau sur lequel tout le monde peut linker un module sous n'importe quelle licence.
Une fois de plus la GPL présente une option qui peut être remplie par des modules sous n'importe quelle license.
Qu'est ce qui jusitifie que les spec d'une webcam ne soit pas publiques
A priori pas grand chose. Les formats de couleur et de compression sont pour la plupart connus. Un mémlange de NDA croisés et d'accord tacites j'imagine.
(note on ma déjà fait le coup avec les CG et j'y ai meme cru à moitié pendant 5 minutes ;)
Si c'est a un de mes posts précédent que tu fais référence, je susi désolé que ca n'ait pas marché plus de 5 minutes...
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
C'est un autre problème dans la mesure ou contrairement a ATI et Nvidia, pwcx peut fonctionner avec un feed raw qui ne vient pas du noyeau, et peut de fait être considéré comme raisonablement indépendant. Le gros problème c'est que pour faire ca ca implique de passer l'initialisation de la webcam en userspace et de faire un trou de sécurité dans le kernel pour qu'il laisse l'appli aller taper le hardware directement.
En fait la seule chose que fait le hook de pwc c'est de permettre a pwcx de "voir" le flux de données vidéos au travers du kernel et d'initialiser la camera dans un mode ou un autre.
Après on peut partir dans de grands debats sur ce que "raisonablement indépendant" veut dire dans les faits, mais très sincèrement une appli qui ne fait que demander un moyen d'acceder directement au matériel, non pas en utilisant les fonctions du kernel mais en passant au travers, rentre définitivement dans la définition.
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Bon ben je vais en dire une dernière quand même.
Le kernel est en GPL, c'est le seul à gerer les accès a la mémoire physique. Donc toutes les applis qui tuilsent les APIs du kernel pour obtenir une allocation mémoire (en kernel ou en userspace) sont donc soit en GPL, soit sont des exceptions. (La LGPL n'a pas le droit de lier la GPL)
Donc toutes les applis qui fonctionnent sous Linux sont soit en GPL soit tirent parti d'une exception d'une appli ou d'un bibliothèque en dessous d'elles.
Le truc c'est que c'est bien des exceptions, mais pas du tout des entorses a la GPL, mais une non application ou une application parteilel de la protection contre les éléments non GPL. Et ces exceptions sont présente dans la GPL :
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.
La clef c'est can be reasonably considered independent Si on considére que d'utiliser des bibliothèques GPL bas niveau d'un système c'est mettre son programme sous GPL, alors aucun programme en peut être raisonablement considéré comme indépendant.
Le terme Bibliothèques standard te gène peut-être. Remplaçons le par "bibliothèques fondamentales". Et dans ce cas de même qu'un programme GPL sous windows peut faire appel a l'API win32 (et heureusement), un programme non GPL sous Linux peut allouer de la mémoire (et heureusement aussi, il y a pas de raison.)
En ce qui concerne readline, la Glibc, la libc ou QT les remarques du thread sont tout a fait valables, mais parce que ce sont des bibliothèques et des applis de trop haut niveau.
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 10.
Il n'ay a AUCUNE dérogation a la GPL a fournir un hook qui permet un accés direct au matériel. Et il n'y a aucne derogation a la GPL a ce qu'un modules ou une appli propriétaire utilise ce hook.
Les applis propriétaires ont le droit d'utiliser les API et les appels fondamentaux du système. Prétendre le contraire revient a dire qu'un programme non GPL n'a pas le droit de demander une allocation mémoire physique.
En ce qui concerne l'argument du kernel space/ User space c'ets très simple on a deux solutions :
- Soit on se permet de lancer des bribes d'applicatifs en kernel space et c'est pas très propre.
- Soit on place les accès direct hardware et les inits de périphs en user space et là c'est carrément immonde et en plus ca fait un trou de sécurité assez grand pour y fourrer Jupiter et tous ses satellites.
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à -1.
Mince, il va falloir le dire a NVidia, Connexant, ATI et pleins d'autres.
Le noyau est plus "inhérent au système" qu'un driver.
Dans un kernel monolithique, ca me ferait un peu mal.... Tu savais que la gestion mémoire par exemple c'était un driver ?
De toute facon je peux lier une appli complètement propriétaire aux bibliothèques standards en GPL. Et ca tombe un peu bien d'ailleurs, parceque sinon pour faire du proprio sur Linux il faudrait y aller franco...
Le fait d'utiliser les APIs standards, les bibliothèques standards ou les appels standards d'un système ne peut pas constituer une violation de la GPL. Si ca n'était pas le cas on ne pourrait soit pas écrire de programmes GPL sous des OS propriétaires, soit pas écrire de programmes propriétaires sous des OS GPL.
Kha
[^] # Re: pas cool :/
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 7.
Disons que c'est a la fois complètement vrai et totalement faux. Pour developper un module linux il suffit 9 fois sur 10 de reprendre 3 bouts de codes a d'autres modules et de changer les déclarations ainsi que l'enregistrement.
Le plus dur est souvent de savoir quel appel système sert a quoi et ensuite derrière c'est du velour.
Par contre Linux n'est pas stable au niveau des interfaces. Tant au niveau du noyeau (en ce moment par exemple c'est la fête a l'IDE) que de l'environement de compilation ou encore que des bibliothèques. Bref parti pour écrire un module on se retrouve souvent a en ecrire 10, subtilement différents ou a faire des automakes de 100 pieds de long pour que les APIs linux fonctionnent (OSS -> Alsa, XFree86 -> X.org, lpr-> gimp print, Defvfs -> Udev etc.)
Généralement quand on met une équipe réduite sur un driver Linux un peu baleze (Une carte d'aquisition temps réel, pour prendre un exemple que je connais) on a pas le temps de finir les specs qu'on peut déjà les mettre a la poubelle. En bref sous Linux on a le droit a grand maximum 8 mois pour faire l'ensemble pilote/interfaces/outils. Et après on est bon pour le maintenir 24h/24 au gré des variations subtiles de la gestion des registres et des appels mémoires.
Voilà pour la problématique.
Kha
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Jerome Herman . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 10.
Le Mossieu vient d epasser trois ans de sa vie a ecrire patch sur patch et a faire demandes sur demandes au dev du kernel pour que telle ou telle fonction soit prise en compte/authorisée/réactivée. Le mossieur il en a pris pleins les dents sur la mailing liste et dans les faits pendant qu'il s'occupait d'un module de premier plan. On lui a peter son module cinq ou six fois au cours des dernières années dont au moins deux fois exprès. Alors le mossieur il veut même pas savoir ce que ca ferait de continuer le même boulot en etant considéré par les devs de premier plan comme accessoire, de seconde zone, facultatif.
Et moi le Mossieur je le comprend un peu au moins sur ce plan là.
Kha