This failed to build for me:

g++ -Wl,-O1 -o qjoypad axis.o axis_edit.o axisw.o button.o button_edit.o buttonw.o event.o flash.o icon.o joypad.o joypadw.o joyslider.o keycode.o layout.o layout_edit.o main.o quickset.o getkey.o trayicon.o trayicon_x11.o moc_axis.o moc_axis_edit.o moc_button.o moc_button_edit.o moc_flash.o moc_icon.o moc_joypad.o moc_joypadw.o moc_keycode.o moc_layout.o moc_getkey.o moc_trayicon.o     -lXtst -lQtGui -lQtCore -lpthread 
/usr/bin/ld: trayicon_x11.o: undefined reference to symbol 'XSetWMHints'
/usr/bin/ld: note: 'XSetWMHints' is defined in DSO /usr/lib64/libX11.so.6 so try adding it to the linker command line
/usr/lib64/libX11.so.6: could not read symbols: Invalid operation
collect2: ld returned 1 exit status

A scratch build is at http://koji.fedoraproject.org/koji/taskinfo?taskID=2575095

Please clear the Whiteboard if providing packages which build.

Spec URL: http://akahl.fedorapeople.org/qjoypad.spec
SRPM URL: http://akahl.fedorapeople.org/qjoypad-4.0.0-2.fc13.src.rpm

Changes:
- updated spec to latest standards                                                                                                                                                                                                          
- replace occurences of my former corporate email address
- added libX11 to linker list

Cleared Whiteboard.

Is there any reason not to update to 4.1?

None, my bad - I just didn't bother checking for a new version.

Spec URL: http://akahl.fedorapeople.org/qjoypad.spec
SRPM URL: http://akahl.fedorapeople.org/qjoypad-4.1.0-1.fc13.src.rpm

Changes:
- update to 4.1.0
- added symbolic link for suitable default icon

FYI, you don't need %clean at all these days.  (F12 was the last Fedora release that needed it, and F12 is closed to new packages, so....)

Unfortunately manipulation of %buildroot in %build is a guideline violation.  rpmlint complains about it:
qjoypad.src:35: W: rpm-buildroot-usage
  %build test -d $RPM_BUILD_ROOT || mkdir -p $RPM_BUILD_ROOT
qjoypad.src:38: W: rpm-buildroot-usage
  %build ./config --prefix=%{_prefix} --install-dir=$RPM_BUILD_ROOT

I believe it suffices to simply call the config script twice; once in %build without --install-dir and again in %install with --install-dir.  This seems to result in an identical package.

I installed and ran the package and it seems to work but I have no joypads (nor can I understand how anyone uses those uncomfortable things).

Ha, you're right. Calling config twice did the trick.
I'm quite surprised you consider joypads uncomfortable (I'm mostly a keyboard hacker myself).

Spec URL: http://akahl.fedorapeople.org/qjoypad.spec
SRPM URL: http://akahl.fedorapeople.org/qjoypad-4.1.0-2.fc13.src.rpm

Changes:

- eliminated %%config altogether
- split up into two config calls in order to prevent breaking the guidelines                                                                                                                                                                
  regarding use of $RPM_BUILD_ROOT

Looks good, thanks.  However, the licensing issue looks a bit bizarre and that may require 

I note that the source code doesn't include any sort of GPL header.  That plus the presense of the generic GPL text implies that any version of the GPL applies, so GPL+ would be the correct license tag.  However, README.txt says:

   Check  out  LICENSE.txt or http://www.gnu.org/licenses/gpl.txt
   for  details!  The  bare  bones  of  it  is,  this  program is
   distributed  in  open-source  form so that others may share it
   freely,  learn from it, or modify it as they see fit. However,
   under no circumstances can it be sold!

which demonstrates some pretty weak understanding of the GPL; whoever wrote it didn't even read the second paragraph of the preamble.  I would assume that this is merely (rather poor) explanatory text and that it's not attempting to add an additional restriction to the GPL, because that would render the whole undistributable.  However, I'm not a lawyer, so perhaps the legal folks should take a look.

And, finally, there's this:

   This  code  was  written entirely by Nathan Gaylinn (excepting
   the  code used for displaying a tray icon that is adapted from
   the  Psi source [http://psi.affinix.com/]) but is based on the
   idea of xjoypad by Erich Kitzm<FC>ller.

My understanding is that Psi is GPLv2+.  However, I don't know exactly which code came from Psi, or if it's sufficient force GPLv2+ on the whole work.

So, at this point I'd approve this, but we should see what the legal folks have to say.  Or you could perhaps try to obtain clarification from upstream.

* source files match upstream.  sha256sum:
  b5aa088827a6f7231e43e45fb942917e3f677ef933109a7b41e13a6b443c95ca
   qjoypad-4.1.0.tar.gz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
X license situation is confusing.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* package builds in mock (f14, x86_64).
* package installs properly.
* debuginfo package looks complete.
* rpmlint has acceptable complaints.
* final provides and requires are sane:
  qjoypad-4.1.0-2.fc14.x86_64.rpm
   qjoypad = 4.1.0-2.fc14
   qjoypad(x86-64) = 4.1.0-2.fc14
  =
   libQtCore.so.4()(64bit)  
   libQtGui.so.4()(64bit)  
   libX11.so.6()(64bit)  
   libXtst.so.6()(64bit)  
   libgcc_s.so.1()(64bit)  
   libgcc_s.so.1(GCC_3.0)(64bit)  
   libstdc++.so.6()(64bit)  
   libstdc++.so.6(CXXABI_1.3)(64bit)  
   libstdc++.so.6(GLIBCXX_3.4)(64bit)  

  qjoypad-debuginfo-4.1.0-2.fc14.x86_64.rpm
   qjoypad-debuginfo = 4.1.0-2.fc14
   qjoypad-debuginfo(x86-64) = 4.1.0-2.fc14
  =
   (none)

* no shared libraries are added to the regular linker search paths.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no generically named files
* code, not content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no static libraries.
* no libtool .la files.
* desktop files valid and installed properly.

I've notified the authors and asked for clarification. Let's see what their response is before going any further.

Any feedback from upstream?

Well, it's been very nearly 18 months since the authors were notified; is there any chance of making any progress here?

Looks like this is dead.