[Top][All Lists]

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

Re: [Gnumed-devel] Movve to Qt (was: Conference)

From: Tim Churches
Subject: Re: [Gnumed-devel] Movve to Qt (was: Conference)
Date: 14 Aug 2003 05:31:27 +1000

On Wed, 2003-08-13 at 22:44, Ian Haywood wrote:

> I think there is consensus that direct Qt database objects are too
> restrictive, and XML-RPC,
> although nice,. is (as has been said before) a post-1.0 matter, leaving
> 3/ and 1/: business objects
> bound to Qt (and wxPython if ppl are willing to work on it)

My observation as an outsider is that the GNUmed project as a whole has
lacked sufficient discipline with respect to Version 1.0 - the main
things are coming up with a specification which is necessarily
incomplete but nevertheless able to be implemented in a reasonable
timeframe, and then sticking to it. All other ideas, no matter how cool
or sexy, are put on the To-Do list for Version 1.1 or later. XML-RPC
definitely falls into that category. 

Having said that, it is fine to experiment with different ideas and test
different development technologies, but at some stage firm decisions
need to be made about which of those competing ideas and technologies
will be used to implement Version 1.0. Those decisions should be made
dispassionately, and the fallacy of "sunk costs" avoided - that so much
effort has already been expended on XYZ, if we just put in a bit more,
everything will be OK. A fairly general rule is to expect to completely
throw away the first few prototypes. 

Of course, these maxims are fine for funded projects in which people are
paid to do the work and there is usually a clear chain-of-command.
That's not the case for a volunteer open source project like GNUmed, and
the ideas in the preceding paragraph are undoubtedly too harsh and
insensitive. But hard decisions still need to be made.

> My $.02 on licensing: it is difficult to accede to demands from users of
> closed operating systems
> that we use a free GUI library on that system, nor to see what advantage
> is so offered to said users.
> (they *can* still develop, as the source remains GPL, Python is an
> interpreted language so it
> doesn't matter if the library is binary-only. Of course they need to
> switch to Linux if they want to run
> QtDesigner. Nice to see the boot on the other foot for once.)
> Qt is GPL on Linux, so purists can be GPL right down to the BIOS if they
> want.

I think that is a very reasonable position to take. However, there are
still a few details to be addressed if GNUmed code is to be dual
licensed under the GPL for non-Windows platforms, and under some other
license for Windows. Ideally, that "some other license" should be as
close to the GPL in effect (eg with respect to copyleft) as possible,
but can't actually be the GPL, and which is compatible with the GPL.
Anyone have any clues about a suitable, properly drafted license which
meets these aims? The Mozilla Public License, with the two extra clauses
needed to make it GPL-compatible, seems closest, although it implements
only "weak copyleft", not strong copyleft like the GPL. But it is the
strong copyleft in the GPL which prevents its use with non-free
libraries like Qt for Windows, so I don't think you can have both strong
copyleft and Qt for Windows without using some license which makes a
special exception for Qt. My non-expert, unsolicited advice is the
GPL-compatible Mozilla Public License (but renamed the GNUmed Public
License - it allows that) for the Windows version.


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]