Re: Qt Xemacs ??

On Thu, 2 May 2002, David Faure wrote: > 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. Qt/Windows is not GPL, isn't the (alleged) KDE port to Windows using Qt/Windows? If so, and if the port is distributed, KDE must have an exception in the GPL saying it is OK to link with Qt/Windows. This is just speculation (I haven't seen KDE/windows), so please correct me if I'm wrong.

> 2) KDE does not link with openSSL (anymore). We dlopen it. Is this ok with FSF? The difference between linking at compile time and runtime seems like splitting hairs. But if it's OK with FSF, then it's OK... (and if so, I'd say the ban on linking is pretty useless, everyone can just dlopen() instead.)

Maybe turning emacs into an XPart is the way to go.