Re: On interpreting licences (was: KDE not in Debian?)

[David Johnson <djohnson@acuson.com>]

Raul Miller wrote:
> 
> On Tue, Feb 01, 2000 at 10:48:20AM -0800, David Johnson wrote:
> > I have put this opinion forth (that Qt is distinct from the
> > application and not a module) in the past, but each and every time
> > I have met with immense disagreement and vile language, so that I
> > have become "gun shy" and have refrained from stating what I see as
> > obvious.
> 
> Please don't confuse the immense disagreement with any vile language.

I haven't. I have received both.

> So treating "unlinked" code as independent works doesn't cut it, not
> when the usual practice is to use these "independent pieces" together
> on the target machine.
> 
> Copyright law doesn't grant any special excemption for dynamic linking.

Oh, but it does! I'm sorry that I can't quote the relevant law to you,
not being a lawyer or anything. But there have been court cases in the
past that have determined that APIs cannot be copyrighted. A footnote
containing a chapter or page reference is the prose equivalence to an
API. For a program, a reference to call a function elsewhere is
analogous to a footnote and the #include <qapplication.h> statement is
analogous to any entry in a bibliography.

The GPLd portions of the KDE source code, as long as it remains source
code, contains zero elements of Qt. After it is compiled into a binary,
there is only a miniscule amount of Qt code, and what there is consists
of the translated/compiled API. Anything within KDE that belongs to Qt
is easily covered under copyright law as a reference or fair use.

Now a license may impose further restrictions to the user beyond what
copyright disallows. But I don't see the GPL doing this. It only refers
to "all the source code for all modules it contains" plus scripts and
makefiles and such. I don't see Qt as being contained within KDE (except
for the API) as it is external to it. Of course, RMS (politely)
disagrees with me on this, but as it is written, it is not clear at all
that Qt is a module of KDE as defined in GPL version 2.

> [Also, there's the Objective C situation
> (where gcc mods were distributed as ".o" files and the end user was
> given instructions on how to build the modified gcc)...

Statically linking NeXT's object files into gcc in the user's private
environment is a far cry from dynamic linkage, and has little bearing
upon KDE/Qt.

David Johnson