[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Qt licensing issues for GNUmed

From: Tim Churches
Subject: [Gnumed-devel] Qt licensing issues for GNUmed
Date: 10 Aug 2003 11:31:45 +1000

There was discussion at the recent about developing a
Qt-based interface for GNUmed. On reflection, I think there are a number
of licensing issues which need to be considered. I mentioned these
issues to both Horst and Ian yesterday at the GPCG conference.

1) Use of Qt/X11/MacOSX (GPLed licensed, free for developer and runtime)
with PyQt for Qt/X11/MacOSX (Python bindings for Qt, GPL licensed when
used with the GPLed version of Qt) with GPLed GNUmed code is not a
problem. However, copyright of GNUmed code needs to be assigned to a
legal entity (to avoid the prospect of being personally enjoined in a
law suit against GNUmed at some future time). If everything is GPLed or
GPL compatible (eg Python), then assignment of the GNUmed copyright to
the Free Software Foundation (FSF) is the best idea.

2) However, the only GPLed version of Qt for Windows is Version 2.3,
which is now a bit old (the GPLed version of Qt for other platforms is
up to version 3.2). So, if a GPLed version of GNUmed using Qt for
Windows is desired, then GNUmed will be forced to use increasingly
ancient versions of Qt on all platforms, and/or be forced to manage
increasingly tricky configuration problems between the Linux/Unix/MacOSX
version (using tyhe most recent release of Qt) and the Windows version
of GNUmed (stuck with Qt 2.3). Yuck!

3) The alternative is for GNUmed to acquire at least one license for Qt
for Windows (Enterprise edition with the database bindings) - at a cost
of about AUD$4000, plus at least one commercial license for PyQt - at a
cost of about AUD$500. Now both of these could only be installed on a
single machine, but they permit the free distribution of the Qt runtime
files (and the PyQt Python bindings to same) as part of an application.
Some entity needs to hold the copyright for this Windows version of
GNUmed, and that couldn't be the FSF because the GPL can't be used for
the Windows GNUmed code, since it would be linking against the non-free
Qt and PyQt libraries.

Thus, as I see it, a Qt-based version of GNUmed for Windows would need
to be licensed under a non-GPL license to allow its use with these
non-GPLed versions of the Qt runtime libraries and the commercial
version of PyQT. That's not a fundamental problem, because the GPL
permits dual-licensing by the original copyright holder. However, if the
copyright for GNUmed is vested in the FSF, then there is a problem,
because the FSF won't consider such dual licensing for anything for
which it holds the copyright (Richard Stallman is a stubborn bastard,
and I think it is fruitless to even ask...). So, if 3) is to happen,
then an alternative license needs to be used, and some entity other than
the FSF needs to hold the copyright to both the GPLed and non-GPLed
(Windows) versions of GNUmed. 

So the mere fact that no-cost, freely-redistributable up-to-date
versions of Qt runtimes for Windows are available (if you have paid for
a developers license) does not solve all the problems of using Qt as a
GNUmed interface. Having a Windows version of GNUmed is, of course,

Perhaps I am seeing problems where none really exist. But these issues
need to be resolved ASAP before anyone invests effort into Qt. But Qt
3.2 does certainly look nice...

Tim C

PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere
or at
Key fingerprint = 8C22 BF76 33BA B3B5 1D5B  EB37 7891 46A9 EAF9 93D0

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]