Re: Qt Xemacs ??

On Thursday 02 May 2002 10:08, Simon Josefsson wrote: > On 2 May 2002, Stephen J. Turnbull wrote: > > > >>>>> "PB" == rendhalver <rendhalver(a)xemacs.org&gt; writes: > > > > PB> i was under the impression that you do need to use qt for KDE > > PB> apps or is there some kind of funky abstraction thingy which > > PB> lets you get around it some how ?? > > > > You do probably _link_ (indirectly) to Qt (see below). But what these > > guys are saying is that XEmacs probably only needs to do #include > > <kde/kpart.H>. Since KDE is already GPL, they have already taken care > > of the legal issues. (NB. If they got the legalities wrong, rms > > would make us a codefendent with KDE anyway. ;-) > > Even if KDE has an exemption for linking with QT (which I assume it does, > since someone ported KDE to Windows, I believe), XEmacs would also have to > have the exemption (which it won't have, from what I gatter). KDE links > with OpenSSL, so I don't think we should trust them to do the legalities > right. You are very mistaken when it comes to licensing issues in KDE, I'm afraid. 1) KDE has no exception for linking with Qt. Qt *is* GPL, for god's sake.

2) KDE does not link with openSSL (anymore). We dlopen it.

> To do a KPart, XEmacs need to link with Qt, so the license issue is always > present. Not necessarily. You could use XPart, which is an out-of-process component model, in which the component doesn't need to link Qt - it simply uses DCOP to communicate with the embedding application. You can find XPart in KDE's kdebindings module. However be warned that this technology was developed as a proof of concept only, it surely needs some polishing before being fully operational. The KVim guys first started using XPart, and are now back to an in-process component, I'm not sure what the exact issues were.