-----BEGIN PGP SIGNED MESSAGE-----
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
> > > >
> > > > 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
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
GPG Public Key: http://ada.fciencias.unam.mx/~rconde/rodolfo_gpg.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----