benoar a écrit 4229 commentaires

La GPL v2 suffit, la GPL v3 ne change pas grand chose dans ce cas.
Oui, car il est important de rappeler, comme tout le monde semble l'oublier, que la GPLv2 indiquait déjà que quiconque distribue du code GPL couvert par un de _ses_ brevets devait donnait une autorisation irrévocable de l'utiliser selon les conditions de la GPL, sans restrictions.

La différence entre la GPL v2 et v3 est lors de la distribution où MS doit accorder les mêmes droit à tout le monde et ne peut pas accorder des droits spécifiques pour Novell.
Heu, je me demande ce que tu veux dire exactement par là.
Pour moi, la différence n'est pas là, puisque la v2 t'obligeait déjà à donner une autorisation à tout le monde. La v3 couvre aussi le cas où tu ne donnes pas une autorisation d'utiliser les brevets, mais où tu donnes un "droit" de ne pas être poursuivi pour violation de brevet. Ce dernier cas est donc aussi "interdit" par la GPLv3 (qui t'obliges à ne mettre aucune restriction de ce genre, ou alors tu perds tes droits à utiliser la GPL). Nuance à la con, mais qui a obligé à sortir cette nouvelle version de la GPLv3.

Alors déjà, de toutes façons aujourd'hui j'utilise déjà pleins de logiciels libres qui doivent sûrement être couverts par quelques brevets, et je m'en porte bien.

Ensuite, parler de fouilles pour vérifier si ton ordi ne contient pas de logiciels couverts par des brevets _dont tu n'as pas l'autorisation_ (parce que oui, je peux très bien avoir acheté une licence d'utilisation à leurs détenteurs), je trouve ça quand même limite exagéré, surtout quand après tu compares ça avec la contrefaçon de produits de luxe ... Excuse moi mais c'est un parallèle très foireux.

Et au fait, t'as déjà entendu parler de quelqu'un se faire pincer pour passage de logiciel sans autorisation d'utilisation d'un brevet ?...

D'accord ...
On dit toujours que l'Europe est en retard sur les États-Unis, on pourrait peut-être reprendre de l'avance en disant merde aux brevets et en implémentant les codecs qu'on veut dans nos browsers ?

Ceux qui moinssent peuvent-ils argumenter ?

Ha, si c'est du sigma design, tout ce qui est encodage/décodage doit être proprio alors.

Encore une fois, tu as fait dévier le sujet pour partir sur d'autres trucs.

Comme dit juste au dessus, le problème n'est pas vraiment le même. Et puis, pourquoi juger "acceptable" ou non qu'un soft décide d'implémenter une techno ?

D'un côté, on a des "libristes", et en particulier Novell, qui parlent d'implémenter .net et silverlight. On voit que le support est pourri (pas moyen de voir cette vidéo) mais tu soutiens dans d'autres journaux que c'est génial ce qu'il font et que c'est super qu'on ait accès à cette techno sous linux avec une implé partielle libre.

De l'autre, on a MS qui décide d'implémenter ODF avec le strict minimum. Bon.

Je dis que Mono n'est pas une bonne idée, je n'ai rien dit sur ODF dans Office.

Bref, quel rapport ?

Parce que MS joue les enculés, et que toi tu utilises des arguments à deux balles genre Office est condamne a suivre OOo pour ODF alors que tu sais très bien que l'équilibre des pouvoirs fait que ça ne changera rien pour MS.

Donc voilà, moi aussi je joue au con et oui, je trouve ça acceptable puisque MS joue la loi de la jungle, et bien nous aussi.

Bon, ça n'est pas en rapport avec la collusion B&M et MS pour la vente de licences, mais pour d'autres choses tout aussi graves (voir plus) :
http://www.latimes.com/news/nationworld/nation/la-na-gatesx0(...)
Et croire que les deux entitées sont vraiment indépendantes est assez naïf, il faudrait que je retrouve une source mais j'avais déjà entendu parler de "contrats" d'achat de licences (avec un rabais) contre l'aide de B&M pour le pays.
Rien qu'à voir comment les contrats pour les OLPC ont été cassé par MS, avec sûrement un chantage à l'intervention ou non de B&M (OK, c'est mes spéculations), moi je trouve ça dégueulasse.

"Business is business" comme dirait l'autre.

Et on ne peut pas souhaiter la mort du pape, non plus /o\

Le jour où MS galèrera à suivre ses concurrents, tu m'appelles, hein.

Allez, je me lance :
il y a des gens qui bossent sur le 1% restant.
Donc en fait avec Mono/Moonlight, on est condamné à "suivre" le developpement des technos de chez MS, en ayant pas la moitié des fonctionnalités à jour. Si c'est ça l'avenir de cette techno "libre", je préfère rester sur nos bons vieux softs (qui sont certes eux aussi à la bourre, mais au moins on dépend pas de MS).

Le contenu est effectivement là pour le côté publicitaire.
_o_

Bah moi je ne comprend pas qu'il puisse demander ça : on peut dire "je laisse mon droit à l'image si c'est sous licence X", mais je ne trouve pas ça normal de forcer un technologie en particulier (genre moi je la verrai bien en H264 + aac). Par contre, pour la plateforme, je suis d'accord, il peut refuser à apparaître sur une plateforme qui va générer de la thune sur son dos.

Et elles seront sous CC-by-nd, d'après ses souhaits. À vos trolls.

T'aurais pu essayer la commande avant de me faire la morale : non, c'est bien le /tmp local dont je parle ; ce qui est exécuté sur la machine distante est tout ce qu'il y a avant la redirection. Ton shell intercepte la redirection comme une redirection locale (de ce qui va sortir sur stdout du "sudo cat" par ssh). Et ça marche.

Il me semble que c'est une option un peu "avancée" du protocole TCP, que certains équipements gèrent mal. Mal au point de casser la moindre connexion d'une machine qui utilise cette option. Windows, par défaut, ne l'utilise pas, et n'est donc pas affecté par ce bug. Debian est juste plus respectueux des standards que ton routeur (enfin, il doit y avoir une machine buggée quelque part sur la route qui va de ta machine à internet), et comme elle exploite toutes les capacités du protocole, bah là elle s'est pris une crampe.

Sudo ne sert que pour ta machine locale : en l'occurrence, ici, ce serait juste pour avoir le droit d'écrire dans /tmp, ce qui ne doit pas servir à grand chose.

Si tu as besoin de droits spéciaux sur un fichier sur la cible pour le copier, il faudra que ton utilisateur _sur la cible_ (host1) ait le droit d'y accéder directement, sans passer par sudo. Tu peux utiliser les groupes unix, par exemple. Tout cela à cause du fait que scp lance une commande de copie directement sous l'utilisateur qui s'est connecté à la machine.

Sinon, si tu copies seulement un fichier, tu peux essayer un truc du genre :
ssh host1 sudo cat /var/tmp/file1 > /tmp/file1
Là, sudo est bien exécuté sur la machine distante, et tiens donc compte de la configuration locale à cette machine.

Si tu es motivé, tu peux aussi t'amuser à refaire un de ces paquets en enlevant les dépendances qui ne t'intéressent pas. Un coup de apt-get source gnome-desktop-environment, tu modifies debian/control, puis un dpkg-buildpackage -us -uc dans le dossier, et tu obtiens un paquet .deb fait maison.

Les Nokia N8x0 contiennent cette puce, mais aucun driver n'est fourni avec : en bref, il est inutilisé, et c'est pour ça que ces bêbêtes ont un affichage super lent ...

Et pour les DSP qui accompagnent beaucoup de ces machines, c'est pareil : la couche le liant avec le CPU est souvent proprio, et les SDK pour développer sur le DSP sont proprios et surtout pas distribués gratuitement.

Il existait déjà des soft d'obfuscation pour l'assembleur, hein. Pour moi, montrer que des obfuscateurs existent n'est pas une preuve que le bytecode est facilement lisible.

L'argument de départ était qu'une VM c'est pratique, parce qu'on est facilement multiplateforme tout en ayant une forme de code assez bas niveau. Ce qui permet de "cacher" les sources. Toi, tu dis que ce n'est pas vraiment cacher car on peut "facilement" le comprendre. Moi je te dis qu'en plus on peut l'obfusquer.

Entre obfusquer des sources pour les cacher et être multiplateforme, et faire pareil pour le bytecode, la deuxième solution est quand même vachement plus simple et efficace.

C'est ça que je comprend pas avec des gens comme toi, c'est comment fonctionne ta logique ... La rhétorique de toi et tes potes est très forte : tu disais plus haut que le bytecode n'aidait pas ceux qui voulaient "cacher" leurs sources, bien au contraire. Et là tu me dis qu'en fait, on sait déjà "cacher" le bytecode depuis longtemps. Quelle est la logique dans ton argumentation ?

Heu ... arrête ta parano, je parlais pas de toi, hein, je parlais des annonces officielles, de pBpG, et du blog de Icaza entre autres.

En ce qui concerne ton dernier argument, sache que dans la recherche en ce moment j'ai entendu parler d'obfuscation de bytecode et que ça a l'air assez à la mode et intéresse pas mal d'entreprises ... Bon ok, pour être crédible il faudrait que je trouve des sources.

Effectivement, c'est dans la FAQ :
http://www.microsoft.com/interop/cp/default.mspx#EHD
Si l'implémentation n'est pas complète, personne n'est couvert. Bref, le modèle de développement ouvert du LL n'est pas possible.

Cela n'a rien de dangereux, ca peut etre embarrassant, genant, etc... mais il n'y a pas de danger.
Oui enfin pour l'instant, ceux qui disent qu'il n'y a pas de danger sont :
1) des responsables de Microsoft
2) un employé de chez Microsoft
3) des devs de chez Novell qui ont signé un contrat avec et ont filé de la thune à Microsoft

Bref, le jour ou quelqu'un d'un peu plus neutre aura un avis positif sur la question, on y réfléchira.