Edouard Gomez a écrit 450 commentaires

Tu aurai pu faire un export vers du htemeleux.

J't'ai maile l'export en hachetemeleux... je ne peux malheuresement l'uploader nule part car le proxy du boulot m'en empeche

--
Edouard Gomez
/me slaps JaL</a not so private joke>

Je fais un soft basé sur du logiciel GPL dont tu es l'auteur. Je le redistribue tout en précisant bien que je me suis basé sur du GPL, que ceux qui veulent peuvent trouver la version originale à l'endroit X. Sauf que je met mon soft sous licence proprio.

NON, c'est pas possible, seul les auteurs du soft GPL ont droit de changer la license. Et encore ce droit ne s'applique qu'aux portions du code que chacun des auteurs a ecrit.

Ton exemple ne tient donc pas la route, car ce que tu y decris est une violation de license, et de copyrights... ce qui d'apres la GPL te fait perdre tous tes droits de redistributions, modifications etc etc...

--
Edouard Gomez
-*- Revises ta GNU GPL -*-

Oui, c'est pour ca que les standards existent :-)

Une appli A compatible standard TRUC cree MACHIN , l'appli B elle aussi compatible standard TRUC peut donc lire MACHIN.

La realite, tu t'en doutes, est plus compliquee puisqu'aucun logiciel n'est bug free (sauf hello world) et que si "faute a pas de chance" ce bug touche directement la generation du stream, ou son interprettion/preparation, tu deviens vite "non compatible" avec le standard MPEG4.

DivX4.02 n'etait pas compatible MPEG4, XviD en mode entrelace ne respectait pas le standard, DivX5 utilise un rounding non compatible avec le standard dans certains cas... etc etc etc

Les sources de ffmpeg refletent bien ces divers bugs. En effet l'equipe de ffmpeg a choisi de rester compatible avec les formats mm "souilles" de bugs et a donc ecrit des work arounds pour chacun d'entre eux. XviD quant a lui se concentre sur le respect du standard kit a ne pas rester compatible avec d'anciennes versions qui auraient contenu un bug. DivX reste majoritairement compatible MPEG4 mais il arrive que des bugs connus presistent, le reste est opaque puisque nous n'avons pas acces aux sources.

--
Edouard Gomez

Nous avions tout simplement mal interprete le fait que si un logiciel proprio A se link avec le logiciel GPL B (de n'importe quelle facon) alors il derive de B. (je ne sais plus exactement quelle clause stipule cela)

En gros on avait interprete ca comme suit:
Si mr X utilise XviD dans Adobe Premiere (exemple, n'importe quel soft proprio fait l'affaire), alors Adobe premiere en se linkant a XviD tombe sous le coup de la GPL... ce qui nous parraissait stupide. C'est ce qui nous avait motive a rajouter cette clause, pour en autoriser l'usage. Contre coup, le developpement d'applis proprios etait aussi rendu possible via ces interfaces.

Maintenant, sachant que nous avions zappe le fait que l'utilisation du logiciel GPL n'etait pas couvert par la GPL elle meme (et ce malgre une lecture et rerelecture de la license) tout devient plus logique et a moins qu' un des auteurs refuse un retour a la GPL promptement, la GPL devrait etre reappliquee au plus vite.

J'espere que cela te permet enfin de comprendre la raison du pourquoi de cette clause (qui ama n'a plus de raison d'etre)

--
Edouard Gomez

Non c'est pas totalement correct.

MPEG4 decrit une myriade de features que tu es libre d'implementer ou non. Le standard definit aussi des profiles afin de faciliter l'interoperabilite de certaines solutions MPEG4. Typiquement un encodeur Simple Profile cree des fichiers lisibles sur du materiel/logiciel Simple Profile.

Aujourd'hui DivX4/5 et XviD-stable creent un bitstream pouvant exploiter toutes les features du simple Profile, DivX5 Pro et XviD-dev quant a eux exploitent quelques features du Advanced Simple Profile. C'est pourquoi les video DivX5 Pro et XviD-dev ne sont plus lisibles sur du DivX4/5 ou XviD-stable. Par contre le simple profile n'etant qu un sous ensemble du advanced simple profile, les anciennes videos retent toujours lisibles.

J'espere avoir ete clair.

--
Edouard Gomez

Zut on avait loupe cette phrase magique, dire qu on avait lu, relu et rerelu la license pour essayer de trouver la solution la plus contrignante pour les logiciels proprietaires... je crois que maintenant j'aurais un tres bon argument pour defendre un retour a la GPL originale.

Merci

--
Edouard Gomez
"Comme quoi les licensesc jamais simple"

(Pour info, sous mswindows, les programmeurs, meme de programmes libres comme VirtualDub, utilisent une api completement proprio et non portable pour accéder aux codecs - On ne peut que donner raison à RMS qui dit que faire du libre reposant sur des fondations proprios est complétement contraire à l'esprit initial)

On est d'accord sur ce point.



Pour ceux qui n'ont pas tout à fait compris la phrase de GomGom et (GPL + "exception de link") l'idée, c'est qu'en gros, on peut désormais faire du proprio linké sur xvid (comme avec ffmpeg), mais alors on est *obligé* d'utiliser Microsoft(tm), c'est interdit autrement...

Je ne suis pas d'accord du tout, mais alors pas du tout. As tu seulement lu cette exception link ? Je ne crois pas que tu l'ai correctement interprete et pour cela je te conseille de lire ce qui suit.

Cette exception permet un link avec XviD lorsque 2 conditions sont remplies :
- le logiciel ne derive pas d'XviD au sens de la GNU GPL (excetion faite du link)
- le logiciel utilise XviD uniquement via les interfaces DShow et VFW.

Le premier point permet de conserver l'esprit de la GPL tout en se rapprochant de la LGPL. Le deuxieme point quant a lui retreint la liberte accordee en point 1. L'usage legal d'XviD ds les media players win32 est tout de meme rendu possible.

Je me premet de reprendre : on peut désormais faire du proprio linké sur xvid (comme avec ffmpeg)

Cette affirmation gratuite se trouve etre totalement fausse. La LGPL n'oblige pas ceux qui link leur logiciel proprio a une lib LGPL de rendre leur programme (L)GPL tant que le lien entre les deux se fait au moyen d'une interface quelconque offerte par la librairie LGPL.

Un contre example simple a ton affirmation pourrait etre :
- je cree un programme proprio qui fait du MPEG4 grace a XviD.
- XviD est LGPL
=> le soft peut rester proprio.

- je cree un programme proprio qui fait du MPEG4 grace a XviD.
- XviD est GPL+link exception
=> le soft obeit il a l'exception link ?
- non, alors passage au GPL ou abandon d'XviD
- oui alors il reste encore a prouver que le logiciel ne depend pas a 100% d'XviD sous peine de retomber ss le coup de la GNU GPL pure et simple.

Nous, auteurs d'XviD, avons refuse qu'XviD puisse etre utilise a 100% dans un soft proprio. Cette clause incite donc finalement tres fortement les gens a programmer en GPL (ou compatible) s'ils veulent profiter au maximum d'XviD, et ceci car certaines features ne sont accessibles que via l'interface native d'XviD qui n'obeit pas a l'exception de link.



En attendant que xvid devienne "LGPL" partout, utilisez ffmpeg - c'est LGPL mais ca ne privilégie pas les OS proprio.

Premierement: XviD ne passera jamais sous LGPL pour les raisons evoquees precedemment.

Deuxiemement: le seul changement de license que nous envisageons serait eventuellement de repasser en GNU GPL sans clause d'exception pour la version 1.0. Autrement dit, nous condamnerions volontairement les windosiens puisque qu'ils enfreigneraient la GPL en utilisant XviD sur un OS proprio (XviD serait lie a des libs proprio en runtime). Ils perdraient donc de fait les droits que la GNU GPL leur confere habituellement... cad le droit d'executer, de modifier et de redistribuer XviD... Cet effet de bord est il vraiment souhaitable ?

Troisiement: la LGPL est une non solution. Certes elle favorise l'adoption des logiciels libres a court terme dans les systemes/environement proprios. Mais elle ne favorise en aucun cas le developpement d'un OS+logitheque totalement libre, but premier du projet GNU.

--
Edouard Gomez

FUD... on fait pas du XviD, on fait du MPEG4... certes un seul bug concernant l'encodage en mode "entrelace" (pas tres utilise en pratique) a fait que les versions du mois d'Aout et precedentes sont incompatibles uniquement pour ce mode. Mais il ne s'agit que d'un cas bien particulier et ca n'a rien a voir avec une "compatibilite descendante". Les films que j'ai encode en novembre 2001 sont toujours lisibles en novembre 2002.

Tu t'ai fait eu... postes les liens en commentaire stp.

J'ai oublié de parler de la license... :-(

Alors le choix de rester le plus fidèle à la GNU GPL nous a poussé à rester sous la GNU GPL plus une exception de link pour que les utilisateurs de windows puissent utiliser le codec sur leur OS favori (oui, nous respectons leur (mauvais) choix :-).

En conformité avec la section 8 de la GNU GPL, et pour protéger les auteurs du codec ainsi que ses utilsateurs, une restriction géographique a été imposée afin d'en interdire la distribution aux USA et au Japon, pays où les brevets logiciels détenus par le consortium MPEG LA sont reconnus et applicables. Si aujourd'hui les développeurs principalement européens n'ont rien à craindre, tout risque de changer très vite avec l'arrivée prochaine de l'EUCD en Europe.

Je voulais donc attirer votre attention sur le problème des brevets logiciels qui en lieu et place de favoriser les innovations, ne font que freiner le développement de nouvelles technologies. XviD a pu s'adapter cette fois ci en jouant sur la restriction géographique, mais pour combien de temps des projets tel qu'XviD resteront-ils légaux dans un contexte ou la moindre idée pourrait être sujette à royalties ?

Ce n'est pas un bug de top, mais un "bug" de Linux lui meme (ou plutot une specifite d'implementation). En effet Linux ne voit aucune difference entre un thread et un process. Tous deux sont crees grace a un appel a clone(), seuls changent des flags specifiant quelles choses le process partage avec son parent.

Voila pourquoi top affiche les threads separemment.

--
Edouard Gomez

Ouais le qwerty au boulot ca aide pas

J'enleve mes moufles, c promis

UCI: http://uci.sf.net/(...)

Zut les liens ca marchent pas.

XviD: http://www.xvid.org/(...)
UCI: http//uci.sf.net/

Je crie au scandale ! Pour ce prix la, l'anus artificiel devrait etre compris dans le packaging.

Ca me fait doucement rire de voir quelqu un dire: "j'ai trouve comment faire marcher la raie ss le diablotin et pas ss le pinguoin" puisque c'est le meme driver, ca se configure a quelques details pres de la meme facon :-)

http://speedtouch.sf.net(...)

C'etait juste une precision que je tenais a faire.

--
Edouard Gomez

Salut, n'hesites pas a donner ton feedback a francois rogler qui, faisant des etudes aux USA, ne peut donc pas tout tester quant a la compatibilite speedtouch<->freebee5. Pour choper son mail, ca se passe sur le site bien connu des surfeurs de mantas bleues : speedtouch.sf.net (<-- ecrit en templeet d'ailleurs ;-) -- Edouard Gomez

A noter que le probleme concernant la compile de mozilla avec -march=pentium4 n'a pas ete resolu comme il est indique dans le changelog. J'ai effectue le test sur une nightly d'avant hier avec un gcc 3.2.1-pentium4 compile par un gcc 3.2.1-pentium3 lui mm compile par un 3.2.0-i386. Je referai le test avec un gcc 3.2.1-i386 avant de jouer du gnats. -- Edouard Gomez

Bien sûr, mieux vaut aller le voir avec une bonne dose de bonne humeur, si vous êtes dépressif, abstenez vous.

Jihaire, vu ton etat d'esprit de ses derniers jours, on se demande pourquoi t'as ete le voir alors ?

--
Edouard Gomez
"Pas taper fort"

En effet c pas tous les ans... et c plutot rare d'apres la depeche sur yahoo. Voila je dormirais plus futé :-) a defaut de gagner des XPs. -- Edouard Gomez

Il va se produire dans la nuit de lundi à mardi (du 18 au 19) un spectacle céleste rare

Il me semblait que la terre traversait l'amas des leonides chaque annee etant donne que les leonides se trouvent sur l'orbite de la terre autour du soleil.

Si j'ai tort merci de bien vouloir me le signaler histoire d'aller me coucher un peu moins con.

--
Edouard Gomez

Et on noit le canard dans la baignoire.

--
Edouard Gomez

t'inquietes je t'ai aide et te voila a -1

--
Edouard Gomez

En parlant de Carmack, il a introduit punkbuster dans la release 1.32 de QuakeIII. PunkBuster est un systeme cient-serveur ayant pour but de verifier que le joueur ne triche pas en ayant des cvars douteuses.

Petit bemol cependant, il semblerait que PunkBuster soit aussi utilise pour de toutes autres choses. J'ai ainsi ete surpris de voir quelqu'un etre banni d'un serveur urban terror 2.6 car il y avait sur le reseau un GUID/CdKey en double. Le probleme de cdkeys partagees entre utilisateurs honnetes et mechants gamerz est un probleme connu et jusqu'a maintenant seul le premier utilisateur de la clef connecte au serveur central pouvait jouer. Mais ca n'allait pas plus loin et tant mieux, car comment savoir qui est le detenteur legitime de la clef ? Bannir les gamerz OUI, mais comment les reconnaitre ?

Pour en revenir au "libre vs triche", comme il a ete dis plus tot, le proprio ne fait que retarder l'apparition de la triche mais une fois qu'elle est la... La seule vrai solution est et sera toujours de jouer sur des serveurs clean geres par de bon admins.

--
Edouard Gomez

Dans le genre vicieux, tu peux aussi t'amuser a creer un tunnel http entre ta machine au boulot et ta machine perso bien au chaud chez toi pour traverser le mechant proxy qui t'empeche de faire de l'IRC au boulot. Ensuite, tu te ssh sur ta machine a la maison via le tunnel, et tu peux enfin lancer un screen pour y mettre un irssi et un mutt... c'est du vecu :-)

PS: les proxy au boulot sainul, ca fait chier, puis tout le monde se retrouve a tunneler ses coms via http... bref, le proxy ne sert plus a grand chose.

--
Edouard Gomez