Martin Konold, suite à The aKademy, viens de proposer un nouveau composant logiciel nommé RuDI. Son but est de permettre l'intégration de n'importe quelle application dans n'importe quel bureau et ceci indépendamment du langage utilisé. Il s'agit ici aussi d'enlever toute liaison entre l'application et les librairies de l'environnement de bureau, donc plus de problème d'incompatibilités du à un changement d'API.
On pourrait imaginer ici n'avoir plus qu'une version de OpenOffice pour GNU/Linux, qui nativement, suivant l'endroit ou elle s'exécute (kde, gnome, autres), sera capable de s'adapter : boite de dialogue kde, gnome ou native.
Cela est aussi un gros avantage pour les applications propriétaires qui s'intègrent souvent peu dans les environnements du bureau.
http://www.kdedevelopers.org/node/1398(...)
http://www.kdedevelopers.org/node/1407(...)
Journal RuDI, Intégration avec n'importe quel Bureau?
4
sept.
2005
# L'avenir nous diras mais...
Posté par un_brice (site web personnel) . Évalué à 3.
À mon avis le fait d'intégrer certaines applications clefs aux différents bureaux nécessiterais un travail sur chaque application. Ce projet peut certainement faciliter ce travail, mais pas le remplacer.
Pas sûr (et tant mieux ?) : de mon point de vu de naïf ça n'apporterais pas grand chose dans le cas de KDE, parce que pour pouvoir développer une application KDE propriétaire il faudras payer la licence de QT (KDE lui même est LGPL, mais QT est GPL). Et même dans ce cas, si on utilise les boites de dialogues on utilise KIO, donc kio_kded et par là même hal, qui est sous GPL...
Je suppose que le même "problème" se pose en d'autres endroits sous Gnome (puisqu'il utilise hal) et KDE.
[^] # Re: L'avenir nous diras mais...
Posté par gnumdk (site web personnel) . Évalué à 2.
>perturbent pas), ça changerais pas grand chose.
Ben, non, c'est vrai que c'est pas du tout perturbant pour un utilisateur d'aller dans /media dans tel application, media:/ dans une autre, le tout avec 15 boites de dialogues différentes...
Après non, ca va pas transformer une appli Gnome en une appli Kde, le but est juste de garder une certaine cohérence entre les applis au sein d'un environnement particulier.
Mais une fois le look et les boites de dialogues unifiés, je peux te dire que les utilisateurs ne se poseront pas trop de question. D'ailleurs, pour l'unification du look, il y'a ce projet: http://kdelook.org/content/show.php?content=13010(...)
>Et même dans ce cas, si on utilise les boites de dialogues on utilise KIO, donc
>kio_kded et par là même hal, qui est sous GPL...
T'aurais pu aller lire l'article avant de tirer des conclusions... L'application proprio peut être écrit en Qt commercial, en Gtk, en Motif, on s'en fout, elle ne sera linké qu'avec RuDI(coté client) donc pas de problème de licence! RuDI sera lui sous licence BSD.
[^] # Re: L'avenir nous diras mais...
Posté par un_brice (site web personnel) . Évalué à 2.
Si RuDI dérive d'un QT non commercial il sera sous GPL (ou illégal). Et par hérédité, une application dérivée de ce RuDI là sera sous GPL.
Même chose pour hal. À vrai dire, hal est aussi sous la licence AFL, qui autorise les links propriétaire mais qui est incompatible avec la GPL/LGPL, donc avec les licences de KDE et Gnome. Du coup je pense que les programes dérivant d'un KDE qui dérive de HAL doivent être sous GPL.
Ça peut avoir l'air excessif, mais en fait c'est normal, après tout c'est bien la différence entre la GPL et la LGPL. C'est un choix de Trolltech/Freedesktop.
[^] # Re: L'avenir nous diras mais...
Posté par gnumdk (site web personnel) . Évalué à 1.
La librairie RuDI avec laquelle seront linkés les programmes n'aura AUCUN liens avec Qt! Les messages en XML seront gérés à travers d-bus.
Par exemple, et je dois beaucoup simplifier, Acrobat Reader dira via libRuDI: "Je veux ouvrir un fichier", un message sera envoyé via dbus et une boite de dialogue d'ouverture de fichier apparaitra.
Voila, si j'ai bien compris le principe est la, comment ca va marchait techniquement derriere, je n'en sais rien.
[^] # Re: L'avenir nous diras mais...
Posté par un_brice (site web personnel) . Évalué à 3.
Pour autant que je sache, elle ne se préoccupe pas de la manière dont sont effectués les appels : que ce soit par la pile, les registres ou le réseau... elle ne fait que la mention de "travaux dérivés". Hors ce logiciel est clairement dérivé de KDE et Gnome (et tout ce qui s'en suit), et ne s'en cache pas .
Si effectivement la GPL fait mention de détails techniques de cette sorte, je te prie de bien vouloir m'excuser. Même chose si l'auteur a trouvé un moyen ingénieux de contourner la GPL (ce qu'il semble croire effectivement).
[^] # Re: L'avenir nous diras mais...
Posté par gnumdk (site web personnel) . Évalué à 2.
>suit), et ne s'en cache pas .
Rah! Soit tu ne comprends pas le principe, soit tu ne comprends pas la GPL ;)
Si j'utilise RuDI dans mon logiciel proprio, il n'y aura pas UNE SEULE LIGNE DE CODE GPL dedans, il ne sera LIE AVEC AUCUNE LIBRAIRIE GPL (RuDI sera BSD), il ne fera qu'envoyer des messages XML à une autre entité qui elle sera sous la licence qui s'impose: GPL.
Que je sache, il est pas interdit à un soft sous licence BSD d'envoyer un message via dbus à un soft GPL?
C'est du client serveur, un client sous BSD, un serveur sous GPL.
[^] # Re: L'avenir nous diras mais...
Posté par gnumdk (site web personnel) . Évalué à 2.
The small RuDI lib which will be available for each platform (Qt/Java/KDE/gtk/Mono) shall be available with a no strings attached BSD style license in order to facilitate wide spread use.
As the coupling of a RuDI enabled application with the desktop services does neither create a derivative work nor uses any kind of linking the license used for the desktop services don't affect the RuDI enabled application.
[^] # Re: L'avenir nous diras mais...
Posté par un_brice (site web personnel) . Évalué à 2.
D-Bus est sous double licence AFL et GPL et pas BSD (bon, ça c'est lâche, mais le fait que l'auteur n'en parle pas laisse entendre qu'il n'a même pas étudié la question).
Le fait qu'il s'agisse d'un appel distant de procédure, et non pas local n'influe pas sur le comportement de la GPL.
Je vais prendre un exemple à un sujet que je connais encore plus mal : les bases de données.
MySQL existe sous GPL. Admettons qu'elle implémente des fonctionalités hors-standards, présente nulle part ailleurs et documentée uniquement dans le code source ou de la documentation copyleft. Et que ces fonctions soient rendues disponibles aux clients MySQL externes. Alors un logiciel qui utilise ces fonctions les a forcément trouvée dans le code ou la documentation copyleft. Donc il dèrive de ces éléments copylefts. Même s'il est loin.
En l'occurence, le serveur RuDI dérive du code ou de la doc de KDE (tout deux sous licence copyleft). Il est donc sous copyleft. Hors la librairie client a été conçue avec le serveur et dans le seul et unique but de se connecter à lui. Elle dérive donc de ce serveur.
D'habitude, disons dans le cas de vsftpd par exemple, c'est diffèrent car les clients dérivent des RFCs. Même chose pour la partie binaire du driver Nvidia qui est linké au kernel mais dérive d'une couche d'abstraction prétenduement prévue à la base pour les BSDs.
Mais l'auteur de RuDI a reconnu dès le départ que son but était d'exporter les fonctions de KDE et Gnome. Ainsi, son logiciel et son protocole on été crée dans ce but et dérive de ces bureaux.
Je crois que je ferais mieux d'en parler avec lui. En tout cas je regrette de ne pas avoir su t'exposer le problème plus efficacement. Tu as compris ce qui me dérange maintenant ?
[^] # Re: L'avenir nous diras mais...
Posté par gnumdk (site web personnel) . Évalué à 2.
>Hors la librairie client a été conçue avec le serveur et dans le seul et unique
>but de se connecter à lui.
Non, il n'y aura pas de connexion, juste des échanges de messages à travers d-bus.
>Mais l'auteur de RuDI a reconnu dès le départ que son but était d'exporter les
>fonctions de KDE et Gnome.
Mais ceci est totalement faux! Tu n'auras acces depuis la libRuDI à aucune fonction de gnome ou kde. Tu auras accès à des services :
-Ouvrir fichier
-Sauver fichier
-Imprimer
-Untel est il connecté?
En clair, tu ne feras que donner des ordres à une applications Kde sous GPL et elle te répondra via dbus. Je doute que tous les script DCOP qui donne des ordres à des applis Kde soient sous GPL ;)
Mais bon, de toute facon, meme si libRuDI était linké à Qt, cela ne serait pas un probleme ;)
Tu seras sans doute surpris de voir que les libs de kde sont sous LGPL et le kicker sous BSD!!! Alors qu'ils sont linké à Qt! Raison, la licence utilisé par Kde est la QPL et elle n'est pas copyleft, fin du débat :p
[^] # Re: L'avenir nous diras mais...
Posté par gnumdk (site web personnel) . Évalué à 2.
En fait, il semble que Kde utilise le Qt GPL.
"So if you want to write a non-copylefted application, release it under
the X11 license, and link it with a GPL-covered library, that is
allowed. The linked executable would be covered by the GPL, of
course, but the app source code would be covered by the X11 license
alone."
Voila pourquoi le kicker est sous BSD et kdelibs sous LGPL.
Désolé pour cette explication foireuse(QPL), mais elle était pas de moi :-)
[^] # Re: L'avenir nous diras mais...
Posté par Gof (site web personnel) . Évalué à 7.
> sont effectués les appels : que ce soit par la pile, les registres ou le
> réseau...
Donc si je crée un serveur HTTP sous GPL, seul les utilisateurs de Mozilla et Konqueror pourront visiter les sites qu'il fournit ? Et l'accès sera strictement interdit au utilisateurs de Internet Explorer sous peine de viol de la GPL ?
(Pareil pour un serveur FTP, Jabber, ...)
[^] # Re: L'avenir nous diras mais...
Posté par Guillaume Knispel . Évalué à 2.
Ca ne ressemble ni de pret ni de loin a un travail dérivé dans ce cas.
[^] # Re: L'avenir nous diras mais...
Posté par Gof (site web personnel) . Évalué à 1.
et c'est pareil pour RuDI
maintenant, prenons par exemple MSN Messenger, qui interdit, dans leur licence, d'étudier le fonctionnement du réseau
Or, les client MSN libres pour linux (dois-je les citer?) utlisient clairement le fruit de recherche et d'analyse en désassemblant le client officiel.
Si, soit disant, il est interdit de regarder les sources d'un logiciel GPL pour faire un autre logiciel, sous une autre licence, compatible avec celui-ci ; est-il permis de faire un logiciel libre compatible avec un logiciel propriétaire ?
[^] # Re: L'avenir nous diras mais...
Posté par un_brice (site web personnel) . Évalué à 1.
Raah mais c'est presque agaçant de répondre toujours là même chose.
Relis mon exemple du client spécifique à MySQL. En gros la réponse serait oui, si http était apparu sous GPL. Avant de faire l'annerie me répondre que RuDI est sous BSD, contacte moi par MP, et je t'expliquerais mon point de vue en détail au lieu de polluer ce post.
Les clients/serveurs web dérivent d'une spécification. Ce projet là a clairement pour but d'exporter les fonctions de Gnome et de KDE. S'il avait eu l'idée de prétendre que son logiciel était fait pour exporter les fonctions des toolkits en général, et ensuite avait programé un backend Gnome ou KDE, ç'aurait été discutable mais pas là.
[^] # Re: L'avenir nous diras mais...
Posté par Larry Cow . Évalué à 1.
HTTP est un protocole, pas un logiciel...
[^] # Re: L'avenir nous diras mais...
Posté par gnumdk (site web personnel) . Évalué à 8.
>KDE
Bon, t'en a pas plein le cul de raconter des conneries comme ca? Va falloir te le dire combien de fois qu'il exporte aucune fonction gnome ou kde? Que le logiciel qui utilisera des fonctions gnome ou kde sera sous GPL! Que envoyer un message à une application ca n'implique aucune licence. Les données envoyées et recus par des applications ne sont pas dépendantes de la licence du logiciel qui les envoie!
Alors une derniere fois, je te la fais en tres clair, genre si je devais expliquer à ma mere.
Application A (linké à libRuDI)
Application B (linké à Kde ou Gnome ou ...)
A veut ouvrir un fichier, A envoie un message aux services du bureau: "Je veux ouvrir un fichier de type pdf!"
B(le desktop services) ouvre une boite de dialogue et laisse l'utilisateur séléctionner un fichier. B envoie à A le path de ce fichier.
Voila, tu comprends bien la que seule B doit etre sous GPL et que le fait d'envoyer 3 lignes de XML à une applications GPL ne force pas à écrire du code GPL!
Ayé, compris?
[^] # Re: L'avenir nous diras mais...
Posté par un_brice (site web personnel) . Évalué à 0.
Merci quand même pour ton explication. Je regrette qu'avec tout le mal qu'on se donne on arrive toujours pas à se mettre d'accord.
C'est beau le respect.
J'ai furieusement l'impression que tu me prend pour un idiot. La politesse voudrais que tu tente de le dissimuler mais bon...
(Au passage l'AFL et la BSD sont compatibles, mais l'AFL étant plus restrictive c'est elle qui l'emporte, donc le soft ne peut pas être sous BSD et utiliser les librairies de D-Bus de toutes manières (sans même parler de GPL donc) - mais c'est pas le débat)
Si le protocole est mis en oeuvre en premier lieu dans un logiciel GPL et que tu déduit le protocole de la lecture du code source, alors ta spécification du protocole seras un travail dérivé, sous GPL. Même chose pour les logiciels écrits d'après cette spècification (mais pas pour les logiciels dont la comprèhension du protocole résulterait d'un reverse enginering ou d'un sniff du réseau).
[^] # Re: L'avenir nous diras mais...
Posté par gnumdk (site web personnel) . Évalué à 3.
Non, il y'a un grande différence entre être idiot et avoir toujours raison.
Si tu comprends pas que c'est chiant d'expliquer 10 fois la meme chose :(
Pour la AFL, ce que tu dis n'est plus vrai, c'est d'ailleurs pour ca qu'elle a été choisi dans dbus:
COPYING: switch to Academic Free License version 2.1 instead of
2.0, to resolve complaints about patent termination clause.
"AFL-licensed software can be used in combination with any other software, open source *or* proprietary, for any purpose whatsoever, including to create derivative works. "
"Therefore, the new AFL is identical to the OSL except that the AFL does not contain a reciprocity provision."
Ensuite, pour tes histoires de protocole, je comprend pas du tout ou tu veux en venir...
>alors ta spécification du protocole seras un travail dérivé, sous GPL.
Jamais rien vu de tel dans la GPL.
Mais bon, ce que tu dis est bidon, l'auteur du soft fait ce qu'il veut du protocole, il en fait une spec avant si il veut. De toute facon ca sera surement un truc freedesktop si ca voit le jour...
[^] # Re: L'avenir nous diras mais...
Posté par Guillaume Knispel . Évalué à 3.
Effectivement la licence n'a a priori pas grand chose à voir avec les protocoles implanté (sauf chez microsoft ces derniers temps mais comme de toute manière c'est des psycopathe leur légistes...;)
Par contre il ne suffit pas de prendre un logiciel sous GPL, de rajouter une couche (forcement GPL elle aussi) par dessus qui implante un protocole réseau ou autre permettant d'utiliser plein de bouts de code, puis de faire une appli proprio utilisant ce protocole pour feinter la GPL. En effet la notion de travail dérivé ne dépend pas de la manière dont les bouts de code intéragissent entre eux (link dynamique / statique / RPC / signaux de fumées / mémoire partagée / esclave qui fait des copié collé de langage interpreté ;) / whatever).
MAIS s'il s'agit d'une interface bien définie effectuant un travail complet bien précis (comme lancer une application, ouvrir un fichier avec l'application par défaut, que sais-je encore et non pas un mappage de chaque fonction une par une), on ne peut pas spécialement parler de travail dérivé. Par exemple rien n'interdit de faire un wrapper graphique d'un programme interactif en mode texte en dérivant les entrées sorties standard, (puisque pour faire cours l'utilisateur se sert aussi de cette interface et que l'utilisation d'un LL est totalement libre). Le problème c'est que la limite est flou, qu'on ne peut pas généraliser, et qu'on est obliger d'étudier au cas par cas.
MAIS encore lorsque qu'un LL implante un protocole bien connu, implanté par d'autres ou spécifié dans une norme, alors une appli implantant le même protocole sous d'une manière compatible avec l'appli, soit d'une manière cliente, alors la licence peut etre n'importe quoi puisque on "dérive" du standard ou de la norme, et non du spécifiquement du LL en question.
La question qu'il faut se poser, c'est si on a un travail dérivé ou une simple utilisation. La réponse est malheureusement non formalisable (par contre dans de très nombreux cas elle est très clair).
[^] # Re: L'avenir nous diras mais...
Posté par allcolor (site web personnel) . Évalué à 4.
Quand on dit des conneries faut s'avoir s'arreter quand même... tu racontes n'importe quoi, va relire la GPL et donnes-en ici le(s) passage(s) qui dit(sent) ce que tu bidonnes.
merci
[^] # Re: L'avenir nous diras mais...
Posté par ham . Évalué à 1.
Les protocols, en tant que document définissant un format binare, n'ont pas forcément la meme license que les logiciel qui implémente le protocol.
D'ailleur la GPL-o-sainte FSF a une license spécifique pour la documentation, des gens sur debian-legal deconseille la GPL pour autre chose qu'un programme,
notament a cause de la notion de "dérivé", utilisant, ... etc
SI le protocol utilisé par DBUS est GPL, avec l'intentention que tout composant qui dialogue avec autre chose en utilisant DBUS soit GPL, et bien je ne considere pas le protocol comme un standard possible. le but des protocol est tout de meme d'avoir des standanrd de communication.
d'un point de vue liberté la définition protocol sous GPL m'interdit de choisir la license de mon logiciel. Cela peut etre voulus, mais cela releve de pratique microsoftienne.
Pour ce qui est de déduire le protocol de la lecture du code GPL, on peut en chipotant, dire que l'oeuvre "document décrivant le protocol" est dérivé de l'oeuvre "code". Par contre si je prend dump ma socket et qu je réecris le protocol sans avoir vu le code, je ne pense pas que l'on puisse considérer que le document produit est dérivé du code.
Et c'est le meme protocol (en tant que suite de bit).
De meme, si tu écrit un document avec une appli GPL, j'ose espérer que le document dérivant de mon utilisation du logiciel ne soit pas GPL.
en bref, il peut y avoir un risque d'avoir, par capilotraction, la définition d'un protocol sous GPL.
Outre le fait de vouloir mettre un protocol sous GPL est hautement discutable,
cela rendrais le protocol non attractif.
C'est un peu comme si les Hippies mettais une langue sous la Hippie License, et si on veut leurs parler il faut suivre la Hippie-license qui impose de vivre dans une communauté avec des chévres (mais pas de mouton).
PS: j'ai rien contre les hippie, on peut le faire avec le sindarin qui impose de se couper les oreil en pointe, ou le language nain qui impose de boire de la biere.
# à voir
Posté par Antoine . Évalué à 2.
Il suffit de voir wxWidgets pour comprendre que l'abstraction des différentes couches graphiques, ce n'est ni facile (il y a des tas de petites différences de comportement à niveler) ni très léger (pas une "tiny lib" en tout cas ;-)). A moins que RuDI ait une méthode radicalement meilleure pour résoudre le problème...
[^] # Re: à voir
Posté par gnumdk (site web personnel) . Évalué à 3.
RuDI ne fera que donner des ordres à un gestionnaire de service. Si j'ai bien compris, c'est au desktop d'implémenter ce dernier.
En clair, ils vont développer une petit lib pour envoyer et recevoir des messages XML via dbus, ils vont définir les différents messages, et apres, le reste sera codé au niveau des différents desktop. Il ne s'agit en aucun cas d'abstraction!
[^] # Re: à voir
Posté par Sebastien Binet . Évalué à 3.
J'ai bon ?
[^] # Re: à voir
Posté par Joris Dedieu (site web personnel) . Évalué à 0.
==============> Je sort
[^] # Re: à voir
Posté par Antoine . Évalué à 2.
Et les messages XML, ils sont free-style ou il y a une définition quelque part ?
S'il y a une définition qui est commune aux différents bureaux, c'est bien qu'il y a une abstraction. Cela ne change pas grand'chose que cette abstraction soit dans le XML plutôt que dans une bibliothèque.
Et si le XML est free-style - chaque gestionnaire de bureau faisant ce qu'il veut - j'avoue que je ne vois pas du tout l'intérêt.
[^] # Re: à voir
Posté par gnumdk (site web personnel) . Évalué à 2.
Il parlais d'abstraction des librairies gnome et kde...
[^] # Re: à voir
Posté par Antoine . Évalué à 3.
Mais je ne comprends toujours pas : le XML en question correspond-il à des primitives d'interface graphique (type boîte d'ouverture de fichier, widget vue en arbre...) ? Si oui, cela revient à réécrire une API d'abstraction, mais en utilisant du XML.
[^] # Re: à voir
Posté par gnumdk (site web personnel) . Évalué à 2.
C'est juste demander à un service d'afficher des boites de dialogue et/ou de renvoyer des informations. Mais celui qui sait comment afficher les boites de dialogues, c'est le desktop service.
En clair, on définit des services que doivent implémenté les différents desktop, on les implémente dans un desktop services et on les appelle à travers dbus.
[^] # Re: à voir
Posté par Antoine . Évalué à 2.
Ok, mais définir ces services et leurs caractéristiques précises de fonctionnement, c'est bien une abstraction.
De plus :
- soit la granularité d'abstraction est grossière (juste quelques boîtes de dialogue standard) et ce système est de peu d'utilité (quel l'intérêt d'avoir une boîte d'alerte Qt dans une appli GTK ?)
- soit la granularité d'abstraction est fine (widgets, réactions au clavier, au double clic, au drag and drop...) et on se retrouve avec les mêmes difficultés qu'une couche d'abstraction : à savoir, rendre un comportement identique sur des toolkits et bureaux différents
[^] # Re: à voir
Posté par gnumdk (site web personnel) . Évalué à 2.
C'est pas de tranformer une appli gtk en une appli kde, juste que l'ouverture/sauvegarde de fichier, impression soit standard dans toutes les applis!
Mais il n'y pas que ca, enfin, il suffit d'aller lire les deux liens, y'a un schema...
[^] # Re: à voir
Posté par Joris Dedieu (site web personnel) . Évalué à 1.
Je vois un autre interet : dès lors qu'un tel systeme devient la norme (et seulement dans ce cas), les développeurs de desktop se retrouvent avec une plus grande liberté pour innover en matiere de stockage et organisation des informations. Ce qui peut ouvrir des perspectives interessantes.
J'entends par la qu'avec un tel systeme, il serait possible d'innover dans un domaine ou la compatibilité reste une nécessité absolue.
Exemple bidon :
Gimp ----> user veut ouvrir un fichier
Gimp <---- OK
KDE5.0 -----> SELECT * FROM imagettes
KDE5.0 -----> SELECT mamy92 FROM famille > blob2tmp_file
Gimp <------ user à choisi /home/user/images/mamy92.jpg
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.