Ray rote, > > that is essentially the GPL with an additional clause that it can be > > linked with Qt.
... > > The KDE people need to track down the authors of the GPL code that much of > > their project is based on, though, to get permission to use it under the > > new license. > I suspect authors of GPL-ed code would more readily go along with a > GPL-except-linking-with-qt-is-ok license than with a change to a wholly > different license. Although I need more data to comment on KDE, this is very likely the case already for their own (non-third-party) code, in spite of any claim of GPL. We went into this in depth with LyX, and concluded that lyx was never truly GPL in the first place. I've written at length about this elsewhere (check for Lyx License in dejanews in gnu.misc.discuss), but it comes down to the author's actions being inconsistent with the purported license, and the specific (actions and requests) overrides the general/boilerplate (the GPL). However, the lyx code is stubstantially all (all?) developed by lyx, and my understanding is that this isn't even close to the case for KDE. The real question is whether lyx could be taken under actual GPL with the linking & dependent -source clauses, or whether it's stuck without permission from all contributors. I expect that there is implicit permission to release under the purported license rather than the actual license, but I won't be sure without some research, and that won't happen unless someone pays my retainer :) However, as a starting position, and not legal advice, I suspect that the original work by KDE is quasi-GPL as you describe, and the applications are violations of the licensing for the original applications. But I won't be following this up with research, either--I use lyx daily, and occasionally write code for it, but I have absolutely no use for a GUI set; all I want is plain old X, xterms, an the ability to launch x applications from scripts or xterms. rick --
