Arnt Gulbrandsen wrote: > The key is in an earleir paragraph. > > These requirements apply to the modified work as a whole. If > identifiable sections of that work are not derived from the > Program, and can be reasonably considered independent and separate > works in themselves, then this License, and its terms, do not > apply to those sections when you distribute them as separate > works. > > In my opinion, Qt is not a section of KDE, it is not derived from the > KDE and it must be considered independent and separate from the KDE. > In other words: The KDE's usage of the GPL does not cause the GPL, and > its terms, to apply to Qt.
So, in your opinion, a library (QT) that is dynamically linked to an application (KDE) is not a part of that application? If I got you right why do your company state (on your QT Free Edition FAQ 5) that you can't link a non-GPL'ed application to a GPL'ed library? I think that is inconsistent, either the library is part of the application (both have to be GPL'ed) or it isn't (both don't have to be GPL'ed). >From section 3 of GPL (i've capitalised the important part): For an executable work, complete source code means all the source code for all modules it contains, plus any ASSOCIATED INTERFACE DEFINITION FILES, plus the scripts used to control compilation and installation of the executable. Doesn't that mean that if I distribute an executable dynamically linked with QT under GPL, I also have to distribute the QT header files under GPL. But maybe I can (I haven't read the QT Free Edition License), maybe you can enlighten me. So if I can't distribute QT header files under GPL, GPL'ed applications can't be linked with QT. Right? Mattias Evensson