The Qt XInput Extension is a C library adding support for XInput devices (like tablets or joysticks) to Qt-based X11 applications. QXi supports devices with up to six valuator axes in absolute mode, up to 32 buttons, and any number of keys. It is built using autoconf and libtool, and comes with a simple example application.
Has anyone read the license at all?
In my experience (from Slashdot and elsewhere, including this thread), 95% of the people who complain about the QPL have no idea how silly the actual problem with it is.
You see, the one point in the QPL that makes it incompatible with the GPL is the provisions that changes to the QPLed body of code must be distributed as patches to said body of code. Apart from that, the QPL is so close to the GPL in intent, if not in wording, that it might just as well BE the GPL.
You don't believe me, right? Well, go and read the licenses. To make it even easier to understand, here's a couple of scenarios:
You have obtained a GPLed or QPLed library (say, GDBM, or Qt).
Scenario 1: You want to write an open-source application using the library. No problem here. If you use the QPLed library, you can choose any license as long as it complies to the open-source definition, except for the GPL. If you use the GPLed library, you have to use the GPL. If you want to sell the result, WITH source code, go straight ahead.
Scenario 2: You want to modify the library and distribute it (port it, for example, or fix a bug). No problem here, either. In case of the GPLed library, your changes have to be under the GPL. In case of the QPLed library, your changes have to be under the QPL, and if you distribute them, you must do so in patch for. Not too difficult in these days of CVS. If you want to sell your work WITH source code, go straight ahead.
Scenario 3: You want to take code out of the library, and incorporate it into your own program/library/whatever. No problem here. If you take code from the GPLed library, the result must be GPLed. If you take code from the QPLed library, the result must be QPLed. If you want to sell the result WITH source code, go straight ahead.
Scenario 4: You want to do any of the above, and distribute the result, but you don't want to share the code with others. Well, you can't, in either case. You'll have to contact the library's author(s) and negotiate a licence exemption. Qt comes pre-negotiated, so to speak. You pay a one-time fee, and that's it.
As you can see, the two licenses are about as close as you can get. The intent of both is to make sure that everyone "plays nice", i.e. shares with others if you share with them. The problem is the patch clause, and this problem does not touch the intent of the license, but is rather a mere technicality. Not even RMS should be able to get truly all worked-up about this, right?
Now, given the above, what's the REAL problem? I can only speculate here, but it seems to me that even a GPLed Qt wouldn't satisfy the needs of those behind this constant bickering. What they REALLY seem to want is an LGPLed Qt, just like they have an LGPLed GTK. In other words, they want to bully Trolltech into giving their work away, even for closed-source development.
So much for the spirit of GNU, huh? Mark my words: the day that Eazel or Miguel's company come up with their particular version of "Sendmail Pro", you'll see the light. The threat hails not from Norway; the threat - if you see one - is the LGPL.