Re: Debian i386 freeze
> after not having acess to e-mail all weekend (ISP problems) and trying to
> catch up....
> Ok this seems to be my major problem with this discussion...
> I personally don't see the problem...because KDE itself is GPL...qt is
> My question is this: can I wrire a progeam for Windows and GPL it?
> I can GPL my code...but it needs to be linked against proprietary libraries..
> I certainly can't garauntee the source to M$ or Borland library
>From the GPL, Section 3:
# However, as a
# special exception, the source code distributed need not include
# anything that is normally distributed (in either source or binary
# form) with the major components (compiler, kernel, and so on) of the
# operating system on which the executable runs, unless that component
# itself accompanies the executable.
Since the MS and Borland libraries, and associated interface files, are
normally distributed with the compiler (by definition, a "major
component"), you could use them.
What is questionable is if you could ship your program with proprietary
MS or Borland DLL's, or must only use the ones that ship with the OS.
> I don't see how this is any different? Should we be warning the
> people who port Moonlight Creator to Windows that they may be
> breaking M$ or Borlands licence by distributing their binaries?
The problem is that Qt does -not- ship normally with the major
components of Linux, so that it doesn't fall under the same special
The same situation applies to Motif. GNU Emacs is all set to compile
and run using Motif widgets. The code is already there. All that
needs to exist is for a build-time option to be chosen, and Motif to be
available. The FSF, however, has held the position that since SunOS
and other commercial Unix ship with Motif libraries in the base system,
it is OK to distribute GNU Emacs pre-compiled for Motif on those
system. Since Linux does -not- normally ship with Motif libraries,
Motif-enabled GNU Emacs binaried for Linux are not allowed.
> As far as I understand it...the program does not contain any actualy qt code...
> it is just linked against the library. It simply contains calls to qt code.
> anyone assuming that because a program is under one licence then
> the libraries it interfaces are also under that license.
The executable contains lots of Qt code. I don't think it matters when
the final link is made -- at run-time or at compile time -- the
executable contains Qt code.
Otherwise, it would be trivial to circumvent the GPL: put the
proprietary code in a shared library, and link it at run time. The
GPLed portion doesn't contain any actual proprietary code, it's just
linked against the library.
Buddha Buck email@example.com
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacaphony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com