A copyright license is permission by a copyright owner to do something that he has a legal right to stop you from doing, such as make a copy or a derivative work. What it means to be a public license is that it is offered to the public, as opposed to the copyright owner offering it to particular persons he knows about.
The GPL lets you do almost anything with the code -- it's almost like the copyright owners waiving all their copyright rights. But not quite: there are strings attached. The license has conditions. In order to have the permission, you have to meet the conditions. The condition we care about here is one of two things, or both, depending on how you read the license document (the document is ambiguous). Either a) if you distribute a derivative work of Linux, you have to supply source code for the whole derivative work; or b) if you distribute a work containing Linux, you have to supply source code for the entire work.
Now we come to the real question: what sort of rights do you have to distribute an LKM you wrote?
Certainly, many people believe that you can distribute an LKM under any terms you like, including binary-only and the owners of the Linux copyright have nothing to say about it. You're distributing nothing but your own code. And it's not a derivative work of anything. Many people do distribute binary-only LKMs and believe that a principle benefit of LKMs is the ability to do that.
Others think differently: The LKM, while an original work, is a derivative work of Linux. The Linux copyright owners have the right to control distribution. The only permission they gave you to distribute it is GPL, and that permission is only under the condition that you supply source code.
Let's look a little closer at the issue of whether an LKM is a derivative work of Linux. The argument in favor goes that writing an LKM is like writing a supplemental chapter for a novel. We know the latter is creating a derivative work. The LKM is like the chapter because it's specifically designed to be part of a whole with the existing Linux kernel. It has no use in any other context, and when deployed, is tightly woven into the rest of Linux. The fact that you typically use a bunch of Linux header files to compile it is proof that it's just an extension of Linux (don't confuse this with another argument -- that the #include actually means you're distributing that header file inside your object code). And note that a kernel module loaded at run time is essentially the same program you would statically bind into the base kernel if you chose to go that route. If writing a module for the Linux source tree is creating a derivative work, then so must be writing an LKM. LKMs often have to be updated to conform to updates the base kernel.
Wasabi Systems, a company that sells kernels with freer licensing than Linux, has published a paper that argues in more detail that LKMs are derivative works of Linux and you should therefore be wary of publishing binary-only LKMs for it.
The argument against says that an LKM is something that interacts with Linux, not something that is part of Linux. It likens the LKM to a user space program, communicating with the kernel via system calls, or an FTP client program (which would not be a derivative work of any FTP server program).
The issue also runs into one of those areas where books and computer programs aren't analogous because a computer program does something, whereas a book just communicates an idea to a person. Loading an LKM might be more like plugging an attachment into your vacuum cleaner than like inserting pages into your book. And we know that the blueprints for a vacuum cleaner attachment are not a derivative work of the blueprints for a vacuum cleaner.
So that's as far as I can go. There appears to be a matter of degree here and a judge will have to draw a line somewhere.
But if you need to make a practical decision, consider that there have been well-known binary LKMs (drivers for Nvidia video adapters seem to be the most famous) for years and no one has sued
