Re: A simple mistake (was Re: Should we ship KDE in hamm?)
On Fri, Jul 24, 1998 at 11:50:35AM +0100, Luis Francisco Gonzalez wrote:
> Raul Miller wrote:
> > Dynamic linking is like static linking in that in either case the program
> > won't run without the library. Dynamic linking is unlike static linking
> > in that the linkage is created every time the program runs, rather than
> > every time the prgram is linked. Also, we generally do not make it a
> > practice of shipping unlinked .o files, arranging to statically link
> > them in the user's machine.
> > That's about the extent of the technological differences..
> > What you're ignoring is that we introduce a very strong association
> > between the binaries and the libraries, using dpkg. This, in
> > combination with some of the other associations (our testing process,
> > the documentation on the program, and of course the way we build the
> > package in the first place) make it very obvious that we intended that
> > qt be used to make kde work.
> Plus, in the case of C++, the header files actually *have* code not just
> prototypes so even if dynamic linking were allowed, there would still be a
> problem with mixing actual code contained in the binary and coming from a
> non GPLed source.
I have been trying to stay out of this discussion for the past few days
(1 day of followig it was plenty for me...I have deleted every subseequent
message without reading it since that date)...
Th efirst hing I wanna say is...well in C you CAN have actual code in
a "header" and #include it...but.. I was always told that is very bad form
in fact we were sternly warned against it in my C classes.
The same for c++...you shouldn't have actual code in the headers...
you can and should place them into separate source files. (I know that
does fall under codeing style...hell some people actually like using
less than 8 charicters for indents in C...no accounting for
taste I guess...but I have never seen any argument in favor of code in
xfstt (the program I maintain)...I noticed it uses the LGPL instead of the GPL
even though it is not a library itself. I am assuming this is to avoid exactly
this sort of mess that KDE is havinbg here with QT....
would that solve it? (AFIAK the LGPL is designed so that the code under it
doesn't pollute what it wants to link against...or have linked against
has this been suggested to the authors? (tho from how it sounds...they don't
seem too terribly responsive to the licencse "issues") Its really too bad
this discussion even has to happen.
(I think later when I have the time I will go back and read the LGPL...
its been a few years)
/* -- Stephen Carpenter <email@example.com> --- <firstname.lastname@example.org>------------ */
E-mail "Bumper Stickers":
"A FREE America or a Drug-Free America: You can't have both!"
"honk if you Love Linux"
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org