-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 02 May 2002 04:21, David Faure wrote:
 On Thursday 02 May 2002 12:12, Simon Josefsson wrote:
 > 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> 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.
 The KDE port to Windows uses cygwin AFAIK - i.e. *not* Qt/Windows. 
	So here we go again, if KDE under windows doesnt use Qt, and if cygwin is 
GPL'ed then it would  be ok to do a kpart, natively in KDE Api, if youre 
inside a unix system, you link with Free software (including Qt) and if you'd 
happen to go inside windows youre still linking with Free software (except 
any windows dlls i dont know about this with cygwin) and youre not seeking 
for Qt non-free....
 > > 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.)
 IANAL, please contact pour(a)kde.org for any precise licensing questions
 (although this one might be a more general GPL issue). I don't know,
 I was simply correcting your statement that KDE is linking to openssl.
 > Maybe turning emacs into an XPart is the way to go.
 Sounds great to me, if you get this to work. I'd give anything (err, almost
 ;) for an XEmacs part in kdevelop. 
	But as you said, XParts is still not fully operational and i would like more 
a KPart xemacs that a xpart....
	Ive thought of making first a qt port of xemacs and from there it would have 
been easy to get a kpart, in an email send before someone said it was ok with 
rms to link *ONLY* with qt GPL'ed, that the configure test was a good 
idea.....
	Id also give almost anything :) for a xemacs part for kdevelop, a great 
fusion it would be !!!!! but so what would be ?? a qt port first ?? then 
kpart ? or go out for a kpart ?? some people have show me their interest on 
these....
	Regards...
- -- 
rcm.
rcm(a)gmx.co.uk
GPG Public Key: 
http://ada.fciencias.unam.mx/~rconde/rodolfo_gpg.txt
ICQ 118193727
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see 
http://www.gnupg.org
iD8DBQE80dD8x2Sktruwba0RAuXHAJ9Bo+ok7WMyOjFNF9KuptSbbedq6QCfeghE
8H/lEyLP2zYaneDidZT0y2M=
=wzjR
-----END PGP SIGNATURE-----