Au dela des insultes, je crois qu'il voulait juste dire qu'on peut recompiler son noyau pour quelque raison que ce soit, ce qui est impossible avec le proprio et que donc certains point font qu'on peut guère critiquer nux en disant qu'on a pas assez le droit de faire ce qu'on veut sous cet OS.
Ceci étant il est tout a fait vrai qu'on peut faire des drivers proprio sous win, avec quasiment aucune limitation (je crois que la plus grande limitation est d'eviter de prétendre que c'est MS qui les a fait ou de ce faire de la pub associant MS au produit sans son accord en disant que ca dérive d'un code de MS du ddk, ce qui est assez permissif :), ce que l'on ne peut pas faire sous nux.
Les libertés dépandent de la vision des choses que l'on a, certain préfèrent le copyleft, d'autres trouvent que le copyleft restraint la liberté de faire du proprio. Les premier rétorques qu'interdire une restriction de la liberté n'est pas vraiment une perte de liberté, etc...
Quand a savoir si le copyleft doit s'appliquer dans ce cas précis de driver de webcam (et donc le hook enlevé), cela dépand "juste" du statut du module proprio : dérivation de linux ou pas ? le reste ("ouin ca marchait pendant 3 ans, maintenant ca marche plus") n'a pas vraiment d'importance si il s'avère que la suppression du hook etait indispensable pour preserver la liberté de nux, fusse au dépend du nombre d'utilisateurs.
Bon j'essaie de mettre toutes les idées a plat et j'en suis venu à la conclusion suivante : le seul moyen de savoir si on est en dérivation ou pas est à mon avis de croire l'auteur :)
Sinon on en revient toujours au meme point : dans un soft ou il existe un système de plugin, imagine un type qui met, disons dans le fichier définissant l'interface des plug'ins, toutes les fonctions du code dans des wrappers, et distribue cette modif sous GPL.
Il peut ensuite bien tranquillement coder en dérivant le soft sans le dériver :p
Et si on lui dit "euh, t'es bien gentil, mais ton truc est dépendant du bidule GPL, donc met le sous GPL ou arrete de le distribuer", ben il lui suffit de reimplementer toutes les fonctions utilisées pour qu'elles fassent le moins de chose possible tout en permettant à son truc proprio de faire semblant de fonctionner, ou alors pour faire un truc qui a completement rien à voir...
J'ai bien l'impression qu'ici c'est de ca dont il s'agit : en standalone le truc du gars il sert à rien, et le type avait rajouté un hook dans le noyau rien que pour son truc proprio.
Donc on est bien obligé de croire les gars du noyau quand ils disent : le proprio c'est cet API et pas une autre. Sinon c'est la porte ouverte à toutes les dérivations masquées. Genre un noyau linux GPL rempli de hook qui font tous des appels à un truc proprio pour supporter une nouvelle archi... Et pour justifier la non dépendance, des programmes qui appelent les fonctions propriétaire pour utiliser certains algorithme d'une autre manière, ou carrement un système de test complet...
Alors, possible ou pas ? Faut-il violer consciemment la volontée des auteurs de linux, qui est de ne pas utiliser autre chose qu'un certain ensemble de fonction quand on est proprio, et si oui est-il légal de le faire ? Ont-ils clairement auparavent stipulés qu'ils ne souhaitent pas que des bidules proprio se chargent sans passer par l'interface officielle ? Le chargement du controlleur proprio de la webcam oubliait-il opportunnement de pourrir le noyau ?
Hm, zut t'as totalement raison. J'avais mal interprété l'entête de la 2), mais en la relisant plusieurs fois j'ai capté. Et dire que je croyais bien connaitre la GPL... Arf comme quoi on en apprend tous les jours !
En même temps qu'en j'y repense c'est mieux comme ca. J'ai été tellement habitué aux lois liberticides et aux copyright plus que fermé de partout que j'ai même plus l'habitude de penser à faire strictement ce que je veux chez moi, snif... !
Bon pour en revenir au module proprio de la webcam, il faut voir si se ne serait pas un travail dérivé de sa modif GPL du noyau (donc un travail dérivé du noyau en bref), ce qui constiturait une violation nan ?
Parce que si l'on ne considère pas cette possibilité, alors il n'y aurait aucun problème à diffuser un prog non compatible GPL capable d'utiliser Readline, et on sait bien que ce n'est pas possible. Donc ya forcement un truc.
Si tu ne précise pas dans ta licence que l'utilisation de ton API pour les plug'in ne constitue pas un travail dérivé, le type il pourra certe écrire un plugin non compatible GPL, mais du coup personne pourra l'utiliser, puisque la combinaison du tout violerait la GPL.
La clef de ton exemple est une précision dans la licence: l'utilisation de tel ensemble de fonction ne constitue pas un travail dérivé. Sinon personne ne peut le deviner.
Maintenant si quelqu'un fait un patch qui modifie ton logiciel (pas juste faire un plugin) pour rajouter une fonction et que cette fonction est utilisée pour charger du code proprio, je doutes que le chargement du code proprio qui ne passe pas par l'API que tu avais autorisé pour les travaux non dérivés soit très catholique.
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 ?
Là ce qui clochait en fin de compte c'était que à cause du fait que le truc proprio utilise le hook, il se transformait (illégalement) en travail dérivé. C'est ce que semble penser Greg KH.
On en revient un peu au meme point, c'est à dire est-ce qu'il faut laisser un type écrire un patch pour creer un hook dans une partie de gestion matérielle de nux (usb, ieee1394, pci, etc..) afin de satisfaire ses besoins de pilote proprio. Et si il ne faut pas alors soit il s'agit de limite légales (c'est ce qui est dit sur la LKML par Greg KH : Think legal limits, not arbitrary.) soit le mec il peut continuer à écrire des patchs qui recraient le hook et à se moment là son retrait est juste une question d'ego.
(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...
Ah c'etait toi ? :)
Ben en fait j'y crois plus qu'à 25 % là :p
Je ne prétend pas que ce que tu disais était impossible. J'en suis arrivé à un point ou j'attend simplement de voir. Or il ne me sera surrement pas donné de voir un driver de CG proprio dans ma vie, donc à mon d'aller bosser chez NVidia pour en faire, ce que je ne souhaite pas, je ne peux que supposer que ca dévoilerait beaucoup trop d'info ou non. Et je penche dans la balance de "ca pourrait devoiler quelques info interressantes, mais rien de crucial vis à vis des connaissances à peu près aussi étendu du concurrent".
Je considère aussi un echange technologique simultanné (qui si je reste réaliste ne se produira certes jamais) et je me demande ce que ca donnerait si il était mis en place par ouverture simultané des sources des deux cotés.
Là j'avoues que je vais un peu trop loin dans mes rêves utopiques :)
N'oublie pas que la GPL régit aussi ce qui tourne en run time.
Sinon ca serait trop la rave, suffirait de faire des modules dynamiques qui se chargent dans 3 appli différentes pour pouvoir faire n'importe quoi.
Ca ne peut marcher que si les hooks du run time sont autorisé initialement. Un contributeur ne peut pas venir changer la licence et dire "tient, je rajoute un bout de code, et je dit que l'appel de cette fonction ne generera pas de travail dérivé".
Sinon il suffit d'encapsuler toutes les fonctions dans des hooks définis par le contributeur comme travail dérivé pour pouvoir linker du GPL libre avec du proprio, sans controle des interfaces et en integration totale. D'ou par l'absurde la conclusion que rajouter un petit hook personel pour pouvoir linker son petit truc proprio dans le kernel est impossible. Et c'est bien de ca qu'on parle ! Le fait qu'il est aussi possible que pwcx fasse aussi le café en user space ni change absolument RIEN.
* you are going to accept that there is a driver in the Linux kernel that
has a hook that _may_ be used to load a binary-only decompressor part into
the kernel, at the user's disgression. Maybe, one day, that part will be
open source too but I cannot guarantuee that.
Ca aurait du te suffire pour te convaincre qu'on parle bien ici d'un travail dérivé.
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.
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. C'est la nouvelle "mode" a ceci près qu'elle est on ne peut plus justifiée, notemment en matière de sécu (n'importe quel bof ou autre bug en kernel space est suceptible de deboucher sur un exploit ouvrant la porte du root). Quand au hook il n'etait utilisé que pour chargé un _module_ proprio et il a donc tout normalement été viré.
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. C'est pas moi qui le dit c'est les kernel hacker. Et cet API elle est pas défini par le premier quidam venu, sinon je fais un module GPL wrapper qui encapsule TOUS les appels à TOUTES les fonctions du noyau, et pis apres bien tranquilement je déclare que je suis dieu et que cet API peut etre utilisée pour linké des modules proprio qui font ce qu'ils veulent.
Bah, cet article décrit le lot de tous les débutants qui ne connaissent pas encore le système.
exemple : Linux didn't like my new flat-panel screen and insisted on unusable low resolutions. Much wasted time and online answer seeking (back in Windows) eventually saw 1280 x 1024 pixels again.
Alors que Linux n'en a rien a foutre des pixels d'un ecran. Second exemple : linux (sous entendu la distri, cet interpreation reglant aussi mon problème existanciel de noyaux et de pixels à l'écran :) ) te file plein de prog mais ils ne sont pas toujours compatible avec TOUS les autres prog qui font plus ou moins la meme chose. Euh, il veut pas 100 balles et un mars aussi ? :)
D'une manière générale, migrer juste parce que on en a marre de IE risque d'être une bien mauvaise idée pour pas mal de monde, il faut une motivation bien plus grande.
Et quand on a la motivation on ne rechigne pas a lire des docs pendants plusieurs heures pour faire marcher sa machine, pour ensuite l'oublier presque totalement pendant plusieurs années et ce concentrer sur son travail.
Mais le gas qui a déjà un win tout beau avec tous ses constructeurs de matos qui se sont acharnés a faire tout fonctionner d'une manière ou d'une autre, et qui se dit : tient IE sux, je vais tester nux, ben c'est sûr qu'il va passer à coté de 99% du système et s'arreter sur des détails de cosmétiques, ou d'incompatibilité qui vont simplement lui faire dire "linux ca suxe mon gadget XXXYYYZZZ il marche pas". De meme pour les fous furieux de matos à la mode et de gadgets, je vois pas trop ce qu'ils gagnerait à utiliser nux (sauf si ils sont fan de logiciel libre bien sur).
Ce qu'on apprend donc de cet article c'est que 1) un OS est difficile à installer (même win peut l'être parfois quand on a pas l'habitude ou quand on a du matos plus récent que sa version de win). 2) il faut etre motiver pour utilisé nux autrement que par "euh, IE ca sux grave". 3) Les applis ne sont pas toutes magiquement compatible entre elles parce qu'on est pas dans alice au pays des merveilles non plus. 4) plein de monde cherchent le système parfait et quand ils se rendent compte qu'il existe pas c'est la désilusion. Vu que "Will I give up Windows altogether? Probably. The more I use Linux, the better I like it despite the challenges. It hasn't crashed; it's immune to Windows viruses; it won't fall victim to spyware, worms or hackers;" le gas a pas encore entammé sa phase de désilusion et ferait bien d'aller trainer du coté des sites de sécu pour voir que du coté du libre comme ailleurs, les programmes parfaits du premier coup n'existent pas :)
D'après ce que j'ai vu autour de moi, soit il retournera sous win, surrement en utilisant pas mal de logiciel libre d'ailleurs, soit il sera entrainé dans une spirale de maitrise technique et philosophique du système :) En tout cas personellement j'ai jamais vu personne administrant leur propre machine de stable à long terme sous nux qui ne soit pas bien mieux informé sur la technique et la philo (sans forcement rentrer trop profondement dans les détails style programmation) qu'à ses débuts.
Rien de bien nouveau dans tout ca donc...
Un dernier commentaire sur le journal cette fois : Pourquoi cet article? Parce que pour une fois il montre les avantages et inconvénients de Linux. Si vous le lisez, il y a de fortes chances que ça vous ne vous donnes pas envie de passer maintenant à Linux, mais plus tard peut-être...
Passer de win à nux à toujours été remis à PLUS TARD par beaucoup de monde et risque de le rester eternellement si l'on se contente d'attendre que 100% des chose que l'on fait sous win sont aussi faisable sous nux. Par contre en observant plus finement les 2 systèmes on se rend compte qu'on est pas dans une situation d'inclusion mais de recouvrement partiels des usages, cad on peut faire plein de trucs sous nux et pas sous win, et inversement. Sans compter que des fois le fait de ne pas pouvoir faire quelque chose sur un des 2 os n'est pas vraiment génant vu les différences qui existent.
Passer à nux ce fait soit tout de suite, soit ne se fait jamais, ou alors pas de manière stable, ce qui est encore plus dangereux en matière "marketing" (deceptions, incompréhension fondamental du modèle de devel du style "oh les gens du kernel ils sont méchant du coup le gas qui faisait marcher les cam phillips il est parti, c'est pas bien pour les pauvres utilisateurs", ...)
Mais oui, moi je vais recupéré le code source de win2k, le dériver et distribuer le tout sous BSD, et quand MS va venir avec la police pour que je me calme je vais ecrire des page oueb comme quoi c'est des vilains mechant casse couille et ca va donner une mauvaise image de la communauté Microsoft.
Le mec il peut toujours demandé ca, mais ya pas de droit de repentir en matière de logiciel.
Donc les mainteneur peuvent (et vont surrement) ne pas accepter.
Y a rien qui les obligent à accepter. Sont truc est libre, n'importe qui peut le REdistribuer, meme si il choisit d'arreter de le distribuer.
Escuse moi d'etre violent mais le coup du "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..." c'est TROP pour moi
Alors tes gentils, mais va apprendre la difference entre GPL et LGPL et revient dire tes conneries après. Va aussi lire le coup de RMS qui a dit a je sais plus qui de passer son soft utilisant readline sous GPL ou d'arreter d'utiliser readline si tes pas bien convaincu.
Avant de vouloir parler d'un truc, faut ptet etre au courant avant, non mais !
Hm de toute facon, quand bien même tu aurais raison, le but de nux c'est pas de dominer toute la planette et d'etre sur tous les PC du monde. Si les gens jouent et font de l'im et qu'ils se rendent compte que linux est pas fait pour eux pour quelque raison que ce soit, ils utiliseront win et ca n'a rien de choquant.
Maintenant si les constructeurs donnent les moyens de se servir de leur matériel, ou ecrivent des pilotes libres, ou des pilotes proprio _en respectant les conditions_, alors les gens pourront jouer et faire de l'im.
La clef c'est le respect des conditions... Tu dirais quoi si je telechargeais les sources de win2k sur edonkey et que je codais un OS qui serait un mix entre un BSD et win ? Je crois pas que ca serait toléré. Je vois pas pourquoi un autre truc qui ne respecte pas les conditions serait plus toléré que ca, juste pour avoir plus d'utilisateurs.
Nous on veut expliquer aux fabriquants de webcam que c'est pas parce qu'ils expliquent comment on peut s'en servir qu'ils vont couler le lendemain. De toute manière pour moi un matériel sans spec, c'est un matériel inutile, qui me servira tout autant dans une poubelle que sur mon PC. Ya bien que MS pour vouloir nous faire croire que le matériel est de manière inhérente lié au logiciel, et au logiciel proprio édité uniquement par le constructeur en plus, ce qui nous soumet à sa merci, et le pire c'est que les constructeurs de matos se mettent à y croire aussi toujours plus souvent (ce qui est un peu logique dans une optique de controle de leur vente... on veut faire acheter du nouveau matos ? suffit d'arreter le support de l'ancien sur les nouveaux systèmes...)
Si linux ce met à etre rempli de truc proprio non controllés, et que les auteurs décident un jours d'arreter, alors une nouvelle version de nux pourrait être bien pire que tout ce qui peut se passer si l'on suit une politique strict et cohérente en matière d'acceptation conditionnelle dérogatoire de pilote proprio. Parce que quand quelqu'un a un droit sous condition, ben ca n'implique tout simplement pas qu'il à le même droit sans condition (en l'occurence de faire du proprio sans ce soucier des api qui sont autorisées ou non, ce qui est la politique du noyeau)
1) stand alone ?? en dehors du noyeau ? L'un sans l'autre ?
Ca change rien.
Le fait de laisser le hook du gas n'aurait pas entrainé de violation de GPL directement, mais la seule utilisation qui en était faite en était une. Du coup ca saute. Si le gas veut continuer son truc en entrant dans le coté obscure, il a cas faire un patch. Et si t'es pas très regardant sur les licence tu pourra continuer a utiliser PWCX. Les distri pourront plus certes, mais vu que c'est illégal...
2) Non.
Le propriétaire est simplement toléré dans le noyeau sous certaines conditions.
Le fait est que ces conditions n'etaient pas respectées sur le driver. Le fait est qu'il existe depuis peu un moyen de maitriser automatiquement le respect des conditions (précision de la licence dans le driver, etc...) donc le coup du "ca fait longtemps que je bosse dessus" est caduc.
- Ca pénalise par contre les utilisateurs tant dans leurs choix que dans l'utilisation de leur machines.
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.
Si l'user il a envi d'utiliser n'importe quoi sans ce préocupper de savoir si ca a marché ou pas et sans comprendre les raisons qui font que ca marchait bien et tout d'un coup ca marche moins bien, ben faut surtout qu'il utilise win et jamais de mac ni de nux....
-- En plus on masque les vrais problèmes avec cette histoire... Qu'est ce qui jusitifie que les spec d'une webcam ne soit pas publiques ??? Est ce que quelqu'un va oser me sortir que les specs permettrait aux concurrents de faire une puce plus simplement et de comprendre comment la cam marche en interne ? (note on ma déjà fait le coup avec les CG et j'y ai meme cru à moitié pendant 5 minutes ;)
Oui mais le monsieur ce qu'il voudrait c'est une dérogation sur mesure à la GPL. Et je comprends un peu les mainteneurs du noyeau sur le fait qu'ils veulent pas. Parce que si tout le monde ce met à faire ca, tu peux jeter Linux dans l'année qui suit tant il serivira plus à rien avec plein de modules proprios de partout. Déjà que la qualité des truc proprios kernel spaces des "grands" (comme NVidia, ATI, ...) n'est pas toujours à 100%, alors si tous les developpeur imaginable ce mettent à fermer leur code pour le fun, ca va nous peter à la gueule.
Ils ont cas prendre exemple sur smart link : possibilité d'utiliser un driver libre pour acceder au matos (alsa), et programme en user space qui s'occupe du traitement du signal. Ca n'a rien de compliqué et ca regle les problèmes de violation de GPL du noyeau.
Le motif me semble clair : The kernel maintainers simply do not want to allow any kind of hook or function or mechanism, specifically written to make it possible to load a binary-module.
Les mainteneurs du noyeau en ont un peut marre qu'on viole la GPL à tour de bras. Aujourd'hui il n'autorisent les modules proprio à titre exceptionnel et derogatoire qu'en passant par un sous ensemble de l'API, et le gas avait écrit un truc dans le driver libre spécialement concu pour charger son module proprio.
Du coup le type il rebelle parce que ca fait 3 ans qu'il avait fait ca. Mais je ne crois pas que y a 3 ans il y avait deja cette histoire de sous ensemble d'API pour les drivers proprios.
Maintenant la question est de savoir si il y a les specs complete de la cam et si on peut reecrire son bidule sans passer 3 mois à reverse enginerer les anciens drivers ou ceux de win.
Si ya pas les specs complete et publique, franchement, personne ne peut prétendre ne pas avoir été prévenu du risque de perte partielle de performance... Avec tout ce qui a été expliqué mainte et mainte fois sur le sujet... Et j'en remet une couche : qu'en on utilise un driver proprio qui implement des fonctionnalités non documenté d'un matériel, on s'expose au risque qu'il disparaisse. C'est dommage mais ce n'est surrement pas de la faute des developpeurs du noyeau qui sur le coup sont on ne peut plus coherent avec leur politique... Si on commence a autoriser que chaque driver libre ait un hook pour implenter un driver proprio qui gerera les fonctions interressante du materiel, on se retrouve vite avec une grosse bouse.
Si y a les specs completes et publique alors un driver libre complet renaitra surrement, ce qui est une bonne chose.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
C'est déjà pas si mal pour des OS quand meme assez différents.
[^] # Re: 300 \o/
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 1.
Un coup de bz2 sur la page oueb, et hop, t'obtiens direct la quantité d'information disponible :p
[^] # Re: 300 \o/
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 0.
# Après les complots de MS, les complots de LFR
Posté par Guillaume Knispel . En réponse au message Linuxfr, c’était mieux avant !. Évalué à 3.
Alors j'ai encore plus adoré le complot du PS pour dominer LFR dans les commentaires du blog de Maxime Ritter :))))
[^] # Re: Linux est-il assez déployé pour se permettre ca?
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Ceci étant il est tout a fait vrai qu'on peut faire des drivers proprio sous win, avec quasiment aucune limitation (je crois que la plus grande limitation est d'eviter de prétendre que c'est MS qui les a fait ou de ce faire de la pub associant MS au produit sans son accord en disant que ca dérive d'un code de MS du ddk, ce qui est assez permissif :), ce que l'on ne peut pas faire sous nux.
Les libertés dépandent de la vision des choses que l'on a, certain préfèrent le copyleft, d'autres trouvent que le copyleft restraint la liberté de faire du proprio. Les premier rétorques qu'interdire une restriction de la liberté n'est pas vraiment une perte de liberté, etc...
Quand a savoir si le copyleft doit s'appliquer dans ce cas précis de driver de webcam (et donc le hook enlevé), cela dépand "juste" du statut du module proprio : dérivation de linux ou pas ? le reste ("ouin ca marchait pendant 3 ans, maintenant ca marche plus") n'a pas vraiment d'importance si il s'avère que la suppression du hook etait indispensable pour preserver la liberté de nux, fusse au dépend du nombre d'utilisateurs.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Sinon on en revient toujours au meme point : dans un soft ou il existe un système de plugin, imagine un type qui met, disons dans le fichier définissant l'interface des plug'ins, toutes les fonctions du code dans des wrappers, et distribue cette modif sous GPL.
Il peut ensuite bien tranquillement coder en dérivant le soft sans le dériver :p
Et si on lui dit "euh, t'es bien gentil, mais ton truc est dépendant du bidule GPL, donc met le sous GPL ou arrete de le distribuer", ben il lui suffit de reimplementer toutes les fonctions utilisées pour qu'elles fassent le moins de chose possible tout en permettant à son truc proprio de faire semblant de fonctionner, ou alors pour faire un truc qui a completement rien à voir...
J'ai bien l'impression qu'ici c'est de ca dont il s'agit : en standalone le truc du gars il sert à rien, et le type avait rajouté un hook dans le noyau rien que pour son truc proprio.
Donc on est bien obligé de croire les gars du noyau quand ils disent : le proprio c'est cet API et pas une autre. Sinon c'est la porte ouverte à toutes les dérivations masquées. Genre un noyau linux GPL rempli de hook qui font tous des appels à un truc proprio pour supporter une nouvelle archi... Et pour justifier la non dépendance, des programmes qui appelent les fonctions propriétaire pour utiliser certains algorithme d'une autre manière, ou carrement un système de test complet...
Alors, possible ou pas ? Faut-il violer consciemment la volontée des auteurs de linux, qui est de ne pas utiliser autre chose qu'un certain ensemble de fonction quand on est proprio, et si oui est-il légal de le faire ? Ont-ils clairement auparavent stipulés qu'ils ne souhaitent pas que des bidules proprio se chargent sans passer par l'interface officielle ? Le chargement du controlleur proprio de la webcam oubliait-il opportunnement de pourrir le noyau ?
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
En même temps qu'en j'y repense c'est mieux comme ca. J'ai été tellement habitué aux lois liberticides et aux copyright plus que fermé de partout que j'ai même plus l'habitude de penser à faire strictement ce que je veux chez moi, snif... !
Bon pour en revenir au module proprio de la webcam, il faut voir si se ne serait pas un travail dérivé de sa modif GPL du noyau (donc un travail dérivé du noyau en bref), ce qui constiturait une violation nan ?
Parce que si l'on ne considère pas cette possibilité, alors il n'y aurait aucun problème à diffuser un prog non compatible GPL capable d'utiliser Readline, et on sait bien que ce n'est pas possible. Donc ya forcement un truc.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 1.
La clef de ton exemple est une précision dans la licence: l'utilisation de tel ensemble de fonction ne constitue pas un travail dérivé. Sinon personne ne peut le deviner.
Maintenant si quelqu'un fait un patch qui modifie ton logiciel (pas juste faire un plugin) pour rajouter une fonction et que cette fonction est utilisée pour charger du code proprio, je doutes que le chargement du code proprio qui ne passe pas par l'API que tu avais autorisé pour les travaux non dérivés soit très catholique.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Là ce qui clochait en fin de compte c'était que à cause du fait que le truc proprio utilise le hook, il se transformait (illégalement) en travail dérivé. C'est ce que semble penser Greg KH.
On en revient un peu au meme point, c'est à dire est-ce qu'il faut laisser un type écrire un patch pour creer un hook dans une partie de gestion matérielle de nux (usb, ieee1394, pci, etc..) afin de satisfaire ses besoins de pilote proprio. Et si il ne faut pas alors soit il s'agit de limite légales (c'est ce qui est dit sur la LKML par Greg KH : Think legal limits, not arbitrary.) soit le mec il peut continuer à écrire des patchs qui recraient le hook et à se moment là son retrait est juste une question d'ego.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 0.
Que ceux que ca énervent inutilise ce commentaire pour se venger...
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 3.
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...
Ah c'etait toi ? :)
Ben en fait j'y crois plus qu'à 25 % là :p
Je ne prétend pas que ce que tu disais était impossible. J'en suis arrivé à un point ou j'attend simplement de voir. Or il ne me sera surrement pas donné de voir un driver de CG proprio dans ma vie, donc à mon d'aller bosser chez NVidia pour en faire, ce que je ne souhaite pas, je ne peux que supposer que ca dévoilerait beaucoup trop d'info ou non. Et je penche dans la balance de "ca pourrait devoiler quelques info interressantes, mais rien de crucial vis à vis des connaissances à peu près aussi étendu du concurrent".
Je considère aussi un echange technologique simultanné (qui si je reste réaliste ne se produira certes jamais) et je me demande ce que ca donnerait si il était mis en place par ouverture simultané des sources des deux cotés.
Là j'avoues que je vais un peu trop loin dans mes rêves utopiques :)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 3.
Sinon ca serait trop la rave, suffirait de faire des modules dynamiques qui se chargent dans 3 appli différentes pour pouvoir faire n'importe quoi.
Ca ne peut marcher que si les hooks du run time sont autorisé initialement. Un contributeur ne peut pas venir changer la licence et dire "tient, je rajoute un bout de code, et je dit que l'appel de cette fonction ne generera pas de travail dérivé".
Sinon il suffit d'encapsuler toutes les fonctions dans des hooks définis par le contributeur comme travail dérivé pour pouvoir linker du GPL libre avec du proprio, sans controle des interfaces et en integration totale. D'ou par l'absurde la conclusion que rajouter un petit hook personel pour pouvoir linker son petit truc proprio dans le kernel est impossible. Et c'est bien de ca qu'on parle ! Le fait qu'il est aussi possible que pwcx fasse aussi le café en user space ni change absolument RIEN.
* you are going to accept that there is a driver in the Linux kernel that
has a hook that _may_ be used to load a binary-only decompressor part into
the kernel, at the user's disgression. Maybe, one day, that part will be
open source too but I cannot guarantuee that.
Ca aurait du te suffire pour te convaincre qu'on parle bien ici d'un travail dérivé.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 6.
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.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 4.
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. C'est pas moi qui le dit c'est les kernel hacker. Et cet API elle est pas défini par le premier quidam venu, sinon je fais un module GPL wrapper qui encapsule TOUS les appels à TOUTES les fonctions du noyau, et pis apres bien tranquilement je déclare que je suis dieu et que cet API peut etre utilisée pour linké des modules proprio qui font ce qu'ils veulent.
# Cet article décrit le lot de tous les débutants
Posté par Guillaume Knispel . En réponse au journal Linux est-il trop beau pour être vrai?. Évalué à 10.
exemple : Linux didn't like my new flat-panel screen and insisted on unusable low resolutions. Much wasted time and online answer seeking (back in Windows) eventually saw 1280 x 1024 pixels again.
Alors que Linux n'en a rien a foutre des pixels d'un ecran. Second exemple : linux (sous entendu la distri, cet interpreation reglant aussi mon problème existanciel de noyaux et de pixels à l'écran :) ) te file plein de prog mais ils ne sont pas toujours compatible avec TOUS les autres prog qui font plus ou moins la meme chose. Euh, il veut pas 100 balles et un mars aussi ? :)
D'une manière générale, migrer juste parce que on en a marre de IE risque d'être une bien mauvaise idée pour pas mal de monde, il faut une motivation bien plus grande.
Et quand on a la motivation on ne rechigne pas a lire des docs pendants plusieurs heures pour faire marcher sa machine, pour ensuite l'oublier presque totalement pendant plusieurs années et ce concentrer sur son travail.
Mais le gas qui a déjà un win tout beau avec tous ses constructeurs de matos qui se sont acharnés a faire tout fonctionner d'une manière ou d'une autre, et qui se dit : tient IE sux, je vais tester nux, ben c'est sûr qu'il va passer à coté de 99% du système et s'arreter sur des détails de cosmétiques, ou d'incompatibilité qui vont simplement lui faire dire "linux ca suxe mon gadget XXXYYYZZZ il marche pas". De meme pour les fous furieux de matos à la mode et de gadgets, je vois pas trop ce qu'ils gagnerait à utiliser nux (sauf si ils sont fan de logiciel libre bien sur).
Ce qu'on apprend donc de cet article c'est que 1) un OS est difficile à installer (même win peut l'être parfois quand on a pas l'habitude ou quand on a du matos plus récent que sa version de win). 2) il faut etre motiver pour utilisé nux autrement que par "euh, IE ca sux grave". 3) Les applis ne sont pas toutes magiquement compatible entre elles parce qu'on est pas dans alice au pays des merveilles non plus. 4) plein de monde cherchent le système parfait et quand ils se rendent compte qu'il existe pas c'est la désilusion. Vu que "Will I give up Windows altogether? Probably. The more I use Linux, the better I like it despite the challenges. It hasn't crashed; it's immune to Windows viruses; it won't fall victim to spyware, worms or hackers;" le gas a pas encore entammé sa phase de désilusion et ferait bien d'aller trainer du coté des sites de sécu pour voir que du coté du libre comme ailleurs, les programmes parfaits du premier coup n'existent pas :)
D'après ce que j'ai vu autour de moi, soit il retournera sous win, surrement en utilisant pas mal de logiciel libre d'ailleurs, soit il sera entrainé dans une spirale de maitrise technique et philosophique du système :) En tout cas personellement j'ai jamais vu personne administrant leur propre machine de stable à long terme sous nux qui ne soit pas bien mieux informé sur la technique et la philo (sans forcement rentrer trop profondement dans les détails style programmation) qu'à ses débuts.
Rien de bien nouveau dans tout ca donc...
Un dernier commentaire sur le journal cette fois :
Pourquoi cet article? Parce que pour une fois il montre les avantages et inconvénients de Linux. Si vous le lisez, il y a de fortes chances que ça vous ne vous donnes pas envie de passer maintenant à Linux, mais plus tard peut-être...
Passer de win à nux à toujours été remis à PLUS TARD par beaucoup de monde et risque de le rester eternellement si l'on se contente d'attendre que 100% des chose que l'on fait sous win sont aussi faisable sous nux. Par contre en observant plus finement les 2 systèmes on se rend compte qu'on est pas dans une situation d'inclusion mais de recouvrement partiels des usages, cad on peut faire plein de trucs sous nux et pas sous win, et inversement. Sans compter que des fois le fait de ne pas pouvoir faire quelque chose sur un des 2 os n'est pas vraiment génant vu les différences qui existent.
Passer à nux ce fait soit tout de suite, soit ne se fait jamais, ou alors pas de manière stable, ce qui est encore plus dangereux en matière "marketing" (deceptions, incompréhension fondamental du modèle de devel du style "oh les gens du kernel ils sont méchant du coup le gas qui faisait marcher les cam phillips il est parti, c'est pas bien pour les pauvres utilisateurs", ...)
[^] # Re: Solution ?
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Faut arreter l'extasie un peu.
[^] # Re: pas cool :/
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Donc les mainteneur peuvent (et vont surrement) ne pas accepter.
Y a rien qui les obligent à accepter. Sont truc est libre, n'importe qui peut le REdistribuer, meme si il choisit d'arreter de le distribuer.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 2.
Alors tes gentils, mais va apprendre la difference entre GPL et LGPL et revient dire tes conneries après. Va aussi lire le coup de RMS qui a dit a je sais plus qui de passer son soft utilisant readline sous GPL ou d'arreter d'utiliser readline si tes pas bien convaincu.
Avant de vouloir parler d'un truc, faut ptet etre au courant avant, non mais !
[^] # Re: pas cool :/
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 6.
Maintenant si les constructeurs donnent les moyens de se servir de leur matériel, ou ecrivent des pilotes libres, ou des pilotes proprio _en respectant les conditions_, alors les gens pourront jouer et faire de l'im.
La clef c'est le respect des conditions... Tu dirais quoi si je telechargeais les sources de win2k sur edonkey et que je codais un OS qui serait un mix entre un BSD et win ? Je crois pas que ca serait toléré. Je vois pas pourquoi un autre truc qui ne respecte pas les conditions serait plus toléré que ca, juste pour avoir plus d'utilisateurs.
[^] # Re: pas cool :/
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 6.
Nous on veut expliquer aux fabriquants de webcam que c'est pas parce qu'ils expliquent comment on peut s'en servir qu'ils vont couler le lendemain. De toute manière pour moi un matériel sans spec, c'est un matériel inutile, qui me servira tout autant dans une poubelle que sur mon PC. Ya bien que MS pour vouloir nous faire croire que le matériel est de manière inhérente lié au logiciel, et au logiciel proprio édité uniquement par le constructeur en plus, ce qui nous soumet à sa merci, et le pire c'est que les constructeurs de matos se mettent à y croire aussi toujours plus souvent (ce qui est un peu logique dans une optique de controle de leur vente... on veut faire acheter du nouveau matos ? suffit d'arreter le support de l'ancien sur les nouveaux systèmes...)
Si linux ce met à etre rempli de truc proprio non controllés, et que les auteurs décident un jours d'arreter, alors une nouvelle version de nux pourrait être bien pire que tout ce qui peut se passer si l'on suit une politique strict et cohérente en matière d'acceptation conditionnelle dérogatoire de pilote proprio. Parce que quand quelqu'un a un droit sous condition, ben ca n'implique tout simplement pas qu'il à le même droit sans condition (en l'occurence de faire du proprio sans ce soucier des api qui sont autorisées ou non, ce qui est la politique du noyeau)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 5.
Ca change rien.
Le fait de laisser le hook du gas n'aurait pas entrainé de violation de GPL directement, mais la seule utilisation qui en était faite en était une. Du coup ca saute. Si le gas veut continuer son truc en entrant dans le coté obscure, il a cas faire un patch. Et si t'es pas très regardant sur les licence tu pourra continuer a utiliser PWCX. Les distri pourront plus certes, mais vu que c'est illégal...
2) Non.
Le propriétaire est simplement toléré dans le noyeau sous certaines conditions.
Le fait est que ces conditions n'etaient pas respectées sur le driver. Le fait est qu'il existe depuis peu un moyen de maitriser automatiquement le respect des conditions (précision de la licence dans le driver, etc...) donc le coup du "ca fait longtemps que je bosse dessus" est caduc.
- Ca pénalise par contre les utilisateurs tant dans leurs choix que dans l'utilisation de leur machines.
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.
Si l'user il a envi d'utiliser n'importe quoi sans ce préocupper de savoir si ca a marché ou pas et sans comprendre les raisons qui font que ca marchait bien et tout d'un coup ca marche moins bien, ben faut surtout qu'il utilise win et jamais de mac ni de nux....
-- En plus on masque les vrais problèmes avec cette histoire... Qu'est ce qui jusitifie que les spec d'une webcam ne soit pas publiques ??? Est ce que quelqu'un va oser me sortir que les specs permettrait aux concurrents de faire une puce plus simplement et de comprendre comment la cam marche en interne ? (note on ma déjà fait le coup avec les CG et j'y ai meme cru à moitié pendant 5 minutes ;)
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 10.
[^] # Re: pas cool :/
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 5.
[^] # Re: euhh ... mainteneurs oupsss ?
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 10.
Les mainteneurs du noyeau en ont un peut marre qu'on viole la GPL à tour de bras. Aujourd'hui il n'autorisent les modules proprio à titre exceptionnel et derogatoire qu'en passant par un sous ensemble de l'API, et le gas avait écrit un truc dans le driver libre spécialement concu pour charger son module proprio.
Du coup le type il rebelle parce que ca fait 3 ans qu'il avait fait ca. Mais je ne crois pas que y a 3 ans il y avait deja cette histoire de sous ensemble d'API pour les drivers proprios.
Maintenant la question est de savoir si il y a les specs complete de la cam et si on peut reecrire son bidule sans passer 3 mois à reverse enginerer les anciens drivers ou ceux de win.
Si ya pas les specs complete et publique, franchement, personne ne peut prétendre ne pas avoir été prévenu du risque de perte partielle de performance... Avec tout ce qui a été expliqué mainte et mainte fois sur le sujet... Et j'en remet une couche : qu'en on utilise un driver proprio qui implement des fonctionnalités non documenté d'un matériel, on s'expose au risque qu'il disparaisse. C'est dommage mais ce n'est surrement pas de la faute des developpeurs du noyeau qui sur le coup sont on ne peut plus coherent avec leur politique... Si on commence a autoriser que chaque driver libre ait un hook pour implenter un driver proprio qui gerera les fonctions interressante du materiel, on se retrouve vite avec une grosse bouse.
Si y a les specs completes et publique alors un driver libre complet renaitra surrement, ce qui est une bonne chose.
[^] # Re: pas cool :/
Posté par Guillaume Knispel . En réponse à la dépêche Fin du support Linux des webcams Philips. Évalué à 3.
??? Comprend pas du tout cette phrase.