[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Move to Qt (was: Conference)
Re: [Gnumed-devel] Move to Qt (was: Conference)
Fri, 15 Aug 2003 18:24:33 +1000
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
-----BEGIN PGP SIGNED MESSAGE-----
Elizabeth Dodd wrote:
|On Thu, 14 Aug 2003 09:06 am, address@hidden wrote:
|>I have just joined this list.
|>I am a lawyer in Sydney running an IT practice.
|>I am interested in open source generally, and in health in particular.
|>This thread looked like something I might be able to help in relation to,
|>but I don't have its history.
|>Could someone fill me in on the reason why people a dual licence is being
|>considered for GNUmed and what the perceived gap is between the GPL
|>requirements of the "other" licence?
|At the obvious risk of getting much of this wrong.
|Gnumed wishes to be part of the Free Software Movement and to be untainted
|with 'other' code.
|There was an option discussed for a different system for producing the
|Graphical User Interface. This system, Qt, seemed to have specific benefits
|for design, especially on windowsOS. The licence for Qt code produced for
|windowsOS would have required the licencing complexity.
|The original threads are archived somewhere - I'm sure someone will
|to the beginning of the thread.
Thank God you're here. We can dispense with all that IANAL prefacing and
ask you for the right answer. :-)
Liz sums up the situation as I understand it and I have appended Tim's
original posting to this thread below.
I found Trolltech's FAQ most helpful.
There was discussion at the recent gnumed.conf.au 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...
keyserver = keyserver.medicine.net.au
pub 1024D/60067CA7 2003-07-23 David Guest (Key Current 23 July2003)
Key fingerprint = C8AA 8C22 A06F 7944 DA77 6A3B FEF9 5033 6006 7CA7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Re: [Gnumed-devel] Move to Qt (was: Conference), ju0815nk, 2003/08/13
Re: [Gnumed-devel] Movve to Qt (was: Conference), Tim Churches, 2003/08/13
Re: [Gnumed-devel] Movve to Qt (was: Conference), Tony Lembke, 2003/08/14
Re: [Gnumed-devel] Movve to Qt (was: Conference), Karsten Hilbert, 2003/08/15
Re: Re: [Gnumed-devel] Movve to Qt (was: Conference), brendansweb, 2003/08/13
Re: Re: [Gnumed-devel] Movve to Qt (was: Conference), Karsten Hilbert, 2003/08/15
- Re: [Gnumed-devel] Movve to Qt (was: Conference), (continued)