Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information

Liens connexes

Dépêche modérée par

Dépêche éditée par

Développeur : Nouveau rebondissement dans l'affaire du pilote PWC

Posté par Thomas Petazzoni (page perso, ). Modéré le 31 mai 2005.
Noyau
Le début de l'affaire du pilote pwc remonte à août 2004. Jusqu'à cette époque, la partie libre de ce pilote pour webcams basés sur des chipsets Philips était disponible dans la version officielle du noyau Linux. Toutefois, ce pilote ne permettait de gérer que les modes de basse qualité des webcams, un module supplémentaire propriétaire, pwcx, étant nécessaire pour accéder aux modes évolués qui nécessitaient des routines de décompression.

En août 2004, un différent opposa les développeurs du noyau Linux au développeur du pilote. En effet, le module libre mettait en place un hook spécifique dans le noyau permettant au module non-libre de mettre à disposition ses fonctionnalités avancées de décompression. Or, les développeurs noyau, et en particulier Linus Torvalds, ne souhaitaient pas mettre à disposition un hook particulier pour les besoins d'un module propriétaire : "if a change is needed to be made to the kernel in order to get a closed source module to work, that module must be made opensource".

L'auteur du pilote a alors fait savoir que ce hook existait depuis longtemps et qu'il ne comprenait pas cette décision. Au final, la discussion a amené l'auteur à demander le retrait du pilote.

Le noyau Linux ne disposait alors plus de pilote pour les webcams à base de composants Philips, pourtant très répandues. Heureusement, un français, Luc Saillard, a repris le développement de ce dernier. À la mi-septembre 2004, il envoie un patch contenant une nouvelle version du pilote, entièrement libre, et permettant d'utiliser certains modes de décompression qui n'étaient auparavant utilisables qu'avec le module propriétaire, grâce à de l'ingénierie inverse. Tout semblait donc s'arranger.

Mais, tout récemment, nouveau coup de théâtre : le développeur originel du pilote demande de nouveau le retrait de ce dernier, arguant du fait que le pilote de Luc Saillard aurait été réalisé plus par décompilation du pilote propriétaire que par ingénierie inverse. Après une investigation plus poussée, Alan Cox a trouvé que les remarques de l'auteur originel étaient recevables. Il a par ailleurs eu une discussion amicale avec Philips qui a abouti au retrait du code litigieux des décompresseurs.

À ce jour, le noyau Linux supporte donc toujours les webcams à base de composants Philips, mais uniquement dans les modes basiques. Toutefois, ce rebondissement n'est certainement pas le dernier dans cette saga, et l'espoir de disposer un jour d'un pilote complètement libre et dégagé de tout problème reste présent.

> Lire la dépêche (114 commentaires, moyenne: 3,4).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Décidément

Posté par Ghislain LEVEQUE (page perso, ) le 31/05/2005 à 09:18. (lien). Évalué à 6.

Sauf erreur de ma part, c'est à cause d'un certain procédé de compression qu'une partie du pilote n'est pas libérée par Philips.

Je ne pense qu'on verra ce pilote se libérer si Philips veut garder cet algorithme de compression et quelque part il y a une certaine logique.

Donc à mon avis la vraie question c'est si Philips va libérer ou non ce procédé de compression....

la decompilation c'est interdit ?

Posté par renoo () le 31/05/2005 à 09:25. (lien). Évalué à 8.

"Mais, tout récemment, nouveau coup de théâtre : le développeur originel du pilote demande de nouveau le retrait de ce dernier, arguant du fait que le pilote de Luc Saillard aurait été réalisé plus par décompilation du pilote propriétaire que par ingénierie inverse."

La décompilation n'est elle pas la plus repandue des méthodes d'ingenierie inverse ? Je vois pas ce que peut etre l'ingenierie inverse pour un pilote de webcam.

le développeur originel...

Posté par équi () le 31/05/2005 à 09:31. (lien). Évalué à 4.

C'est quand même un vieu grincheux je trouve, et non pas pour sa réaction de départ : il avait codé un truc lui-même, il s'est senti "trahi" par Linus et les autres dévs et il a donc demandé le retrait de son module, ça c'est compréhensible.

Mais quel intérêt de ressortir ça 6 mois plus tard ?
Il n'a quand même pas mis 6 mois avant de voir que le nouveau module proposé était issu d'une décompilation de son module proprio ? -.-

Une explication possible serait que lui s'en fout un peu mais que Philips lui a mis la pression en découvrant ça (d'où les 6 mois), car d'après ce dont je me souviens le développeur originel a/avait un contrat avec Philips qui lui donnait accès aux spéc en contrepartie de ne livrer qu'un module binaire/proprio.

Précision

Posté par gnuk (page perso, ) le 31/05/2005 à 09:46. (lien). Évalué à 2.

Quelqu'un pourrais expliquer la différence qu'il existe entre "décompilation" et "ingénierie inverse".

De ce que j'en ai compris, les dévellopeurs du noyau ne veulent toujours pas intégrer ce code car il a été écrit à partir d'informations "décompilées".
Pourquoi la décompilation à l'air d'être une méthode refusée, c'est "illégale" quand il s'agit de code propriétaire ? (vous me direz ... si ce n'est pas propriétaire ... c'est surement inutile)

Je ne comprend pas tout.
Et moi qui me réjouissait d'avoir fait (re)fonctionner ma webcam :/

Pour information : j'ai compilé ce module sur des noyaux 2.6.5 (=< v10.0.5) & 2.6.11 (v10.0.7) sans soucis et il fonctionne à merveille.

Il existe une très bonne documentation (wiki) ici http://www.lavrsen.dk/twiki/bin/view/PWC/WebHome(...), notamment sur l'API.

[+] Juste une question

Posté par Samuel Pajilewski () le 31/05/2005 à 10:07. (lien). Évalué à -5.

On pourrait pas faire en sorte que le noyau integre facilement des modules proprios ?

Parce que devoir mettre open source un module quelque soit le pilote, ça risque de freiner l'adoption de Linux par les grands constructeurs de périphériques...

Hooks sur binaires

Posté par herodiade () le 31/05/2005 à 10:11. (lien). Évalué à 5.

On se demande bien pourquoi Linus accepte les hooks pour charger les firmwares binaires pour la majorité des nouveaux chipsets wifi, voir carrément des drivers incluant les binaires sans les sources (comme le driver tg), et refuse le hook pour PWC...

question juridique

Posté par Éric (Jabber id, page perso, ) le 31/05/2005 à 10:15. (lien). Évalué à 10.

Si j'ai bien compris c'est l'action de décompiler qui est interdite dans certains pays, pas le résultat (qui lui ne contrevient à priori pas aux droits d'auteurs s'il ne s'agit pas d'une simple recopie de la décompilation). Quelle est à votre avis la légalité aux US du driver issu de la décompilation si cette décompilation se fait en Europe ou dans un autre pays l'autorisant ?

Ceci dit ça me montre une chose, c'est que dans l'ensemble les gros logiciels libres refusent ce qui n'est pas conforme à la loi US. Je n'ai pas d'exemple en tête mais j'avais déjà vu ça une fois sur le DMCA et une fois sur la question du brevet GIF Unisys . Quand quelque chose est interdit dans un pays spécial on dit que ce n'est pas grave et que ça ne concerne pas la GPL. Par contre quand c'est interdit aux US là on retire les choses.

différent != différend

Posté par michauko (Jabber id, page perso, ) le 31/05/2005 à 12:36. (lien). Évalué à 3.

"Avoir un différend" a un sens, "avoir un différent" n'en as pas. Subtile différence ! ;)

Je commence a en avoir MARRE !

Posté par djibb (Jabber id, page perso, ) le 31/05/2005 à 13:53. (lien). Évalué à 7.

J'utilise une webcam phillips TOUCAM pro, parce que je suis astronomoe amateur et que c'est LA meilleure cam en astro (et toute la clique des "pro" chez phillips et creative).
http://astrosurf.com/djibb/new/images/astro/(...)
(tout fait a la webcam)
Pas de bol !! ces webcams sont dirigées par un module proprio appelé PWCX, basé sur PWC (GPL) et pas de bol, ce module n'est pas inclus dans la noyau... ca veut dire qu'a chaque fois que je veux faire une version de ceci : http:/www.lin4astro.org je me tape des ajouts de modules (et ca devient galère quand on veut tout automatiser un peu). C'est pourquoi la version de dev est basée sur knoppix 3.7, que la stable a plus de 1 an et demi et est basée sur knoppix 3.3.
J'ai vraiment été heureux quand j'ai vu que pwc rentrait dans le noyau et la je suis dégouté. Dégouté pourquoi ? Parce qu'un dev du libre a une problème avec son ego, a été vexé parce que son code ne satisfaisait personne sauf lui et qu'il a signé un DNA qui est expiré depuis bien longtemps et que donc, il pourrait très bien le mettre en GPL sans que ca gene personne. (meme pas Phillips... !)
Bref -> Ca me gave !

--
http://astrolix.org

patch externe ?

Posté par Edouard Geuten (Jabber id, page perso, ) le 31/05/2005 à 15:27. (lien). Évalué à 1.

Si j'ai bien compris le pilote de Luc Saillard :
- fonctionne
- est en GPL
- a été obtenu par des métodes légales en europe (la décompilation pour reverse engeenering c'est légal ici)

pourquoi ne pas simplement en faire un patch externe (en fait ca à l'air d'être déjà le cas) ?

Evidemment ca ne sera plus par défaut dans le kernel, mais c'est pas, IMHO, un si grand probléme. N'importe quel particulier pourra utiliser le driver si c'est légal dans son pays (ou à ses risques et périls) et il en vas de même les distributions non ?

Enfin je ne comprend pas pourquoi à l'air de trouver ca si terrible que ce ne soit plus par défaut dans le Kernel ?