KDE license (was: redhat need not apply)
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
--
Reply to: