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>
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.
--
David FAURE, david(a)mandrakesoft.com, faure(a)kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KDE, Making The Future of Computing Available Today