> specifications. The driver - the part that interfaces between the
> Linux kernel and the library - is released under GPL. The library
> itself is not available in source form, but could be included with the
On the contrary. You can't GPL the driver as it is linked with a private
binary object file and violates the license of the GPL. After our discussion
I checked this viewpoint with several folks. Take it up with the FSF lawyer
if you dont like it.
However, to the extent that binary-only modules are OK --- as long as
you restrict yourself to the interfaces exported by /proc/ksyms (cf
Linus's pronouncement that dynamically loaded kernel which adhere to the
/proc/ksyms interface are to be considered the same as user programs
executing in user space --- i.e., not restricted by the GPL), it should
be OK for you to distribute a separate device driver package which did
exactly what you described, but still linked against a private .o file.
As a practical matter though, you might want to stop and ask yourself if
this is really necessary or matters. It doesn't take all that much
effort to disassemble a compiled .o file, and people who think that it
is difficult are just kidding themselves. I was part of one of two
separate teams (one at MIT, and one in Berkeley) that disassembled the
Internet Work/Virus almost a decade ago, and we did that work in less
than 12 hours. True, we were motivated, but that just means someone who
isn't motivated won't pull an all-nighter, and instead take a week or
two to disassemble your object file and *then* post it on Usenet.
If your company can't compete if your hardware interfaces are disclosed,
I'd suggest that you should take a hard look at your business model or
your technology, because that should be a red flag that something might
be seriously wrong. A number of companies have since released hardware
information about their products, and as far as I can tell, they haven't
done badly by their decision. If anything, they've sold more products
as a result.
- Ted