Qt-interest Archive, March 2002
KDE, Qt, and licensing
Message 1 in thread
Okay, maybe I'm just a little tired today and that's
why this doesn't make sense to me. But, I'll ask it
anyway.
Qt is dual licensed. If I don't purchase a commercial
license, then any software I release has to be
released under the GPL. True? If that is the case,
what about KDE? Isn't KDE released under the LGPL?
If that's the case how come I can't release my
software under the LGPL? How come KDE isn't violating
Trolltech's licensing scheme?
I'm willing to accept that I am a bit in the dark
concerning licensing/GPL/LGPL/etc. Could someone shed
some light on this one for me? Thanks!
SN
__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/
Message 2 in thread
On Wed, 6 Mar 2002, Steven Nakhla wrote:
> Qt is dual licensed. If I don't purchase a commercial
> license, then any software I release has to be
> released under the GPL. True? If that is the case,
> what about KDE? Isn't KDE released under the LGPL?
The KDE libraries are under the LGPL, yes.
> If that's the case how come I can't release my
> software under the LGPL?
You can. You just can't use a more restrictive license than the GPL.
Just don't forget that KDE (or your software) links to Qt, so anyone
using it must comply to *both* your license and the Qt license.
e.g. you can write a proprietary KDE application, but you'll need the
commercial Qt license to do it (and you must comply with the LGPL for the
KDE libraries, meaning, mostly, no static linking).
LLaP
bero
--
[ signature omitted ]
Message 3 in thread
> The KDE libraries are under the LGPL, yes.
>
> > If that's the case how come I can't release my
> > software under the LGPL?
>
> You can. You just can't use a more restrictive license than the GPL.
> Just don't forget that KDE (or your software) links to Qt, so anyone
> using it must comply to *both* your license and the Qt license.
>
> e.g. you can write a proprietary KDE application, but you'll need the
> commercial Qt license to do it (and you must comply with the LGPL for the
> KDE libraries, meaning, mostly, no static linking).
>
Static linking under LGPL is ok if you provide access to the source to the
LGPL library, e.g. via a web link, isn't it? e.g. say I wrote a game using
the LGPL SDL library, then as long as I provided access to both my game
source and the SDL source on my webpage, I could provide a static
executable for the convenience of end users, particularly on Windows where
people are unused to building from source, and in any case compilers
don't come free with Windows?
Nick
Message 4 in thread
Nick,
> Static linking under LGPL is ok if you provide access to the source to the
> LGPL library, e.g. via a web link, isn't it? e.g. say I wrote a game using
> the LGPL SDL library, then as long as I provided access to both my game
> source and the SDL source on my webpage, I could provide a static
> executable for the convenience of end users, particularly on Windows where
> people are unused to building from source, and in any case compilers
> don't come free with Windows?
My, that would be nice! But its not correct. The reasoning from RMS
works like this. If you use an LGPL library, then bug fixes in the
library should be immediatly available to users of your software. In
order for this to work, your closed source app has to be dynamically
linked against the LGPL'd library. So the user can upgrade the version of
the library they're using by replacing the dll/so. This assumes of course
that the new library version is binary compatible.
Now, you can link dynamically against the LGPL library, and distribute the
DLL to go with at as part of your install. But you have to make sure you
document that you are using that library, and where to get the source code
for it.
---
Geoffrey Wossum
Project AKO - http://ako.sf.net
Message 5 in thread
The Giant Hogweed Homepage: hogweed.html
On Thu, 7 Mar 2002, Geoffrey Wossum wrote:
> > don't come free with Windows?
>
> My, that would be nice! But its not correct. The reasoning from RMS
> works like this. If you use an LGPL library, then bug fixes in the
> library should be immediatly available to users of your software. In
> order for this to work, your closed source app has to be dynamically
> linked against the LGPL'd library. So the user can upgrade the version of
> the library they're using by replacing the dll/so. This assumes of course
> that the new library version is binary compatible.
I wasn't thinking so much about closed source apps, I was thinking about
the case of a Windows app written using an LGPL library. This might be
typically distributed as a self extracting executable allowing the option
of installing a statically linked executable plus source if required.
There would also be a link on the app's website to the LGPL library's
source.
Now by my reasoning, you could still distribute a static executable as
long as you provide your source too, as anyone who wanted to recompile
your app against an updated version of the library could simply install
the app source, download the source of the new version of the library and
go.
If anyone has got any objections to that, then to be quite frank they
don't seem to have any concept of the desire to keep downloads for 56K
modem users to a minimum. A full DLL compared to a static executable is
just wasteful.
Nick
Message 6 in thread
> I wasn't thinking so much about closed source apps, I was thinking about
> the case of a Windows app written using an LGPL library. This might be
> typically distributed as a self extracting executable allowing the option
> of installing a statically linked executable plus source if required.
> There would also be a link on the app's website to the LGPL library's
> source.
I misunderstood. This is perfectly acceptable.
> If anyone has got any objections to that, then to be quite frank they
> don't seem to have any concept of the desire to keep downloads for 56K
> modem users to a minimum. A full DLL compared to a static executable is
> just wasteful.
For windows applications, I prefer to distribute applications that are as
statically linked as possible. I don't think the tech support where I
work could handle tracking down DLL and OCX problems on a customer's
computer. And if tech support couldn't figure out, guess who the call
would get transferred to ;)
The one exception I make is I dynamically link to Qt. There's not likely
to be version conflicts, since the copy of qt-mtXXX.dll is probably the
only one a customers computer will have, plus I install to the same
directory my .exe's are installed to, rather than putting it in
%WINDOWS%\system or something stupid like that. I used to statically link
to Qt as well, but with Qt 3.x you have to dynamically link to get plugin
support, which is required for accessibility features and Windows XP
theming.
---
Geoffrey Wossum
Project AKO - http://ako.sf.net
