The kernel source tree is GPL, so any modifications that are made to it and released must also have their source released under the GPL.
The GCC compiler is also GPL. Modifications made to the compiler itself must be released with source, as with the Linux kernel. But, a program compiled with the GCC compiler can be released under any licence. There is a legal barrier between the gcc compiler and its output. This is well-understood. This legal barrier also exists between the compiled program and any preexisting C libraries on the system, even though that program may make use of those libraries at runtime.
Most third-party kernel modules are compiled outside of the kernel source tree, and are output by the GCC compiler just like other C programs. The only link to the kernel comes at runtime, similar to C libraries. Therefore, it is accepted that a kernel module has this legal barrier, and can be released under any licence.
However, what happens when the kernel module uses API's that were intended to be part of the internal workings of the kernel, and were only exported because it was technically necessary? The system call table would be an example. It becomes a gray area in this case.
The GPL's legal barrier only applies to interfaces intentionally defined by the architecture of the software, such as an application's plugin mechanism, or a compiler's runtime library and linker. When a kernel module takes advantage of an unintended API such as the system call table, does the legal barrier still apply? This is a difficult question to answer.
For this reason, many binary-only drivers use GPL wrappers these days. The GPL wrapper is a kernel module that is open source, interfacing with the kernel without requiring for the legal barrier. The binary-only driver communicates solely by using the API presented by this wrapper, and not the kernel. The GPL only covers distribution of software, not its original authorship (the original author is always free to redistribute their software under a different licence). As both wrapper and binary-only driver are written and copyrighted by the same author, there is no licence conflict.
This seems to work well, and also has the advantage of allowing the wrapper module to be upgraded along with the kernel. When the kernel API changes, the wrapper module can be kept in sync, without needing to change the binary-only driver. Linux is known for speed and robustness because it is free to throw out old obsolete functionality that is no longer needed, something that would not be possible if a binary-only driver depended on that functionality.
I support the use of open source wrappers around binary-only drivers, and find it to be a reasonable compromise. Drivers that use this technique will not be hurt by API evolution such as this in the new 2.6 kernel.