Effet inattendu de la GFDL

  • Canada
  • GNU/Linux
  • Pine
Vendredi soir je consultais wikipedia français et anglais pour avoir de
l'information sur ma destination voyage: l'ouest canadien.

Je trouve l'information suivante sur la page de Vancouver
(http://en.wikipedia.org/wiki/Vancouver):
« An aboriginal settlement called Xwméthkwyiem, [...] »

Comprenez mon étonnement sur le nom "aborigène" de Vancouver. Je fais
quelques recherches sur internet concernant ce nom:
http://www.google.com/search?q=Xwm%C3%A9thkwyiem&num=100

On y trouve que les pages de wikipedia et quelques clones. Je consulte
avec plus d'attention et je trouve que le nom qui était là avant le
douteux «Xwméthkwyiem» est « Wu'muthkweyum ». Pas moins douteux me
direz-vous mais là n'est pas mon point.

Je fais alors une recherche pour ce nom:
http://www.google.com/search?num=100&hl=en&lr=&q=Wu%27muthkweyum&btnG=Search

Beaucoup plus de résultats (15) mais encore une fois, des clones de
wikipedia en de wikipedia fr et en. Mais attention, des clones obsolètes!
Ce mot n'est plus dans wikipedia, du moins pas dans l'article sur
Vancouver (sauf en français mais c'est pas grave, ça ne nuit pas à ce que
je vais expliquer ci-bas). Remarquez que wikipedia, le site, arrive en
sixième position (fr.wikipedia.org)

---------------------------------------------
Ce qu'on peut en déduire

Il n'y a rien de plus simple que de télécharger toute la base de données
de wikipedia, toute langue confondu. Sans l'historique, les discussions et
tout le tralala, ça tient sur quelques gigs. Ne reste qu'à télécharger la
BD et la mettre en ligne, et vous voilà avec votre propre wikipedia (le
contenu seulement) sur votre site web.

Note: Désactiver Adblock pour bien comprendre ce qui suit.

Prenons un exemple:
http://www.sciencedaily.com/encyclopedia/vancouver__british_columbia

Voyez le nombre de pub qu'il y a autour du texte. Bien sûr il y a la note
sur le copyright au bas de la page:
[
Note: The original source of this article can be found on the main
Wikipedia Web site.
This article is licensed under the GNU Free Documentation License, which
means that you can copy and modify it as long as the entire work
(including additions) remains under this license.
]
mais l'usager lambda n'y voit que du feu. On a donc du contenu sérieux
sur son site web sans aucun effort. C'est le jeu avec GFDL, j'ai pas de
problème avec ça.

Ce que nous avons compris, Vincent et moi, c'est qu'il suffit de
télécharger une copie de wikipedia, qui représente l'encyclopédie _à un
moment précis_, de le mettre en ligne et d'attendre que la véritable
version de wikipedia se modifie. Pendant que nous avons une version
statique, le "véritable" encyclopédie évolue, c'est-à-dire qu'elle change
ses mots, son contenu et fini par diverger de ce que nous nous avons sur
notre site. Ainsi, nous voilà en bonne position dans les moteurs de
recherche pour certains mots-clefs (exemple trivial: Wu'muthkweyum), vu
l'abondance incroyable de mots gracieusement fournis qui eux ne se
retrouve plus, au du moins plus dans cet ordre, sur la version évolutive
de l'encyclopédie.

Il est ainsi possible, avec un peu de patience, de ramasser du traffic sur
son site web en n'ayant rien créé. Que fait-on avec le traffic ainsi
généré? On vend de la pub ou on le dirige vers un autre endroit de son
site!

Miguel
 

Re: Effet inattendu de la GFDL

  • Canada
  • Windows
  • Mozilla Thunderbird
C'est pas mal intéressant comme remarque. Ca me fait penser à la
situation KHTML vs Safari. Apple a utilisé le code source de KHTML mais
renvoie ses améliorations au code sans suivi CVS, de diff ou
explications (corrigez-moi si je me trompe). La license est respectée à
la virgule près mais le code fourni est inutilisable par l'équipe KHTML.
Il semble donc qu'en certaines occasions, il est possible de prendre
avantage des licenses libres en les suivant à la lettre mais pas
nécessairement en suivant l'esprit de la license.

Fadi
 

Re: Effet inattendu de la GFDL

  • Canada
  • GNU/Linux
  • Mutt
  • FOAF
  • PGP

> C'est pas mal intéressant comme remarque. Ca me fait penser à la
> situation KHTML vs Safari. Apple a utilisé le code source de KHTML mais
> renvoie ses améliorations au code sans suivi CVS, de diff ou
> explications (corrigez-moi si je me trompe). La license est respectée à
> la virgule près mais le code fourni est inutilisable par l'équipe KHTML.


Des motifs fort raisonnables expliquent en partie le pourquoi - ainsi,
beaucoup de code de Safari est destiné directement aux API de OSX, alors
le code pourrait difficilement s'utiliser ailleurs.

D'autre part, je crois que KHTML et Safari visent deux objectifs;
l'équipe Safari veut améliorer son produit au plus vite quitte à tourner
des coins ronds alors que l'équipe de KDE a tendance à favoriser
l'élégance même si ça prend plus de temps. D'ailleurs, les quelques
chanceux parmi nous ayant pu voir les dernières moutures de KDE peuvent
constater comment ça commence à drôlement payer toute cette élégance,
comment les applications commencent à interagir entre elles toute seules
et à quel point <flame>c'est loin en avant de Gnome</flame>.

Alors j'ai l'impression que même si les modifications au code de Safari
étaient bien documentées, peu de ce code serait incorporé dans KHTML.



> Il semble donc qu'en certaines occasions, il est possible de prendre
> avantage des licenses libres en les suivant à la lettre mais pas
> nécessairement en suivant l'esprit de la license.


Effectivement, Safari est un beau cas, mais pensons aussi à un certain
stack TCP/IP utilisé par un fameux système d'exploitation propriétaire.


--
--====|====--
--------================|================--------
Patrice Levesque
http://ptaff.ca/
wayne(à)ptaff.ca
--------================|================--------
--====|====--
--
Pièces jointes
 

Re: Effet inattendu de la GFDL

  • Canada
  • Windows
  • Mozilla Thunderbird
Patrice Levesque wrote:


>>C'est pas mal intéressant comme remarque. Ca me fait penser à la
>>situation KHTML vs Safari. Apple a utilisé le code source de KHTML mais
>>renvoie ses améliorations au code sans suivi CVS, de diff ou
>>explications (corrigez-moi si je me trompe). La license est respectée à
>>la virgule près mais le code fourni est inutilisable par l'équipe KHTML.
>>
>>
>
>Des motifs fort raisonnables expliquent en partie le pourquoi - ainsi,
>beaucoup de code de Safari est destiné directement aux API de OSX, alors
>le code pourrait difficilement s'utiliser ailleurs.


De ce que je comprends, il serait possible d'aller chercher plus de
patches, et certaines sont intégrés dans KHTML. Le gros du problème,
c'est que les développeurs de KHTML n'ont pas accès à la doc (bug
report) d'Apple. Donc des patchs avec des commentaires comme: "fixes bug
#123876" sont difficilement utilisables. Mais ton autre point est je
pense la raison majeure du problème


>D'autre part, je crois que KHTML et Safari visent deux objectifs;
>l'équipe Safari veut améliorer son produit au plus vite quitte à tourner
>des coins ronds alors que l'équipe de KDE a tendance à favoriser
>l'élégance même si ça prend plus de temps. D'ailleurs, les quelques
>chanceux parmi nous ayant pu voir les dernières moutures de KDE peuvent
>constater comment ça commence à drôlement payer toute cette élégance,
>comment les applications commencent à interagir entre elles toute seules
>et à quel point <flame>c'est loin en avant de Gnome</flame>.


Sans vouloir commencer un débat, le problème majeur de Gnome c'est que
la technologie de binding de objets c'est CORBA qui est cirssement
complexe à utiliser, donc peu de projets l'utilisent, au désagrèment
d'avoir des fonctions sofistiquées comme KDE permet maintenant. De plus,
QT est un API beaucoup plus sofistiqué que le widget set qu'est GTK.

Je me demande comment QT se compare à OpenSTEP (ou Cocoa, ou GNUStep).


>Alors j'ai l'impression que même si les modifications au code de Safari
>étaient bien documentées, peu de ce code serait incorporé dans KHTML.
>
>
>>Il semble donc qu'en certaines occasions, il est possible de prendre
>>avantage des licenses libres en les suivant à la lettre mais pas
>>nécessairement en suivant l'esprit de la license.
>>
>>
>
>Effectivement, Safari est un beau cas, mais pensons aussi à un certain
>stack TCP/IP utilisé par un fameux système d'exploitation propriétaire.


Ainsi que des utilitaires tel que ftp et telnet. Voici le désavantage
des licenses complètement libre comme BSD et LGPL dans une certaine mesure.

Ciao,


--
Stefan Michalowski
Email: mitch(à)ptaff.ca
PGP Key: http://screamerone.zapto.org/k.asc
 

 

Propulsé par xhtmail