tgl a écrit 1743 commentaires

> - le mix avec d'autres textes est possible (chacun sous sa licence),
> éventuellement dans des fichiers séparés

Au risque de me répéter, ça ne me parait absolument pas d'évident. Si conserver des fichiers distincts assure l'indépendance des parties d'une oeuvre en termes de licence, alors pourquoi considère-t-on habituellement que lier un programme propriétaire avec une bibliothèque sous licence GPL constitue une violation de cette dernière, y compris dans le cas d'une liaison dynamique ?
C'est une question sincère.

> Et tu peux aussi jeter un oeil sur ces bouts de code là, qui
> pourraient t'inspirer.

Plus précisement, le premier lien pointe sur "depreverse", un petit script du genre du tiens (qui fait aussi les dépendances des modules perl ou python, mais bon là on s'en fout). Lui doit être distro-agnostique je pense.
Le deuxième, c'est une surcouche autour pour faire des jolis dessins avec "dot", dans ce genre là :
http://tdegreni.free.fr/gentoo/freeciv-gtk2.ps(...)
Lui est spécifique à Gentoo, mais probablement adaptable si ça t'amuse (en gros, réécrire les bouts de code qui font des correspondances fichier/paquet).

Bon enfin non, mais pour disons qu'il n'est pas vraiment adapté à ce que tu veux faire. Typiquement, les bibliothèques que tu dois lister en tant que dépendances sont celles qui sont directement requises par tes binaires, alors que ldd fait une résolution récursive.

Essaye plutôt ça :
# objdump -p ton_fichier_binaire | sed -n 's:^NEEDED::p'

Et tu peux aussi jeter un oeil sur ces bouts de code là, qui pourraient t'inspirer. Y'a des trucs spécifiques à Gentoo dedans, mais c'est adaptable je pense :
http://www.gentoo.org/cgi-bin/viewcvs.cgi/users/spider/depreverse/?(...)
http://tdegreni.free.fr/gentoo/dotfinder.py(...)

Toutafè.

Juste pour en mettre une petite couche supplémentaire, le seul lien entre Daniel et Gentoo aujourd'hui (la page d'histoire mise à part donc), c'est un alias mail drobbinsCHEZgentooPOINTorg (et peut-être un reverse DNS aussi, j'ai pas regardé si il l'avait encore). Le reste (marque, copyright, etc.), c'est à la fondation.

Après, on peut troller si on s'ennuie (C'est Mal(tm) ? c'est Bien(tm) ? C'est Lui-que-ça-regarde(tm) ?), mais ce qui est clair c'est que ses choix présents ne peuvent pas avoir la moindre once d'influence sur Gentoo.

Nautilus c'est quand je veux opérer sur plusieurs fichiers, ou profiter des miniatures etc.

Ha ben voilà une réponse intéressante. Tout particulièrement, parce que pour moi, c'est plutôt le contraire. J'utilise abondamment la CLI pour les traitements de fichiers en masse.

Pour moi, traitement de masse et opération sur plusieurs fichiers, c'est pas forcement la même chose. Enfin bref, c'est pas pour jouer sur les définitions, mais je vois quand même deux classe de traitements distincts sur les ensembles de fichiers :

- les trucs complètement systématiques, programmable avec un oneliner en bash, comme par exemple la génération de thumbnails pour les images d'un répertoire, les renommages systématiques par regexp, etc. Là ça me viendrait pas à l'idée de passer par un gestionnaire de fichier graphique.

- les trucs répétitifs mais jamais 100% systématiques non plus : l'exemple qui me vient, par ce que c'est à peu prêt la seul fois où j'ai utilisé un gestionnaire graphique autrement que "pour essayer" (et c'était ROX en l'occurence), ça a été le rangement de mon audiothèque. J'avais des milliers de ogg/mp3 avec des noms assez hétérogènes, super longs et gavés d'espaces et autres nuisances, et pas particulièrement de dossiers pour classer tout ça ni rien. J'ai commencé mon rangement en ligne de commande, et c'était franchement l'horreur, par ce que ça revenait à une commande au moins par fichier pour le renommer et déplacer, et qu'en plus elles étaient très chiantes à taper (complétion peu efficaces à cause des nombreuses similitudes des noms de fichiers d'un même artiste, ce genre de trucs). Là franchement la GUI m'a ensuite fait aller très largement plus vite : les renommages se faisait directement en éditants le nom existant (laquelle édition pouvait passer par des copier/coller d'une portion du nom, etc.), et les déplacements d'ensembles de fichiers par drag'n'drop étaient eux aussi vachement plus pratiques.

> il suffit de voir ce qui prévaut dans le monde des distribs Linux, à
> savoir qu'une simple juxtaposition d'oeuvres n'est pas une oeuvre
> dérivée.

C'est un des cas de juxtaposition, pour lequel il est courament admis qu'il n'y a pas dérivation des oeuvres GPL. Mais un autre cas de juxtaposition est la liaison dynamique de code proprio avec du code GPL, et il est lui par contre courament considéré comme proscrit (en dehors d'exceptions explicites comme les modules noyau, on considère chez GNU que le couple formé consitue une oeuvre dérivée, et ce quel que soit le mode de liaison).
Je ne vois rien d'évident pour rapprocher plus de l'un que de l'autre mon exemple du CDRom ajoutant des fioritures à du contenu GPL. Moi j'aurais plutôt tendance à le rapprocher de la liaison dynamique, en ça que ce qui est juxtaposé à l'oeuvre GPL n'est exploitable et n'a de valeur que parce qu'il y fait sans cesse référence. Mais ça n'est que mon interprétation, franchement subjective.

> [...] any derivative work [...]

C'est là qu'est toute l'ambiguité que je voulais souligner. Les rares cas indiscutables comprennent la liaison statique ou de la modification directe, mais le reste est une question d'interprétation. Autant la GPL est limpide pour expliquer les droits et devoir en matière d'oeuvres dérivées, autant elle est obscure en ça qu'elle ne définit pas justement ce qu'elle entend par oeuvre dérivée.

Ah ça y est, vous avez adblock sous Konki ? Et ben c'est cool, il ne vous vous en manque plus que 467 alors :)
https://addons.mozilla.org/extensions/showlist.php?application=firef(...)

Perso, la notion d'oeuvre dérivée, si fondamentale dans la GPL, ne me parait pas forcement bien claire pour un document, enfin ça me titille un peu...

Imaginons cet exemple : je fais un cédérom de formation pour web-designers en me basant sur du contenu GPL d'Opquast. Il est composé de différentes table des matières et autre interface de recherche, pointant tous au final sur les différents éléments du contenu Opquast.

Est-ce que ce cédérom est un produit dérivé, et donc obligatoirement 100% GPL, ou bien est-ce la simple aggrégation du contenu GPL Opquast et d'une interface qui peut donc parfaitement être propriétaire (un peu comme dans certaines distribs Linux, avec des paquets libres et des outils proprétaires) ?

La première hypothèse est dérangeante, parce que si on va par là on peut très bien dire que Google devrait être GPL puisqu'il indexe du contenu GPL.

La seconde l'est aussi, parce qu'on peut alors se demander si la GPL sur un document n'est pas systématiquement contournable, pour peu qu'on prenne le soin purement technique de bien séparer en des fichiers distincts ce qui est d'origine GPL et ce qui est de l'ordre de la valeur ajoutée ou modification propriétaire. En poussant jusqu'au bout ce principe, rien ne m'empêcherait de diffuser indirectement un texte dérivé propriétaire sous la forme suivante : le fichier d'origine GPL, le fichier des modifications propriétaires, et une glue qlqconque (à base d'index par exemple), propriétaire elle aussi, permettant à l'utilisateur de consulter l'oeuvre dérivée.

C'est là, à mon humble avis, que le document se distingue du logiciel : le produit final, celui diffusé et reçu par l'utilisateur, n'est pas forcement la liaison intime de ses parties.[1] Ce qui est fondamentalement un dérivation de l'oeuvre originale peut être techniquement constitué uniquement par des ajouts.

Intuitivement, j'aurai tendance à dire que dans l'esprit du copyleft, si un document ne peut faire sens qu'en référence à un document GPL, alors il en constitue une oeuvre dérivée... Google serait donc OK parcequ'il indexe moulte autres choses, alors que mon cédérom bidon ne le serait pas puisqu'il n'est plus rien si on le prive de son contenu GPL. J'aurai, de même, par exemple tendance à dire qu'un gestionnaire de paquets générique peut être légitimement proprio puisqu'il permet d'installer autant du GPL qu'autre chose, alors qu'un script d'installation d'un logiciel GPL particulier ne peut être que GPL lui aussi. Mais ça n'est que mon interprétation...

Enfin bref tout ça pour dire que perso je suis bien emmerdé avec les licences copyleft. Je n'en connais pas de particulièrement meilleure que la GPL en la matière en fait, et pourtant je ne la trouve claire que lorsqu'elle est appliquée à des oeuvres modifiées dans leur corps ou bien liées statiquement... Ça couvre pas grand chose de nos jours :/
Perso, si j'avais des oeuvres auquels je tenais suffisament pour leur assurer un copyleft vraiment indiscutable, je crois que je prendrais la peine de les affubler d'une licence dérivée de la GPL qui expliciterait la nature des éventuelles oeuvres dérivées correspondantes à leur propre nature. C'est vraiment ça le problème pour moi : la dérivation depuis des headers du noyau n'a techniquement rien à voir avec la dérivation d'une documentation, et toute cette variété des mode de dérivation n'est que sous-entendue dans la notion d'oeuvre dérivée qui sous-tend les licences copyleft génériques. C'est à mon sens laisser bien trop de marge d'interprétation à un éventuel juge.


[1] Vous me direz, ça n'a rien d'inconnu ou de propre au document, puisque c'est aussi le cas de la relation programme/bibliothèque dans les langages interprétés, ou bien même en C avec la liaison dynamique. Ce dernier cas au moins est bien connu, c'est celui par exemple des modules noyaux : la thèse communement admise est que l'utilisation des headers du noyau implique la notion d'oeuvre dérivée, et que quand bien même le produit diffusé ne contiendrait pas le moindre bit de code GPL il n'en serait pas moins obligatoirement GPL (évidemment, des exceptions à la GPL existent pour les interfaces publiques du noyau, qui permettent quand même l'écriture de modules propriétaires). Ceci dit, si j'adhère dans l'esprit à cet interprétation, elle ne m'en parait pas moins optimiste, et je serai franchement soulagé le jour où un tribunal l'aura confirmée...

> ça ne permet de bouger dans les coins en prenant soin d'éviter un
> éventuel panel

Patch :
http://tdegreni.free.fr/temp/extremes--workarea.patch(...)

> (qui utilise ce genre de trucs de toute façon ?).

Bah moi, et j'assume :)

Y'a lea-linux.org aussi qui a qlqs liens dans son header, et qui voit passer pas mal de monde. Tu pourrais intéresser interlug-fr.org aussi je suppose, et pourquoi pas faire une annonce sur :
http://www.aful.org/wws/arc/interlug(...)

Et enfin, pourquoi pas une brève dans les niouzes de GLMF ? Tu as déjà un contact bien établi je suppose :)

En plus c'est pas HIG-compliant, ni DFSG-compliant :)
http://koke.amedias.org/2005/03/24/tintin-is-not-hig-compliant/(...)
http://lists.debian.org/debian-wnpp/2004/10/msg00700.html(...)

Bon nan sérieusement, je pense aussi vraiment que c'est s'exposer inutilement à des emmerdes que d'utiliser cet icone. Jimmac lui avait proposé ça à la place, mais ça n'a pas eu un succès fou :
http://jimmac.musichall.cz/weblog.php/2004/Nov/01(...)
Ça vous rappelle pas une certaine section BDD sur un certain site francophone consacré à linux et au libre ? :)

> Pour ceux qui ne connaissent pas c'est le blog de Maître Eolas

...qui justement dit lui aussi avoir hâte de lire le jugement. :)

Mais ça reste un adresse à surveiller ceci dit, puisque je ne doute pas que quand il l'aura il nous en fera part, ainsi que de ses commentaires.

Sur la diffusion de logiciel contrefait, je sais bien que c'est ce qui a été retenu, mais cependant il ne s'agit que de quelques 10aines d'octets (la clef de leur système de signature, cf. mon post en dessous), donc absolument pas qlqchose qui se substituerait à l'original.

C'est là que le jugement est quand même bizarre :
D'un côté, on dit que « non, grand dieu non, » ça n'est pas le procès du full-disclosure mais juste une banale affaire de contrefaçon. Et pourtant dans les faits, ce que Guillermito diffuse n'est absolument pas préjudiciable au sens des warez et autres actes de "piraterie", mais uniquement en ça qu'il met le doigt là où ça fait mal.

Bref je serais vachement curieux de connaitre les motivations des dommages qu'il a à payer. Les dommages, rappelons le, c'est la réparation d'un préjudice : le juge a considéré que Tegam méritait ~10000¤ pour compenser quelquechose qu'il n'aurait pas dû subir ou perdre... mais quoi ? Qu'est-ce que Tegam a subi sinon une sacrement mauvaise publicité ?

Reste l'utilisation de logiciel contrefait, et là ok, elle est indiscutablement avérée. Mais je doute que ça soit celà seul qui motive la note de ~10000¤, ça serait complètement disproportioné (d'autant que Guillermito s'est mis en règle assez rapidement grâce à un internaute qui lui a offert une licence). Bref c'est pas vraiment ça qui fait avancer le schmilblick.

> Une méthode que j'ai déjà utiliser

Argh, en parlant de grammaire...

Une méthode que j'ai déjà utiliser sur papier pour arriver à des phrase correctes grammaticalement, c'est d'annoter chaque contribution par leur "type" grammatical. Quand c'est son tour, le joueur vois la structure grammaticale de l'ébauche de phrase qu'il a à compléter, mais par contre ne sait rien des mots eux même (même pas le dernier comme tu fais toi).

Genre tu te retrouves devant :
"groupe nominal féminin pluriel" + "adjectif" + "complément circonstanciel" + "verbe transitif"
... et là a priori tu ajoutes un COD, ou bien juste un adverbe si tu veux laisser la primeur du COD au suivant, etc. Et quand tu vois que ta contribution amènes à un truc déjà suffisament long, bah tu décide de l'arrêter avec en plus une ponctuation.

Bon forcement, c'est un peu scolaire comme approche, mais c'est plus rigolo en fait quand tu les relies d'avoir des phrases correctement construites, plutôt que juste une bouillie de mots.
Je sais pas, je suppose qu'avec quelques champs de formulaire à choix multiples ça passerait bien sous forme de page web.

Un truc qui serait marrant aussi, ça serait de laisser brancher les phrases : si plusieurs personnes proposent des contributions en partant du même stade (parcequ'elles se sont connectées ~ en même temps), alors ça devient deux phrase en cours, et les suivants se retrouvent aléatoirement connectés à l'une ou l'autre, etc. Et une nouvelle phrase n'est entamée que quand toutes les branches de la précédente sont closes.

Enfin voilà, qlqs idées en vrac si t'as encore plus de temps à perdre quoi...

> Perso je trouve quand meme un peu "béte" quand on trouve des
> failles ou bug de les annoncer haut et fort sur le net sans en parler
> prealablement a l'editeur du logiciel.

Dans la version de Guillermito, c'est bien par là qu'il a commencé, et il n'a rendu la chose publique qu'après quelques tentatives infructueuses. Bon, après, c'est ce que lui raconte, donc on le croit ou pas, j'en sais rien du tout perso.

> on parle de "reproduit, modifié, et rassemblé tout ou partie du
> logiciel Viguard" et aussi de "procédé à la distribution gratuite de
> logiciels tirés des sources du logiciel Viguard".

Juste pour relativiser un peu cette histoire de contrefaçon, une petite explication :
http://www.kitetoa.com/Pages/Textes/Textes/25012005-Tegam_versus_Gu(...)

> Je n'ai généralement pas besoin de modifier un logiciel pour prouver
> qu'il buggue.

Sauf que là, enfin de ce que j'ai compris, le bug est justement que le logiciel est modifiable. La démonstration de Guillermito n'était pas que Viguard laissait passer tel ou tel virus, mais plutôt qu'il était simple d'en écrire un qui le rendrait inefficace. Ce qu'il a dévoilé, ça n'est pas vraiment un bug de cet antivirus au sens "ça marche pas", mais plutôt la description d'une attaque possible à son encontre, qui passait justement par l'utilisation des quelques octets cités dans le lien ci-dessus. Leur "contrefaçon" était donc bel et bien nécéssaire pour diffuser le proof-of-concept de l'attaque.

Après, on peut se dire que, du coup, il n'aurait pas dû diffuser son proof-of-concept. Mais encore falait-il y penser que ça tomberait sous le coup de la "contrefaçon", enfin perso ça m'aurait pas paru évident a priori...

Allez zou, pour pas que tu te reposes sur tes lauriers, une autre petite suggestion :
Quand on plie puis déplie un thread complet par double clic, ça serait sympa qu'il se restaure dans l'état où il était avant qu'on l'ait plié (au lieu d'avoir la totalité des commentaires qui sont dépliés).
Bon ceci dit, de ce que je comprends du code (m'enfin j'suis vraiment pas fluent en JS), ça m'a pas l'air évident : là les commentaires ont deux états (déplié / plié), et il en faudrait trois (déplié / plié avec le thread / vraiment bien plié).

Bon, c'est vraiment si t'as le temps/envie hein, c'est pas essentiel comme feature :)


Hmmm... puis en y réflechissant, ça tuerait un peu une utilisation du double clic qui est de déplier complètement un gros troll bien moinsé sans changer son seuil, donc c'est p-ê pas terrible comme idée en fait... Bon ouais nan alors, j'ai rien dit.

> Il est en tête de gondole au Virgin Megastore de la Défense !
> C'est là que je l'ai vu, il y a quelques jours, au milieu de la "chick litt"
> (la littérature pour gonzesses, dans la vague des Sex and the City et
> autre Bridget Jones).

Argh ! Plus j'imagine le tableau, plus je bénis les vrais libraires subsistants.

> Si quelqu'un pouvait découvrir pourquoi diable cette Elsa s'appelle Linux

Pour se faire de la pub gratuite avec Google peut-être ? J'imagine que parmi les mots courament recherchés, qui sonnent pas trop mal et qui provoqueront probablement pas de procès, Linux doit être plutôt bien placé.

Et puis vu le genre de bouquin et le coup du blog, l'éditeur a probablement plus misé sur le marketing en ligne que sur la tête de gondole à la Fnac...

Sinon ça peut toujours se programmer juste pour rire. Comme ça par exemple, c'est pas hyper joli, mais ça doit marcher avec pas mal de shells :

dec_to_oct() {
	local plop plip plup
	plop=${1}
	if [ ${plop} -lt 8 ] ; then
		echo ${plop}
	else
		let "plup = plop % 8"
		let "plop = (plop - plup) / 8"
		plip=$(dec_to_oct ${plop})
		let "plip = plip * 10 + plup"
		echo ${plip}
	fi
}

Yep, si tu épaissis légèrement la toolbar (au repos) tu peux voir le contenu scroller joyeusement. Le problème, c'est qu'il faut lui redonner le focus pour scroller dans l'autre sens si elle l'a perdu, et que c'est pas évident une fois le contenu caché (mais ça le fait avec les access keys).

Perso, je serais pour la garder tout simplement toujours visible : c'est ce que je fais avec ma css perso (juste qlqs modifs sur kaiska), et quand elle tient sur une seule ligne on peut vraiment pas dire que ça bouffe de la place. Je trouve ça plus agréable pour pouvoir aller viser à la souris droit sur là où est le machin que tu veux cliquer.

> ben le compilo peut generer des instruction sse2

C'est le cas d'ailleurs, enfin c'est ce que fera Xcode par défaut en tout cas (cf. la doc pdf pointée un peu plus haut).

Merci à tous les deux pour les précisions.


> ( très lent en ce moment )

Arf, ouais, ils font mirroir Debian ou quoi ?

Ah oui, et puis aussi qlqs autres éléments qui feraient qd même plutôt pencher pour l'hypothèse 32bits :
- la démo du WWDC tournait sur un Pentium4
- la config qu'Apple mets en vente pour les développeurs est aussi un Pentium4
- les slides montraient des Pentium D (un dual-core, en gros deux Pentium4 bien solidement collés ensembles)