Manuel Menal a écrit 516 commentaires

Comme indiqué dans la nouvelle, effectivement, les seuls partis politiques à soutenir la manifestation sont les Verts et le Parti Communiste Français.

Rappelons brièvement que les Verts avaient dès le début pris position contre la Loi sur la Confiance en l'Économique Numérique, de la même façons qu'ils avaient pris position contre la LSQ de Daniel Vaillant, dénonçant son caractère liberticide comme les associations appelantes. Ils ont à de nombreuses reprises rappeler qu'il était inadmissible que le réglement des litiges entre deux entités privées puisse se faire par une autre entité privée, faisant référence à l'article tant décrié (les propos sont presque mots pour mots, mais pas exactement, j'arrive pas à relire mes notes :-) Je n'ai pas de données sur le vote des députés Verts - ils ne constituent pas un groupe à l'Assemblée et je ne peux donc pas vérifier leur position exacte, mais nul ne doute qu'ils ont voté contre ce projet - ou alors, il y a un gros problème de contradiction.

De la même façon, le groupe CRC au Sénat, regroupant le Parti Communiste Français et le Mouvement des Citoyens - Pôle Républicain, s'est fermement prononcé contre cette loi, reprenant la même argumentation que celle qui a été développée par les militants, puisque leur démarche a été la consultation, pour la rédaction des amendements notamment. Ils sont ainsi signataires de la pétition contre la LEN. IRIS avait d'ailleurs remercié les sénateurs de ce groupe suite au vote en seconde lecture au Sénat (http://refperso.com/article.php3?id_article=62(...) pour l'article, et http://www.groupe-crc.org/article.php3?id_article=662(...) pour la position du Groupe.)

iRIS en profitait alors pour dénoncer le double discours du Parti Socialiste, qui est assez frappant lorsqu'on compare les prises de positions au Sénat et à l'Assemblée des députés, et le site du Parti Socialiste. Certains membres du Parti Socialiste dénonçaient un contraste très fort entre la Commission NTIC (Ludovic, excuse moi si je me méprends sur l'intitulé exact - tu me corrigeras) et les élus, la sénateur Danièle Pourtaud prenant ouvertement position pour le filtrage, et ne revenant aucunement sur ses positions de la législature précédente, que nous avions été nombreux à dénoncer. Plus généralement, l'attitude de l'ensemble du Parti Socialiste a été une fois de plus ambiguë, puisqu'il n'hésitait pas à souligner les points positifs, se refusant à se prononcer simplement contre ce projet de loi, tout en ne proposant que des amendements à la portée extrêmement limitée. On peut penser que la négociation peut apporter quelque chose même sur ces projets là - je ne le pense pas - mais il faut alors se jeter dans la bataille des amendements. Faute de combattivité, on ne peut que s'interroger sur la sincérité des élus socialistes dans leur refus de cette loi.

Il est intéressant de constater que les positions des trois principaux groupes de la gauche dite « parlementaire » sont très proches de leurs positions globales sur l'ensemble des sujets qui touchent à l'économie numérique : brevets logiciels, LIL, IP Enforcement, EUCD, pour ne citer qu'eux. On ne peut douter de l'engagement des Verts contre ces mesures, qui ne cessent de prouver qu'ils sont résolument contre les brevets logiciels dans les médias, et notamment sur leur site, allant même jusqu'à faire de ce genre de questions leur créneau (et on le comprendra d'autant mieux que c'est sociologiquement cohérent avec leur « électorat »). Le PCF s'est également engagé contre ces mesures, sans ambiguïté, les mettant cependant moins en avant médiatiquement, mais étant très présents au Parlement Européen (via le groupe de la Gauche Unie Européenne, dont le président est PCF) comme au Sénat ou à l'Assemblée. Le Parti Socialiste est lui beaucoup plus en demi-teinte sur ces sujets : désaccords entre les tendances au niveau de l'EUCD - sur lequel les élus socialistes semblent globalement très peu informés, toujours des désaccords au sujet des brevets même si la position du Parti Socialiste est dorénavant claire - s'en suit notamment un manque de combattivité étonnant de la part d'un si grand groupe au Parlement Européen, là où les groupes GUE-NGL ou Verts sont des petits groupes.

Je rajouterais une note personnelle en m'étonnant (étonnement majoritairement feint, mais tout de même) que les Verts, dont les élus et tendances rappellent régulièrement leurs positions anti-libérales, se prononcent pour une Constitution qui définit l'Europe dès le début du texte comme une « zone où la concurrence est libre et non faussée », et développant tout au long du texte, au détriment de toute mesure et réflexion sur les institutions, ou sur le rôle des citoyens dans l'Union. Nous avons pu apprécier le manque de justice des institutions européennes, l'éloignement toujours croissant des institutions (Commission, BCE, Conseil de l'Europe) et des citoyens, qui fournissent régulièrement aux gouvernements de se défausser de leurs responsabilités en se cachant derrière une machine toujours plus lourde. Les Verts connaissent ce problème, et l'ont dénoncé à de nombreuses reprises lorsque des mesures concernant les brevets, les OGM, sont passés au mépris de la démocratie par un changement d'intitulé ou autre entourloupe assez détestable. Il ne me semble pas que soutenir un Traité qui n'a pour but que de graver dans le marbre de la Constitution une Europe libérale, et avant tout et surtout tout sauf démocratique :-/

'Xcusez pour les probables fautes, il est tard, j'ai concours demain et je devrais réviser. :)

Hem. Se relire, parfois, ça aide. Bien évidemment, seule la LSQ est l'oeuvre de Daniel Vaillant, la LSI est l'oeuvre de Nicolas Sarkozy, et n'a pas grand chose à voir. Si ce n'est que le Parti Socialiste a eu des positions encore pour le moins ambiguës sur cette loi, une bonne partie des voix s'étant non pas élevées contre, mais en expliquant en substance qu'ils avaient commencé à faire pareil, et qu'ils l'auraient fait s'ils avaient été au pouvoir. Avant que le tollé associatif et syndical ne commence. Enfin, c'est un tout autre débat, et une toute autre question.

Il aurait été appréciable que le groupe socialiste au Sénat vote simplement contre cette loi, plutôt que de s'abstenir en brandissant l'irrecevabilité d'un article - par ailleurs tout à fait détestable -, ce qui permet au Parti Socialiste de prendre des positions pour le moins en demi teinte sur la LEN : tu as suffisamment suivi pour l'admettre.
Tu ne nieras pas non plus qu'il y a quelques années, ce furent les ministres socialistes, en la personne de Daniel Vaillant et bien d'autres, qui proposèrent des mesures similaires dans le principe - même si moins extrêmes dans la loi - via la LSQ et la LSI, contre laquelle un grand nombre des associations qui aujourd'hui appellent à la manifestation s'étaient élevées.
Heureusement, le Parti Socialiste a aujourd'hui réagi en s'opposant plus ou moins à pas mal des mesures. Mais il reste gêné, hésitant, et traîne souvent la patte pour condamner une loi qui n'est aucunement justifiable. Je me souviens de séances publiques où les sénateurs du groupe CRC se sentaient bien isolés lorsqu'ils s'opposaient à la LEN. C'est pour le moins dommage.

Sans oublier, même s'il a un certain nombre d'oeuvres communes avec Bibliolib, l'excellent http://marxists.org,(...) qui héberge des centaines de livres d'auteurs dits marxistes (la version internationale tient sur 3CD), et dont la branche francophone est assez développée : http://marxists.org/francais/index.htm(...) ;

Je vois mal comment on peut nier que la Qt/Free, puis la QPL sont totalement incompatibles avec la GPL. KDE en conséquence n'avait pas de pratique illégale. En revanche, les distributeurs qui distribuaient KDE et Qt, eux, en avaient. La différence, c'est qu'à l'époque la plupart des distributeurs majeurs - et beaucoup d'employés de ces distributeurs le confirmaient officieusement - en avaient rien à faire de ces problèmes de licence, dans la mesure où le marché était suffisamment petit pour qu'ils ne soient pas inquiétés.

Quant à RMS, ce que tu avances est complètement faux. Avant la sortie de Qt 2.2, et son passage en double licence (QPL/GPL), il rappelait encore dans ses conférences l'existence de Gnome à cause des problèmes de KDE qui perduraient, et l'expliquait toujours fréquemment en privé. RMS, en revanche, a pu dire qu'il était OK avec la QPL, dans la mesure où elle est libre (même si incompatible GPL). Le seul argument, à part les tentatives de mystification insensées qu'on retrouve encore aujourd'hui sur kde.org, c'est que Qt serait une bibliothèque liée au système : soyons sérieux.

En rajoutant la ligne dans /etc/hosts ?

Étrange, étrange, je l'utilise pourtant quotidiennement ici - et je viens de corriger des news dessus à l'instant mêmê. Pas de problème de proxy cache (le message a été affiché pendant un temps) ou autre bêtise du même genre ? news.hurdfr.org resolve bien sur 212.180.127.243 ? hmhmhm.. ça me laisse perplexe.

Et GNU/Hurd il en est où exactement. Parce que c'est pas avec le peu de informations/articles que l'on peut lire qu'on peut réellement suivre son développement.

C'est une question très difficile, j'imagine que tu en es conscient. GNU/Hurd en est où : il est relativement stable (à part sur les machines sur lesquelles le micro-noyau utilisé par le Hurd, GNU Mach, a des problèmes chroniques de stabilité) ; je l'ai moi-même utilisé comme seul système (GNU/Linux voulait plus s'installer ! :-) pendant près de deux mois, et aucun crash dans l'utilisation habituelle du système. (quand on commence à bidouiller pas mal avec proc, des translators, etc., là, les risques augmentent considérablement). Il est en tous cas très utilisable, du moins en console : la nouvelle console du Hurd, écrite par Marcus, supporte tout ce dont on peut souhaiter ou presque : le charset qu'on veut, y compris UTF-(8|16), la possibilité de détacher et réattacher ailleurs un vt (comme dans screen, sauf que c'est natif), la possibilité de multiplexer une console (pratique pour partager un terminal, faire des démos, ...), a plusieurs clients (VGA pour la console "native", mais aussi ncursesw, ce qui permet de rattacher sa console dans un xterm :-), même le beep, et bientôt des screensavers. ;-) Elle est très stable et facile à utiliser. De plus, grâce à Marco, on a un support XKB pour cette console qui permet d'utiliser n'importe quel keymap supporté par XFree86. Il mérite d'être testé !

La plupart des outils de base sont portés ; pour la plupart du reste, une recompilation suffit, ou alors une simple correction de bug dans le programme (genre, utilisation de MAXPATHLEN ou PATH_MAX inconditionnellement, ce qui n'est pas conforme à POSIX, utilisation de sys_errlist[], noms de fichiers teminant par /, ...) pour laquelle il suffira de demander un chtit peu d'aide à un membre d'HurdFr (par exemple). Seuls des grosses, grosses applications, comme Gnome ou KDE posent réellement problème, parce qu'ils utilisent des fonctionnalités (filelocks, par exemple) pas encore supportées par GNU/Hurd. La mémoire partagée SysV peut aussi manquer mais je ne peux pas citer d'application qui en dépende, de tête (The Gimp l'utilise mais marche sans). XFree86 est bien entendu porté mais il souffre de bugs embêtants : outre qu'il souffre des problèmes de lenteur de GNU/Hurd (notamment, les accès disques sont extrêmement lents), un bug empêche par exemple d'utiliser un clavier français en utilisateur normal. Le support des pthreads est encore assez jeune et quoi qu'a priori assez stable, plus de tests intensifs pourrait lui faire du bien :-)

Quant au support matériel de GNU/Hurd : il faut savoir que les pilotes de périphériques de GNU/Hurd sont aujourd'hui dans le micro-noyau, GNU Mach. La version "stable" actuelle est la 1.3 ; elle contient des pilotes périphériques issus de Linux 2.0.39, pour un certain nombre (via-rhine, rtl8139, ne2k) mis à jour. Alfred est en train de travailler pour intégrer à la prochaine version de GNU Mach 1.x les pilotes écrits par Donald Becker (dont sont issus les pilotes Linux, mais ce ne sont pas les mêmes, du fait de vieux conflits entre Becker et d'autres développeurs Linux) pour les cartes ethernet. Certains adaptateurs SCSI sont supportés. Plus de détails sur http://savannah.nongnu.org/cgi-bin/viewcvs/*checkout*/thug/thug/gnu(...) ; à noter qu'une version 2 de GNU Mach est en passe de voir le jour. La différence fondamentale est qu'elle utilise une bibliothèque externe pour les pilotes de périphérique, nommée OSKit, qui lui a des pilotes de périphériques de Linux 2.2.12, un code plus clair et documenté, un support PCMCIA, etc. Il lui manque cependant un support générique pour le port série (la seule chose pour lequel l'actuel marche, c'est le gdb à distance via port série, ce qui est déjà fondamental :-), un support PS/2, et surtout que les gens testent GNU/Hurd (notamment la console de Marcus dans tous ses recoins, XFree86, ...) avec.

Bon.. c'est à peu près tout pour l'état actuel de GNU/Hurd. Maintenant, les perspectives : le développeur principal du Hurd, Marcus Brinkmann, ainsi que pas mal d'autres travaillent actuelle sur le port du Hurd sur un autre micro-noyau, L4 - en l'occurrence, son implémentation par L4Ka, L4Ka::Pistachio. Les raisons sont multiples : GNU Mach est un micro-noyau de première génération ; ça veut dire qu'il fournit déjà par lui-même un grand nombre de services qui pourraient être mis dans l'espace utilisateur, par exemple, les pilotes de périphérique, la VM (Mach contient la partie de la VM qui décide de quelle page doit être virée de la mémoire et quelle page reste ; la partie concernant "où vont-elles ?" est réalisée en espace utilisateur, via les memory objects. c'est comme ça que fonctionnent les systèmes de fichiers, grosso modo), le scheduling, etc. L4, lui, ne fournit que les mécanismes de base qui nécessitent d'avoir des permissions spéciales (celles du noyau) : un appel système pour l'IPC le plus simple, la création d'espaces d'adressages, de threads, le changement des registres de base, le map en mémoire, et quelques petites autres choses. Pour Pistachio sur x86, je crois qu'on en est à 13 appels système, pas plus. L4, contrairement à Mach, est conçu avec comme objectif premier les performances. Pour les gens intéressés par des détails, je peux détailler, mais http://l4ka.org(...) le peut encore plus :-) (rubrique publications, notamment). Le port avance. Ca nécessite énormément de travail, sur les choses de base : VM, pilotes de périphériques, etc., nécessitent d'être bien pensés, bien conçus, de façon modulaire et performante. Beaucoup de travail est fait sur les spécifications en même temps que sur le code. Il n'est vraiment pas si difficile de participer : il faut juste lire les docs, essayer de comprendre, poser des questions (plein!), essayer de repérer les inconsistences, les trucs sur lesquels on pourrait bosser, et se jeter dedans.
Bien entendu, ça ne sera pas fini demain. Mais plus y aura de gens, plus ça ira vite. :)

A une époque pas si éloignée je m'étais interessé au GNU/Hurd mais depuis j'avoue avoir un peu baissé les bras parce que d'une part GNU/Linux est vraiment sensationnel et d'autre part, j'ai pas l'impression qu'il y ait un véritable engouement autour de GNU/Hurd. Je me trompe peut-être mais les hacker du Hurd devraient essayés de plus communiquer autour de leur projet sinon personne ne risque de s'y interessé (et c'est bien dommage).

Il est assez difficile de demander de communiquer à des gens qui sont déjà surchargés par la masse de travail à faire. Ils font l'effort, à chaque nouvelle /. (ou pour nous, francophones, chaque nouvelle DLFP :-) d'informer, de répondre, de rétablir la vérité, mais rien que ça demande énormément de temps, et ça n'est pas exactement le boulot le plus gratifiant et réjouissant intellectuellement. Quant à l'engouement, je serais pas aussi catégorique que toi. Beaucoup de gens s'y intéressent. Beaucoup de gens sont enthousiasmés. En revanche, il est assez difficile de leur faire franchir le pas de la contribution, parce que ça pourrait toujours un peu compliqué, un peu trop bas niveau, un peu trop réfléchi. Il faut le répéter : le développement du Hurd est accessible par tout le monde ayant des connaissances de développement en C. Le principe des translators, ça n'est pas dur à comprendre, c'est encore moins dur à coder. Prendre un bug au hasard, et se lancer à sa quête, c'est pas très difficile, et des gens, sur #hurdfr, sur #hurd, sur bug-hurd, sont prêts à vous aider. La plupart des threads sont des échanges entre Roland, Marcus, Thomas (trois développeurs principaux du Hurd, le premier et le dernier étant les auteurs originels) et des gens qui veulent corriger un bug.

D'autre part avec le peu de ressources françaises dans le domaine, il est d'autant plus difficile pour un non-anglophone de se documenter sur le sujet.

Ca, je veux bien le croire. Un gros travail de traduction avait été fait par HurdFr, mais la plupart ne sont aujourd'hui plus à jour. Ce serait génial que quelqu'un s'y remette ; ça non plus, ça n'est pas dur, tout le monde est prêt à aider (moi le premier), et c'est très instructif.

Voilà. Sinon ben j'ai toujours une machine sous le GNU/Hurd qui tourne même si je ne m'en sers pas vraiment, ça fonctionne bien (quoique un peu lent).

Si ça te dit, je pensais faire, quand on aura rétabli http://hurdfr.org(...) un RR sur un sous-domaine (du style, ssh.hurdfr.org) pour qu'un maximum de gens puisse avoir accès à une machine GNU/Hurd. J'en ai déjà 2/3 derrière, ce serait sympa si la tienne venait se rajouter (quelle connex', d'ailleurs ?). Pas besoin qu'elle soit allumée 24/24 7/7, vu que ce serait un RR.

1) Et même si Qt avait en QPL, le problème aurait toujours été le même ; il est fou de constater que même les développeurs KDE, aujourd'hui, des années après, ne sont toujours pas prêts à accepter qu'utiliser KDE avec Qt jusqu'à Qt 2.2 était simplement illégal. Bref, c'est comme tout le reste du post au dessus, de la désinformation, de la mauvaise foi.

Et je passe sur les propos insultants pour la personne de MDI et d'autres, qui, personnellement, me font toujours hésiter à réclamer un blâme, ou la suppression du commentaire.

Tu veux un récapitulatif ? Ca prend quelques lignes et quelques minutes, et si tu t'y perds, c'est que d'autres s'y perdent. Précise entre quoi et quoi tu te perds, et tout ce que tu peux te demander, et go. :-)

L'hébergeur de http://news.hurdfr.org(...) a eu des soucis d'ISP, il a donc dû changer d'IP. Le responsable des DNS pour hurdfr.org étant pas joignable pour le moment :-/, pour avoir accès à news. il faut rajouter dans /etc/hosts la ligne:

212.180.127.243 news.hurdfr.org

et tout devrait marcher impeccablement. À noter que http://hurdfr.org,(...) en rade depuis plusieurs mois, devrait être achevé dans le week-end et mis en ligne sur une bonne connex' dans les semaines à venir. Toute contribution, qu'elle soit de relecture ou sur le code (PHP, CSS, SQL, JS, .. :-) est bien entendu très très appréciée : n'hésitez pas à venir demander l'endroit où relire et où est le code sur #hurdfr, irc.freenode.net.

Si ça peut aider les gens à passer le pas, à découvrir en particulier la programmation (pour l'utilisation, etc., le mieux est quand même d'installer) avec GNU/Hurd : un certain nombre de membres d'HurdFr ont des machines qui tournent sous GNU/Hurd accessibles à qui en fait la demande (même endroit qu'avant). La plupart sont derrière des ADSL, mais c'est très potable (si quelqu'un a une machine GNU/Hurd hébergée avec une meilleure connex ou la possibilité de le faire, c'est plus qu'apprécié! :). C'est pratique pour tester, compiler, découvrir.

C'est clairement indiqué sur http://www.gnu.org/licenses/license-list.fr.html(...) ; la dépêche dit "d'après l'annonce", et je semble confirmer dans les commentaires, mais j'avais été un peu vite en besogne en considérant le soutien d'Eben à la clause sur les brevets comme une acceptation tacite de compatibilité avec la GPL : en y réfléchissant à deux fois, il semble clair que ça ne peut pas être le cas.

La plupart des licences Creative Commons sont non libres, il faut le rappeler. C'est un des gros problèmes posés par ces licences à la demande : on a tendance à ne pas réfléchir à sa licence, dans toutes ses implications - compatibilité, respect des DFSG, de l'OSD, de la définition de la FSF, problèmes pratiques (e.g.l'advertising clause) - mais à devenir un consommateur qui pique à droite à gauche, comme dans un supermarché, les caractéristiques de ses licences.

Par exemple, il paraît complètement naturel à la plupart des utilisateurs de licence Creative Commons de rajouter un 'nc' (non-commercial). Rappelons que toute licence avec cette restriction est non seulement non libre (non respect de la liberté 0 selon la FSF), mais même pas Open Source (6. No Discrimination Against Fields of Endeavor, pour citer l'OSD - et les DFSG, puisque le premier est basé sur le second).

Et vos mains pour coder.

Tous les fichiers de XFree86 ayant pour détenteur des droits d'auteur "The XFree86 Project, Inc.", ainsi que le code des développeurs ayant donné leur accord, verront leur licence changer. Ils se trouvent éparpillés un peu partout parmi les composants essentiels et bibliothèques de XFree86. Branden a commencé une revue des licences utilisés dans XFree86 ; pour avoir la liste des modules en question, il faudra probablement attendre un peu.

Ce qui est sûr, c'est que la plupart des bibliothèques seraient affectées par ce changement de licence.

Qt et Gtk+ (principalement Gdk pour Gtk+) sont essentiellement basés sur la XLib, et en font grand usage.

As-tu déjà essayé de créer un programme X sans la XLib ? Bonne chance. :)

Sans problème, bien entendu. Le problème est uniquement la XLib, et plus généralement l'ensemble des bibliothèques fournies par les implémentations de clients X. Si ces bibliothèques n'ont pas une licence compatible avec la GPL, ça n'est pas légal. La licence du serveur derrière n'importe absolument pas (dans la mesure où le protocole X est un standard. S'il s'agissait d'exploiter une interface spéciale totalement spécifique au serveur X de HP-UX, ça se discuterait.)

Sauf si on se réfugie derrière l'exception que je citais plus haut, celle des "composants systèmes". Il me semble beaucoup plus défendable de considérer la XLib et ses équivalents comme composantes essentielles du système, dans le cas d'un système comme HP-UX. C'est globalement ce qui se fait pour la plupart des logiciels Win32 sous GPL, bien que je sois conscient que le cas de Win32 est encore à part.

HTH.

D'abord, on a le problème du flou énorme dans la définition de "end-user documentation". J'aurais dû mal à considérer que le dit "CD booklet" soit de la documentation à destination de l'utilisateur finale. M'enfin...

Plus généralement, ça n'est pas David Dawes qui dit ce que la phrase doit dire. Éventuellement, vu qu'il l'a vraisemblablement écrite, il peut préciser le sens voulu (en but d'une modification), mais ça serait à la justicie de décider du sens réel de la phrase. On ne va pas ressortir le député rapporteur de tel ou tel loi pour qu'il précise comment il faut l'interpréter. Je vois mal comment on pourrait convaincre, e.g., un juge que la phrase plus haut veut dire qu'à chaque endroit où l'on remercie des gens, il faille remercier XFree86.

Si tu as lu l'ensemble des threads, tu as probablement pu constater que David Dawes partait de plus en plus en délire complet... Son interprétation semble changer, qui plus est, au fur et à mesure qu'il s'énerve tout seul. Reste la clause. En revanche, son interprétation de la clause a un intérêt dans la mesure où c'est en suivant son interprétation qu'il décidera ou non d'attaquer quelqu'un qu'il estime ne pas respecter la licence.

Attention, attention, luc2, ça va finir par se voir.
(Note to self: Je trouve de plus en plus plaisant de faire des petites recherches sur ces personnages qui fustigent les micro-noyaux.)

Je les ai lus. J'ai lu aussi debian-legal. J'ai lu aussi /.. Et ?

Je considère toujours qu'il est faux d'interpréter la clause ci-dessus comme signifiant "à chaque endroit où l'on remercie un tiers, il faut ajouter la phrase" (ce que tu as dis).

D'abord, parce que sans préciser "dans la documentation destinée à l'utilisateur final", ou, alternativement, "dans le logiciel", ça n'a même aucun fondement. Donc ta mention des pochettes, boîtes, etc., est sans fondement.

Ensuite, parce que je pense (et si j'en crois mes discussions et debian-legal, je suis loin d'être le seul) que même cette restriction est une interprétation abusive de la clause. Le singulier me semble bien montrer que le but de la précision "same location" (ou "same place") est qu'on n'ajoute pas la phrase dans un endroit paumé alors que les autres remerciements sont bien en évidence. Certainement pas qu'on l'ajoute partout.. Ca me paraîtrait insensé.

En revanche, j'admets volontiers que l'ambiguïté de la phrase pose un problème en soi. Mais comme je considère cette clause abusive (pas au sens légal, cette fois) de toutes façons, ça n'a que peu d'intérêt..

Parce que ça ne l'a jamais été. Du tout. Qt était en Free/Qt dans les débuts de KDE 1, licence qui n'était pas libre. Utiliser KDE lié avec Qt, c'était alors enfreindre la licence des applications KDE sous GPL en question (la plupart). C'était donc parfaitement illégal. C'est une des raisons pour lesquelles le projet Gnome a été créé, outre le fait que Qt était purement et simplement non libre à l'époque.

À l'automne 98 (si ma mémoire me fait pas défaut), Trolltech a décidé de publier les versions à venir de Qt sous une nouvelle licence, la QPL (Q Public License), qui, elle, est une licence de logiciel libre. Cela resolvait le problème moral qui se posait à beaucoup, et un certain nombre de problèmes pratiques. Mais le problème légal, lui, n'était absolument pas résolu : la QPL n'est pas plus compatible avec la GPL que la licence précédente. Il était donc toujours illégal d'utiliser KDE avec Qt (avec Harmony, ça n'aurait pas posé de problème, mais Harmony n'en était qu'à ses balbutiements (stade qu'il n'a jamais dépassé par ailleurs)). C'est pour cette raison que potato (Debian 2.2) contenait Qt (en version 2, sous QPL), mais pas KDE.

Le problème légal a lui été résolu à partir de Qt 2.2 (il me semble), avec le passage de Qt en double licence (QPL/GPL). Il suffisait alors d'utiliser Qt dans les termes de la licence GPL, qui donnait parfaitement le droit de lier KDE (sous GPL ou LGPL) avec Qt.

Le problème a été maintes fois expliqué, démontré, les solutions énumérées, ici-même et ailleurs (je me souviens avoir fait, il y a plusieurs années, avant KDE 2, un commentaire à ce sujet). Outre les explications empêtrées et hors sujet que l'on peut encore aujourd'hui trouver sur le site et dans la documentation de KDE (comme : oui, mais les développeurs de KDE ont signé un accord avec Qt comme quoi Qt serait toujours libre. Et alors ?), l'excuse la plus donnée était que la GPL permet aux logiciels de lier avec des bibliothèques considérées comme étant des composants essentiels du système. J'ose espérer que l'hypocrisie derrière cette affirmation apparaît clairement à tout le monde.

Voili, voilà. Rappelons le enfin : il n'y a aujourd'hui aucun problème légal avec KDE, Qt, à ma connaissance du moins. Et le problème dont nous parlons aujourd'hui ne serait pas avec KDE ou Qt, mais avec toutes les applications GPL utilisant XFree86 (donc, Gnome compris).

Tu as dû mal comprendre.

Il n'a jamais dit que ça affectait Qt particulièrement. Qt est effectivement affecté, pour les raisons que j'évoquais : si l'on veut utiliser Qt et X11 simultanément, il faut suivre les termes de la QPL, donc, pas de logiciel GPL utilisant Qt. Donc, pas de KDE.

La seule raison pour laquelle ça affecte, notamment, Qt, c'est l'incompatibilité avec la GPL. Paul Cannon citait Qt parce que c'est un des toolkits majeurs très utilisés par les applications en conjonction avec les bibliothèques d'XFree86. Mais le problème se pose quasiment de la même façon avec Gtk+. (j'ai la vague impression de me répéter)

Euh, non. Il est explicitement dit que cette phrase doit se trouver avec les autres remerciements à des tiers, -dans la documentation destinée à l'utilisateur final-. Ce sont les premiers mots de la clause.
Effectivement, on peut imaginer une lecture de la clause qui nécessiterait l'inclusion de cette phrase dans tous les endroits où on remercie des tiers dans la documentation. Il faudrait alors vérifier tous les documents considérés comme documentation à destination de l'utilisateur final (rarement vu un concept aussi peu clair dans une licence :), et inclure la phrase en question à chaque endroit où on remercie des tiers. Je reste à peu près persuadé que ça n'est pourtant pas le sens de la phrase, dans la mesure où "location" est bien au singulier. Une telle lecture devient plus problématique si on choisit d'inclure la phrase dans le programme lui-même, qui est encore plus susceptible de contenir de nombreux endroits où on fait des remerciements à des tiers.

Ceci dit, il suffit de mettre dans un fichier considéré comme documentation destinée à l'utilisateur final la liste des phrases du style. Cela pose de réels problèmes, mais ça ne veut certainement pas dire qu'on doive l'inclure partout.

Concretement, qu'est ce que cela veut dire pour l'utilisateur lambda. Dois je m'attendre a ce que Debian et autres Mandrake soient dans l'obligation d'arreter l'usage de Xfree? (du moins a partir de la 4.4)

Plusieurs solutions. La première, en rester à XFree86 4.3. C'est la solution qu'adoptent temporairement Mandrake et RedHat. L'autre solution, c'est qu'il semble que peu de développeurs, outre David Dawes, veulent utiliser cette nouvelle licence. Comme le choix de la licence est propre à chaque développeur, il "suffirait" d'exclure le code écrit par David Dawes, et des autres développeurs utilisant cette nouvelle licence. C'est le choix que semble avoir fait Theo de Raadt pour OpenBSD : http://marc.theaimsgroup.com/?l=openbsd-misc&m=107696705911864&(...) ; L'autre solution qui vient à l'esprit à l'heure du Xserver de FreeDesktop, de Xwin, de Xouvert, et autres "branches" et "forks" de XFree86, c'est d'utiliser un d'entre eux, et avant celà, de le pousser pour qu'il soit utilisable. On y croit ou on n'y croit pas. Je n'y crois pas. :)

Cela dit, je trouve ca vraiment flippant de se rendre compte qu'un tel projet peut partir en sucette aussi facilement. Il y a pas un moyen de se proteger contre ce genre de "détournement"...

Je ne sais pas si le projet "part en sucette". Il y a effectivement un problème de fond chez XFree86, d'organisation, de cohérence et d'unité. Les développeurs se sentent lâchés, ce qui évidemment n'aide pas. Ce genre de problèmes arrive cependant dans tout gros projet : mais selon l'état du projet, on le gère plus ou moins bien. XFree86 n'était vraisemblablement pas en mesure de gérer efficacement le problème. Au vu des conséquences pour les autres projets, je pense cependant que le problème sera géré, avec plus ou moins de casse au passage..

En revanche, si ça pouvait être l'occasion d'une vraie review des licences dans de gros projets comme XFree86 (chose que Branden Robinson a commencé), afin d'être plus ou moins sûr de la légalité de la diffusion de trucs aussi centraux, ce serait une très, très bonne chose. La politique de l'autruche, qui veut que s'occuper des licences, de toutes façons, c'est de la masturbation intellectuelle pour pipopensourceux puisqu'ils ont rien d'autre sous la main, pourrait à mon humble avis devenir une bombe à retardement pour le libre. Le syndrôme mplayer...

Mais qui est incompatible avec la GPL, comme je l'expliquais plus bas. Je ne t'apprends rien, puisque c'était ce qui empêchait Debian de distribuer KDE avant le passage de Qt en double licence, et ce qui valait à KDE la "condamnation" de la FSF et d'une bonne partie des partisans du logiciel libre. Si une distribution intègre un XFree86 dont des bibliothèques utilisées par Qt utilisent cette nouvelle licence (et ce sera vraisemblablement le cas dès XFree86 4.4), on retombera sur la même situation : il sera bien possible de distribuer Qt, mais aucun logiciel GPL l'utilisant. Il ne sera pas plus possible de distribuer Gtk+, et tout logiciel l'utilisant, donc a fortiori Gnome.

Ceci dit, je ne vois pas en quoi ce serait un problème de licence de Qt. D'ailleurs, Qt n'a jamais eu de problème de licence (au sens légal du terme), c'est bien KDE qui en avait, puisque le seul moyen de l'utiliser était d'enfreindre sa licence. Mais c'est une vieille histoire...