djano a écrit 1147 commentaires

Question: supposons que quelqu'un livre un logiciel proprio sous forme de code source qui doit s'interfacer avec un logiciel sous GPL (cas qui nous intéresse ici), mais sans le livrer avec le logiciel sous GPL, par exemple sous forme de patch.

Lorsque le client combine le patch propriétaire avec le logiciel sous GPL l'ensemble devrait être couvert par la GPL, n'est ce pas? Dans quelle mesure le client pourrait (ou ne pourrait pas) demander a l'éditeur du patch propriétaire de lui fournir les sources?

En écrivant ça, je me rend compte que ce cas couvre aussi bien ce filesystem proprio que les modules binaires de NVidia par exemple. La différence fondamentale étant que les modules du noyau sont considérés différemment par Linus Torlvalds que les filesystem qui font partie intégrante du noyau (sauf s'ils sont utilisés via FUSE, mais les perfs en prennent un coup je pense).

Que savez vous a ce sujet?

En fait si j'ai bien compris la licence Illinois Open Source License/NCSA (licence de LLVM), le code source initialement développé sous cette licence doit rester sous cette licence puisque cette derniere stipule que le code doit conserver les conditions de la licence ainsi que son texte.

Si l'on y ajoute du code sous GPL, le travail combiné est sous GPL, mais le code source d'origine NCSA doit rester sous cette licence. Donc la distribution du logiciel sous forme binaire peut se faire sous GPL si la documentation associée au logiciel cite le copyright du code original sous licence NCSA.

Dans ce cas, faire un logiciel propriétaire doit répondre aux mêmes exigences.

Donc pour résumer, comme le dis PsychoFox, on peut bien faire un fork en GPL si le logiciel (travail combiné) contient du code source en GPL, le code source sous licence NCSA doit garder son copyright original (et la doc du logiciel doit citer ce copyright).

Je pense que seul le frontend de GCC est utilisé. C'est vraiment trop tordu autrement!!
En plus le besoin pour LLVM serait reduit: Refaire 2 fois toutes les optimisations? Faire toutes les conversions entre les formats internes de GCC? Quelle perte de temps lors de la compilation!!

clang va transformer directement le code C vers représentation intermédiaire de LLVM. Regarde le tutoriel de la création d'un front end pour avoir une idée de comment c'est réalisé.

Je pense que oui, mais ils ne peuvent pas tout faire d'un coup.
J'aurais peut être du écrire: "pour le moment il n'y a pas encore d'équivalent".

Oh non Hurd n'est pas mort!!! Il est juste en sommeil (comme les volcans, c'est a dire pour très longtemps). Je crois que le port L4 est mort pour une sombre histoire de feature manquante nécessaire a la vision Hurdienne du monde qui permettait d'autoriser certaines opérations entre serveurs Hurd et de se passer les autorisations entre eux (les capabilities).

Les devs Hurd voulaient remplacer L4 par un autre noyau, Coyotos pour lequel Jonathan Shapiro joue un grand role ( https://linuxfr.org//2005/09/26/19619.html , oui! ca date de 2005!). D'apres ce que j'avais lu, Markus Brinkmann travaille sur d'autres projets actuellement. Est ce qu'il va jamais revenir sur Hurd? Je me pose légitimement la question.

Dans une interview que j'ai lu il y a un moment, RMS disait simplement que le besoin philosophique pour le Hurd était retombé depuis que Linux avait pris sa place. Bref, RMS reconnaît que le Hurd n'est plus si utile que ça.
Maintenant s'il y a des gens qui veulent bosser dessus, ce n'est quand même pas la faute de la FSF!!
Enfin dire qu'un projet est mort arrive rarement, par contre le nombre de projet orphelin est lui assez phénoménal. Je crois d'ailleurs que la FSF recherche des mainteneurs pour certains de ces projets.

PS: non je ne suis pas dév du Hurd ni meme utilisateur.

Pour les non anglophones, dans Android, les packages spécifiques a XMPP sont renommés en des packages spécifiques a Gtalk. Une des raisons est que Gtalk n'a pas l'ambition d'être une API XMPP générique et que son implémentation future va surement utiliser un format binaire. En gros Gtalk ne sera plus une implémentation XMPP, si ce n'est pas deja le cas :,( .

Le fameux "Don't be evil" en prend un coup.

Purée, Google prend de plus en plus la voie des tenebre. C'est triste, mais cela se voyait de plus en plus.
La liste des logiciels d'IM proprio va s'allonger. C'est tres tres triste.

> Dire que si la BSD n'aurait pas existé, apple n'existerait plus.
Et? Est ce que ce serait mieux?

Mac OS X, IPod, IPhone, etc. on quand meme des succes non négligeables et ont permis de montrer au commun des mortels qu'il n'y avait pas que Microsoft, Windows et Office. ca a révolutionné pas mal de choses. Si Apple avait disparu, est ce que tu aurais connu de tels changements?

Safari (et plus encore Firefox bien sur) ont montré a nouveau la voie du respect des standards du web.

Je veux bien qu'Apple ne soit pas le meilleur allié du libre, mais de la a dire qu'Apple est totalement maléfique et que tout ce que fait Apple est merdique, il y a la un pas que je ne franchis pas et ne franchirais jamais. il faut reconnaitre ses mérites, mais aussi ses mauvaises actions. Bref, il faut rester critique envers ce qu'ils font.

LLVM + gcc doit etre compris comme LLVM + des front ends GCC. Ils ne gardent que ce qu'ils n'ont pas développé: les front ends.

Ce n'est pas parce que c'est difficilement réutilisable que tu ne peux pas le réutiliser. Simplement ca demande beaucoup plus de travail.

LLVM a existé bien avant que clang n'existe, donc pour pouvoir réellement tester et utiliser LLVM ainsi que le pousser dans ses retranchements, il fallait trouver des front ends qui servent d'interface entre le code source et la représentation intermédiaire de LLVM. Or GCC offre plusieurs front ends vraiment tres matures permettant ainsi d'utiliser LLVM avec des langages courant tels que C, C++ (celui-ci est un des front ends les plus durs a realiser), Fortran, Ada, Objective-C et meme maintenant Java.

> Pourtant gcc est le compilateur qui supporte le plus de language...
Oui, d'ailleurs c'est un vrai tour de force.
Il supporte aussi un max de plateformes et architectures. La liste dans les sources est assez impressionnante.

Il est juste dommage que le code de GCC ne soit pas plus facilement réutilisable pour écrire des outils d'analyse du code source, des outils pour la documentation, le refactoring, etc. Cela n'encourage pas à l'utiliser pour créer d'autres outils. Est ce un manque de documentation, de tutoriaux, ou bien un mal plus important tel que le manque de modularité?

C'est la que clang + llvm offre une plus grande réutilisation en offrant des librairies que l'on n'a qu'à empiler comme des briques.
Ensuite, il est vrai que la licence de llvm facilite la propriétisation du code, malheureusement, chose que la GPL n'autorise pas. Bref, c'est du Apple tout craché.

C'est pourquoi GCC devrait avoir une architecture plus ouverte pour permettre de "plugger" différentes analyse ou même réutiliser le front end indépendamment du middle end ou du back end ce qui apparemment n'est pas facile actuellement.
Ensuite rien ne leur empêche de dire que les interfaces ne sont pas figées et que ceux qui les utilise le font à leurs risques et périls. C'est ce qui se passe dans le libre, pour tous les patches au noyau, pour ses interfaces internes, ainsi que pour beaucoup d'autres projets libres. Là où le libre est très fort, c'est pour s'adapter à ces changements, alors que le logiciel propriétaire n'aime pas du tout ça:
cf Vista qui casse tous les logiciels propriétaires uniquement distribués en binaire et qui sont bons à jeter à la poubelle lors d'un changement d'OS, sauf à prier pour des patches de Microsoft ou de l'éditeur du soft qui résoudraient le problème, mais là, on peut toujours espérer.


En tout cas, longue vie à GCC et un grand merci à ses développeurs!!

> Or dans ce cas, comment un changement du frontend améliore les performance [1]. Il génère un code intermédiaire plus détaillé ?
Les notes de version en anglais, ne parlent pas d'amélioration des performances grâce au changement de front end gcc.

> On nous parle de type "long double" supporté par LLVM, mais c'est pas plutôt le boulot du frontend de supporter les types du language qu'il parse ? Après lecture des release note, la modif est bien dans llvm-gcc.
Oui pour les types propres au langage, mais il faut également qu'ils disposent d'un équivalent dans le middle end. Apparemment, c'est ce qui a été implémenté ici: un équivalent du type "long double" pour l'IR (la représentation interne) de LLVM. Ensuite, cela se traduit au niveau utilisateur par un support du type C "long double" tel qu'on l'attend de la part du compilateur.

> On nous parle pas du tout de bibliothèque rattaché au langage.
> Par exemple quelle libc llvm-gcc/clang supporte ?
http://llvm.org/releases/2.2/docs/ReleaseNotes.html#portabil(...) :
# Intel and AMD machines running on Win32 using MinGW libraries (native).
# Intel and AMD machines running on Win32 with the Cygwin libraries (limited support is available for native builds with Visual C++).
Pour linux je suppose qu'ils utilisent les librairies standard de GCC, llvm-gcc n'étant qu'un compilateur après tout.

> Ou sera l'équivalent de libgcc (qui par exemple implémente le support des flottants en soft pour les archi qui ne l'ont pas) ?
hé bien justement il n'y a pas d'équivalent:
llvm-gcc 4.2 supports CellSPU as a 'configure' target and progress is being made so that libgcc.a compiles cleanly. Notable pieces still in development include full 64-bit integer and full double precision floating point support.

Si tu enleves les liens pour les telephones portables, il y a tout de suite beaucoup moins de liens (mais il y en a quand meme).

Oui, mais tu ne sembles pas compter sur la force qui a fait le logiciel libre: le partage. Des plugins pour des formats propriétaires sont en cours de développement, et je ne doute pas que d'autres personnes s'atteleront a la fourniture de beaucoup plus de plugins. Il suffit juste d'etre un peu patient (ou de contribuer :P )

Personnellement, c'est la premiere fois que j'entends parler de ce projet, et il me semble très prometteur. la seule chose qui me chifonne c'est de savoir si ce système de fichier tient la charge avec les disque durs actuels, remplit de dizaines de gigaoctets de fichiers (au lieu de quelques megaoctets); notamment avec la fonctionnalité de recherche au fil de la frappe (traduction approximative de As-You-Type search).

Par ailleurs il faudrait peut-être réenregistrer certains sons comme « confier une tâche » et « tache » parce qu'ils ne font absolument pas la distinction entre « a » ouvert et « a » fermé (d'ailleurs pour cette exemple précis on a même l'impression qu'ils sont inversés).

Super chipoteur se dit que "a" ouvert et "a" fermé sonnent exactement de la meme maniere pour lui, pauvre provincial originaire du sud ouest (oui j'ai beaucoup souffert :,( ).

<ma vie>
D'ailleurs, il s'agit regulierement d'une source de mesententes:
- michel (michel) et michèle (michèleuh) ne se prononcent pas pareil pour moi.
- un verre et un ver ne sont absolument pas des homophones dans ma région. Ca m'a toujours perturbé cette histoire jusqu'à ce que je comprenne que tout le monde ne parlait pas comme chez moi.
- etc, etc.
</ma vie>

Je chipote, mais on dit "dans le Tarn".

Moi j'en voit bien une, mais il faut savoir comment est faite la saucisse.

Je m'y essaie quand meme, mais sans la saucisse ;) :
Prenons GCC qui est lui même composé de front ends et de back ends:
- en entrée, il accepte des programmes ecrits dans plusieurs langages de programmation (C, C++, Java, Ada, ...). Il va traduire la sémantique de ces programmes dans un format intermédiaire (commun a tous les langages). En fait, la partie centrale est commune (c'est le format intermediaire) mais la partie située en entrée (le front end) change selon le langage de programmation. Ici, le front end est est l'analyseur lexical et syntaxique.
- en sortie, il permet de compiler dans plusieurs langages: A partir du format intermediaire (commun a tous les langages), il peut générer de l'assembleur pour processeur x86, UltraSparc, PowerPC, et même du bytecode Java. A partir de la partie centrale commune, la partie réalisant la sortie (le back end) change. Ici, le back end est le generateur de code.

On voit donc bien que l'on a:
- une partie en entrée qui peut changer (celle qui "accepte" un langage de programmation en entree),
- une partie centrale toujours la meme (celle qui code la semantique d'un programme),
- une partie en sortie qui peut changer (celle qui genere l'assembleur).

J'espere que je n'ai pas embrouille les idees!

Oui et puis dans le cas hautement improbable où MS ferait un plugin ODF, je ne suis pas sûr qu'il en feraient un totalement complet qui restitue le mieux possible le document original (aussi bien en import qu'en export).

Si le format est mal supporté par Word, les gens vont se dire: "ce format est pourri" et pas "MS Word a une fonctionnalite d'import / export ODf pourrie".

oui, avec PHP.

Un petit " http://www.google.fr/search?q=uploader+fichier " te dira tout ;) !

Il faut comparer ce qui est comparable.
Les textures de Warsow devraient être comparées avec les images utilisées dans OOo telles que les icônes, le splash screen ou autres.

Et là, je pense que les images sont GPL puisque inclues dans le code source.

En fait, j'ai l'impression qu'il combine plusieurs types de logiciel:
- un explorateur de depot (CVS ou SVN) + de la coloration syntaxique. Comme CVSWeb, CVSView, ...
- un explorateur de code source, comme lxr (linux cross reference) ou comme celui qui est directement integre a eclipse (avec control + clic gauche ou encore F3). Il permet d'explorer un code source comme dans un navigateur avec des liens vers les definitions.

Combiner les deux represente deja beaucoup de travail, mais en plus cela est disponible pour plusieurs langages differents, ce qui est remarquable.

Voila ce que j'en ai compris.

Tiens je connaissais pas. Bien vu ;) .

Mes informations ne sont pas si loin de ce qui est ecrit ici, meme si ca date un peu (j'ai vu 2004) !

Bof, les engagements de confidentialité ca n'engage que ceux qui y croient. Tiens, c'est comme la politique. Les declaration d'intention, ca fait toujours bien a l'exterieur.

En tout cas, je prefere utiliser mon tableur et mon traitement de texte sur mon PC. Il va me falloir des cas tres particuliers pour en avoir besoin.

Bref, il faut vraiment vouloir s'auto-flageller pour utiliser ce service avec des données confidentielles.

La dernière fois que j'en avais entendu parler, il avaient un complexe contenant de 60.000 à 70.000 ordinateurs Dell. Des ordinateurs "classiques", comme les notres a part peut etre le format des boitiers.

Lorsqu'un PC tombe en panne, il est immédiatement debranché, et renvoyé à Dell qui se débrouille avec (Google a un contrat spécial). Ensuite, les techniciens de Google installent un nouvel ordinateur a la place.

Bien sûr ensuite, ils font un load-balancing aggressif et du cache web. Probablement avec squid un peu comme Wikimedia:
- http://meta.wikimedia.org/wiki/Wikimedia_servers , et plus particulierement http://meta.wikimedia.org/wiki/Wikimedia_servers#Overall_sys(...)
- http://meta.wikimedia.org/wiki/Cache_strategy

Lorsque Google a été lancé, le domaine des moteurs de recherche était occupé par des mastodontes tels Altavista.
Google est arrive avec une idee simple mais efficace (utiliser les liens pointant sur une page pour indiquer sa popularité), ce qui est devenu le fameux PageRank.
Yahoo en achetant del.icio.us a peut etre trouve mieux que le PageRank: utiliser les bookmarks que les internautes mettent sur ce site.

Et on n'est pas a l'abris de nouvelles avancees theoriques.
Bref, Google est actuellement tres fort, mais quelqu'un qui fournirait un meilleur moteur de recherche pourrait tres bien emporter la palme. En plus, il semble qu'il y ait de la place: http://www.up.univ-mrs.fr/veronis/pdf/2006-etude-comparative(...)

Je m'explique en prenant un exemple : J2EE. Il n' y a pas d'implémentation par Sun de serveur J2EE, juste une spécification. Les produits qui implémentent cette spécification peuvent être certifiés par Sun ce qui garanti qu'une application J2EE développée peut être déployée (simplement) sur n'importe quel serveur certifié.

Desolé de te contredire, mais il y a bien une implémentation de J2EE par Sun: Sun Java System Application Server (ou JSAS pour les intimes) [1] qui maintenant est même distribué en Open Source (CDDL) sous le nom du projet GlassFish [2].
Wikipedia en francais ecrit ceci [3]:

En juin 2005, Sun a annoncé le lancement d'un projet open-source pour créer la prochaine version de Java System Application Server dans sa version destinée aux développeurs, sous le nom de projet GlassFish

Je confirme avoir lu la même chose que toi sur la libération du code source de Jikes par IBM, et les modifications intenses que la communauté leur a apporté par la suite.

[1] http://en.wikipedia.org/wiki/Sun_Java_System_Application_Ser(...)
[2] http://en.wikipedia.org/wiki/Glassfish_Application_Server
[3] http://fr.wikipedia.org/wiki/Java_et_logiciel_libre

Natif certes, mais non libre...