Oui c'est tout à fait cela.

Une marque dont on ne peut prouver qu'elle a été défendue devient publique et quiconque a alors le droit de l'utiliser (et on se retrouve avec des entreprises malhonnêtes voire des sites pornos qui utilise le nom).

PJ a fait un excellent article à ce sujet sur Groklaw.net:
http://www.groklaw.net/article.php?story=20050816092029989(...)

Ce qu'il faut savoir c'est que jusque là, la défense de la marque Linux rien qu'en enregistrement de marque a couté 300000 dollars américains à Linux International, dont 250000 dollars viennent de la poche même de John Hall (puisque l'organisation à but non lucratif a très peu de revenu), auquel rien n'oblige à sortir son chéquier ainsi sinon son sens du dévouement et de la responsabilité vis à vis de la communauté.

Le fait d'élaborer une organisation Linux Mark Institute et un tarif d'utilisation de la marque[1] (et ils le disent eux même, sur des critères bien parmi les plus relachés concernant l'utilisation de la marque au monde), vise à ce que les frais de défenses de la marque se subviennent à eux même, bref que des entreprises comme RedHat, Mandriva, Novell ou je ne sais quoi qui bénéficient de l'aura du nom Linux sur leur produit pour leurs ventes, contribuent un peu à la défense de la marque en payant quelques frais de licence.

John Hall qui avait compté toute la situaion en privé, a même été incité à mettre sa réponse sur une des mailing list australienne tant elle démontre que ces effarouchements sont tout à fait immérités:

http://lists.linux.org.au/archives/linux-aus/2005-August/msg00084.h(...)

Il me semble assez difficile de l'accuser d'extorsion de fond au vu de son investissement personnel.

Après avoir lu tout cela mon impression est qu'ils sont assez pragmatiques dans l'exigence d'une licence pour utiliser la marque, et ne vont réclamer les sommes qu'aux organisations qui font du nom Linux un véritable usage commercial. Je présume par exemple que Debian ou Gentoo ou Patrick Volkerding et son Slackware ne tombent même pas dans le tarif "non-profit-organisation" (et qu'il n'est là que pour faire joli ce tarif) et ne verront jamais le Linux Mark Institute venir les embêter, parce que les parties sont raisonnables de chaque côté et que Debian ou Patric peuvent se targuer d'en faire usage depuis plus de 12 ans sans que Linus y ait vu mal au contraire, ce qui vaut accord implicite. Sans doute même existe-t-il pour Gentoo et Slackware (pas pour Debian à cause du contrat social) un accord écrit gracieux de Linus datant d'avant aout 2004 (le site invoque de tels accords écrits et que ceux d'avant cette date restent indéfiniment valides).

Et bien sûr commercialiser un tee-shirt avec le mot Linux est toujours considéré comme du fair-use [2] et reste exempt de licence.

[1] : http://linuxmark.org/fees.html(...)
[2] : http://linuxmark.org/who_needs.html(...)
(et plus généralement tout le site linuxmark.org)

[ Répondre ]

Je confirme, ils ont la versionnite chez gaim. J'ai rarement vu un projet libre monter en version de la sorte pour quelques corrections de bugs mineures. D'un autre côté, vu qu'il y a peu de changements d'une version à l'autre (je ne sais pas si il y a lien de cause à effet, mais on peut le penser), la mise à jour et la compatibilité ascendante en sont d'autant facilitées.

C'est quelque chose auquel il fallait s'attendre lorsqu'ils ont décidé arbitrairement de passer à la version 1.0 et d'adopter un nouveau système de numérotation. Il avait été décidé alors que la condition présidant au changement de numéro de version mineur serait un ajout à l'API qui ne casse pas la rétro compatibilité, un changement de numéro de version majeur si l'API était cassée, les autres modifications ne provoquant qu'un changement de numéro de version micro (majeur.mineur.micro). Je n'ai pas vérifier que c'était bien le cas, mais je présume qu'ils se sont tenu à ça.

D'un autre côté, vu leur rare tendance à casser leur API, je crois que nous aurons plutôt une version telle que 1.24.0 qu'un saut de version mineur d'ici là...

Le passage de la FAQ qui rappelle leur numérotation :
http://gaim.sourceforge.net/faq.php#q107(...)

[ Répondre ]

La lenteur de sortie des versions localisées n'est qu'une légende (enfin je crois ;-) )
Je l'ai écrit d'ailleurs il y a peu en commentaire d'un journal [1]

Les versions localisées de Firefox sont depuis quelques mois avant la version 1.0 sur le CVS de Mozilla.org. La traduction est inchangée depuis le mois de novembre, les éléments de localisation étant comme l'API gelés.

Les binaires des versions localisées sont préparées par les mêmes fermes que celle qui préparent la version anglaise. Et au même moment.

La distribution par contre se fait en moyenne en retard de 3 à 6 h sur la version anglaise. La raison est assez simple. La QA de la Mozilla Foundation emmenée par Asa Dotzler exige un test de chaque version qu'elle publie. Pour les versions localisées, elle attend que toutes les versions ait été testées. La plupart des équipes donnent leur feu vert bien avant la sortie de la version anglaise, malheureusement quelques équipes se montrent en retard dans ce processus. De ce que j'ai remarqué, MoFo les attend jusqu'à 6h après la version anglaise, et à ce moment là publie toutes les versions qui ont reçu le feu vert. Si toutes les équipes étaient promptes à effectuer le test, une sortie simultanée à la minute prêt serait possible, étant donné que 95% des équipes l'effectuent avant la sortie anglaise.

Concernant Thunderbird, la version localisée franchophone est faite à la main, par Jérome Schell qui réalise chaque fois un super boulot pour la sortir rapidement.

Enfin pour Mozilla 1.7.10, on n'a pas à rougir, les 5 packages des version localisées Linux i686 et Windows étaient prêtes 1h après la sortie anglaise (bon c'était la nuit, et j'ai pas beaucoup dormi mais bon..)

Cette impression de lenteur des versions localisées, j'ai plutot le sentiment qu'elle vient de la lenteur que nous avions montrée à sortir quelques versions localisées de Mozilla 1.7.x cet automne et cet hiver, ayant à tort un peu délaissé un temps, notre attention sur la Suite.

[1] : http://linuxfr.org/comments/601876.html#601876(...)

[ Répondre ]

J'ajoute que c'est bien un problème de volonté comme tu le dis .. habillé de la justification dont je parle juste au dessus.

[ Répondre ]

Voit pas le rapport : meme en mono-compte sous Windows, tu as un repertoire dedié a ton compte, comme ce que tu vient de decrire.

Oui, chacun sait ça ;-)
(Même si je voulais ignorer ce fonctionnement de Windows que je ne le pourrais pas, vu que je m'occupe de la plupart des versions des installeurs francophones de la suite Mozilla)

Simplement je ne fais que répéter les réponses à ce sujet de David Bienvenu et Asa Dotzler à chaque fois qu'on leur a suggéré, appuyés par d'autres équipes de localisation. C'est la manière dont ils justifient de mettre la localisation de Mozilla/Mozilla Firefox en per-system plutôt qu'en per-user.

Pour eux, les habitudes de l'utilisateur Windows font qu'il fonctionne souvent en monocompte, donc la localisation installée par défaut en per-user, ils n'en voient pas l'intérêt.

Mon post pouvait prêter à confusion, désolé, et faire penser à du FUD.
Mais c'est bien la justification officielle.

L'installation de la localisation dans le répertoire utilisateur fonctionne à la main mais ne le sera pas par défaut en automatique. Sans doute le feront-ils si Longhorn incite plus que ne le fait XP à fonctionner en multicompte.

[ Répondre ]

Oui... hélas...

Bon on peut toujours y arriver en modifiant deux, trois préférences à la main. Mais c'est pas l'idéal.

L'avantage c'est que une fois que c'est fait, à la main, on reste en français à chaque mise à jour, si on a installé le xpi en simple utilisateur.

[ Répondre ]

Dans un monde parfait les fichiers de localisations n'aurait rien a foutre dans un binaire et resterait bien au chaud sur le HD de l'utilisateur quand il upgrade de 1.0.x à 1.0.y si il le souhaite (on pourrait toujours DL 1.0.y avec les locales pour ceux qui font une première install

C'est possible en bidouillant.

Quand je compile Firefox sur ma Gentoo, je me retrouve avec la version anglaise. J'installe le xpi de la localisation française (ils sont dispo sur un des répertoire des mirroirs mozilla), je bidouille 5 minutes les préférences (via about:prefs ou directement dans le fichier) pour indiquer que c'est la localisation française que j'utilise.

Ensuite, étant donné que j'ai fait une installation utilisateur du xpi (et non système en passant en root), les fichiers de localisation sont dans un des sous répertoire de ~/.mozilla/ et à chaque mise à jour, la localisation reste en français.

Pour être plus concis, l'astuce consiste à ce que la localisation soit en 'per-user' et non 'per-system'. (j'aurais du dire ça directement au lieu de digresser bêtement)

Pour que cela devienne le défaut, il faudrait que Firefox ne soit pas aussi centré sur son fonctionnement sous Windows (et on peut rêver), où l'utilisateur lambda tourne en monocompte Administrateur..

[ Répondre ]

Tout ce que tu suggères fonctionne déjà ainsi :
la localisation de la branche 1.0.x a été gelée peu avant la sortie de Firefox 1.0 en novembre.

Depuis toutes les versions de la branche 1.0.x utilisent les mêmes fichiers de localisations. (Nous n'avons plus touché au cvs sur cette branche donc depuis novembre)
Ce ne sont pas des fichiers po mais ça tient le même role (ce sont des fichiers properties (Javascript) et dtd ).

Normalement les binaires localisés sont mis à disposition moins de six heures après la version anglaise. Ils sont créés en automatiques par la ferme de compilation de Mozilla.

La raison est de ce délai simple, Asa Dotzler (de la QA de Mozilla.org) tient à ce que tous les binaires localisés de la ferme soient testés avant d'être mis à disposition (même si il n'y a aucune raison pour qu'ils ne fonctionnent pas puisque la localisation n'a pas changé, mais bon la QA est comme ça..). A chaque version, la plupart des équipes de localisations donnent leur feu vert avant la sortie de la version anglaise, mais il y a toujours une ou deux équipes qui ne l'ont pas fait, et qui répondent 2 ou 3 heures après la sortie de la version anglaise. Ce qui explique le léger décalage de quelques heures.

Là ce n'est pas du tout un problème de localisation. Mais plutôt que Mozilla.org a pris la décision (contestable) de ne pas diffuser les binaires localisés de la 1.0.5 dès qu'ils ont appris avoir cassé une API (et une API sans rapport avec la localisation au contraire de ce qu'on peut le lire à certains endroits..).

[ Répondre ]

Le problème de l'API est que personne n'a été informé avant, même pas les developpeurs des extensions.

Soyons précis: le changement d'API est un accident. Probablement les patches 1.0.4->1.0.5 ont modifié par accident des API qui été censées être gelées. C'est donc un accident (un peu ennuyeux pour la réputation de Mozilla.org) et personne n'a donc à être prévenu d'un changement puisque c'est une régression temporaire (pléonasme) et en aucun cas un changement d'API définitif.

La 1.0.5 n'a aucune faille si ce n'est qu'elle n'est pas compatible avec certaines extensions du fait du cassage d'API.

La version 1.0.6 est juste un retour à l'API de la branche 1.0.x .. Une des corrections de failles de sécurité de la 1.0.4 est donc à réécrire sans casser l'API cette fois

Christopher Aillon (Fedora) [1] sur son blog fait un peu d'ironie, puisque Asa Dotzler avait dit qu'un des défauts des distributions Linux était les changement d'API continuel incessants. Asa lui répond [2] en disant que la différence est que c'est ici un accident alors que les changements d'API sont volontaires dans Fedora.

[1] : http://christopher.aillon.org/blog/dev/mozilla/20050714-apis.html(...)
[2] : http://weblogs.mozillazine.org/asa/archives/008524.html(...)

[ Répondre ]

Il y a plus élégant que la méthode proposée sur gentoo-wiki.com et ses cp ...

Il manque en fait juste à la compilation le flag --enable-official-branding

De là on peut même songer à créer un USE flag nommé branding qui active ce flag de compilation.

Voir le patch (à valeur bien cosmétique je le reconnais volontiers) que j'ai proposé à Gentoo:
http://bugs.gentoo.org/attachment.cgi?id=58755(...)
et le rapport de bogue associé :
http://bugs.gentoo.org/show_bug.cgi?id=89945(...)

[ Répondre ]

Il s'agit apparemment de problème de segfault dans quelques applications (au moins Kasteroids) lorsqu'elles sont compilées avec l'option -fvisibility=hidden de gcc (cette compatibilité avec cette option est la principale nouveauté de KDE 3.4, et comme il l'était évoqué dans un autre journal, permet à KDE de gagner en rapidité)

Il s'agit d'une methode d'une classe du toolkit KDE dont le code est visiblement non compatible avec cette option.

Le problème est connu en upstream et pour les developpeurs de Gentoo leur seule solution est pratiquement de sortir une ebuild sans l'option fvisibility=hidden.. En fait ils voudraient presque que KDE 3.4.1 sortent rapidement, résolvant ce problème, leur évitant de backporter du code du svn KDE via un patch.

Bon c'est en tout cas ce que j'ai pu tant bien que mal comprendre à partir de ce rapport de bogue:
http://bugs.gentoo.org/show_bug.cgi?id=86898(...)

[ Répondre ]

Les binaires francisés de Firefox sont en fait réalisés par les fermes de compilations de mozilla.org à partir des traductions de FrenchMozilla (contrairement à Thunderbird ou la Suite ou les binaires francisés incombent à FrenchMozilla) . En somme seul mozilla.org a le contrôle sur le moment de sortie des autres langues.

Ainsi, la plupart du temps (comme ce matin) les binaires francisés (et l'ensemble des autres langues) sont disponibles dans les 5 à 6h après la sortie de la version anglaise.

Pour la 1.0.3, ce ne fut pas le cas (il y a eu un peu plus de 24 h) du fait apparemment de quelques soucis techniques chez mozilla.org

J'en profite pour signaler que nous venons de sortir les binaires francisés de la Suite (Seamonkey) 1.7.8 à l'exception de la version Mac (encore à venir):
http://frenchmozilla.sourceforge.net/FTP/1.7.8/(...)
(attention: ne pas lier - dépot temporaire en attendant mirroring SourceForge et Mozilla.org)

[ Répondre ]

Le support des webcams tient apparemment au portage en Java d'une bibliothèque C toute nouvelle sortie à la mi-février, nommée libmimdec

http://www.jblinux.net/libmimdec/(...)
L'annonce :
http://www.hypothetic.org/docs/msn/phorum/read.php?f=1&i=10514&(...)

[ Répondre ]

Sous Mandrake (en tout cas sur les anciennes versions, pour les plus récentes il semble c'est pareil (à lire le cvs des rpmbuild), mais je ne sais pas vraiment, ayant quitté le bateau il y a un bon moment déjà), les deux pilotes atmelwlan.sf.net et at76c503a.berlios.de sont installés, et le hotplug lance les deux modules qui voulant gérer le même matériel causent un plantage plus ou moins grave (clavier bloqué voire kernel panic)...

Il faut donc soit blacklister un des deux modules (l'atmelwlan de préférence), soit effacer un des module, et refaire un depmod.

Quant à Debian, je n'ai pas testé (ma seule machine Debian est en remote), mais le pilote berlios n'est que dans Sarge et Sid et encore en source et contrib... Donc peut-être as-tu testé juste l'atmelwlan qui est assez bogué..

[ Répondre ]

Ce chip a deux pilotes libres, le meilleur étant le driver Berlios, qui résout tous les problèmes connus avec celui de atmelwlan.
http://at76c503a.berlios.de/(...)

Etant donné que le seul code binaire et non portable est le firmware uploadé dans l'appareil, ça fonctionne tant en x86 qu'en PPC.

Par un heureux hasard, le chip est dans tous les modules wifi usb que j'ai pu acheter : un Linksys WUSB11 v2.6, mais aussi un Zonet et deux Peabird ... Bon c'était pas très prudent d'acheter sans s'assurer de la compatibilité au préalable, je le reconnais.

La liste des matériels avec ce chip:
http://at76c503a.berlios.de/devices.html(...)

[ Répondre ]

Le fil Reuters (disponible sur Reuters.Fr mais aussi sur des sites comme Liberation.fr) s'étend longuement sur la perte de part de IE.

La dépêche est remplie d'inexactitude, en particulier sur la durée de vie de Firefox (deux ans demain et non quelques mois comme sous entendu), mais a le mérite d'exister..

http://www.reuters.fr/locales/c_newsArticle.jsp?type=techNews&l(...)

[ Répondre ]

Surtout que Madcat semble être vraiment une personne de valeur...

En parallèle du coup de main à Amule, Madcat s'est lancé dans le développement de Hydranode, un client modulaire P2P à l'architecture daemon/GUI depuis juin pour la préparation et depuis aout pour le coeur du développement et progresse de façon très impressionnante (voir le developper's diary)

http://www.hydranode.com/(...)

ShareDaemon (ex-Xmule2) suivait le même but, mais il semble que les contraintes dues à son origine emulienne ait incité à stopper le projet et à lancer celui-ci.

[ Répondre ]

C'est d'autant plus remarquable que la version française a véritablement explosé ces tous derniers mois. Il y a 4 mois environ, la version française comptait de mémoire (je peux me tromper) 31000 ou 32000 articles. Première version non anglaise, elle avait peiné en regard de la version allemande notamment et japonaise qui sont plus jeunes de deux mois.

Wikipedia semble vraiment de bons hospices même si je redoute toujours une exploitation à grande échelle ne respectant pas la GFDL par des gens sans scrupules.

Je ne doute pas que Wikipedia saurait trouver les ressources financières et juridiques pour se défendre. J'ai des craintes plus importantes pour des projets inspirés de Wikipedia sous une licence GFDL sur des domaines plus spécialisés mal couvert par Wikipedia qui contribuent ensuite leur contenu à Wikipedia. Eux auront du mal à faire respecter la licence de leur projet et leurs droits d'auteur.

[ Répondre ]

Je l'ai remarqué avec horreur ce matin une fois la dépêche modérée et en ligne. Je devais être un peu fatigué hier ... désolé..

[ Répondre ]

Sur la page en lien justement:
Surnommé le "père du rock'n'roll" , à la fin de sa vie, il aurait disparu dans les oubliettes de l'Histoire si Elvis n'avait eu une affection pour lui, au point de réinterpréter après deux autres de ses chansons "My Baby Left Me" et "So Glad You're Mine". Cet exemple a donné des idées à d'autres comme Eric Clapton, Creedence Clearwater Revival, Rod Stewart ou Elton John, mais Arthur Crudup n'aura jamais eu l'occasion de profiter de cette notoriété. Il tentait vainement d'obtenir le versement de ses droits d'auteur lorsqu'il mourut sans un sou, en 1974.

[ Répondre ]