Re: Linux GPL and binary module exception clause?

From: Kendall Bennett
Date: Wed Dec 03 2003 - 19:29:30 EST

Linus Torvalds <torvalds@xxxxxxxx> wrote:

> On Wed, 3 Dec 2003, Kendall Bennett wrote:
> >
> > I have heard many people reference the fact that the although the Linux
> > Kernel is under the GNU GPL license, that the code is licensed with an
> > exception clause that says binary loadable modules do not have to be
> > under the GPL.
> Nope. No such exception exists.

Right, after following a few of the links and reading the previous
discussions, that is clear to me now ;-)

> But one gray area in particular is something like a driver that
> was originally written for another operating system (ie clearly not
> a derived work of Linux in origin). At exactly what point does it
> become a derived work of the kernel (and thus fall under the GPL)?
> THAT is a gray area, and _that_ is the area where I personally
> believe that some modules may be considered to not be derived works
> simply because they weren't designed for Linux and don't depend on
> any special Linux behaviour.

Or what if a device driver is written such that it is completely binary
portable between different operating systems, such that the same binary
can work on Linux, OS/2, Windows, QNX, BeOS and multiple embedded
systems? Clearly I am talking about our SciTech SNAP drivers here, as
that is what they are. Would writing glue code to allow those modules to
be loaded inside the Linux kernel make the binary driver modules derived
works? Clearly the glue code would be Linux specific and hence need to be
GPL, but would it extend to the binary module? I can also come up with
some arguments both for and against this scenario, and I agree 100% that
it is a huge gray area.

To date we have not even attempted to load our SNAP drivers inside the
Linux kernel, even though it would be quite easy to do so, primarily
because of this gray area. We may need to write some kernel modules
shortly to support a few things that the SNAP drivers may need, but since
the user space drivers would interface to this kernel module via system
calls, only the kernel module would need to the GPL and the user space
driver that uses it would not. So we may never try to load the SNAP
drivers inside the kernel, but it is an interesting exercise to consider
the legality of whether it is possible.

Anyway loading SNAP drivers inside the Linux kernel, while interesting,
wasn't the reason I brought up this discussion. The primary reason is
that we are going to be releasing the SciTech SNAP DDK under the GNU GPL
soon, and I wanted to understand how this expection clause works. Since
it doesn't exist, it does open up a few questions ;-)

It is our position that drivers that would be built from our GNU GPL DDK
are in themselves separate works as they follow a clearly defined, binary
compatible interface and can be used with software building using a non-
GPL version of our SDK (the SDK is actually LGPL). The driver binary
itself on the other hand must be GPL, as it links against generic code
provided to the developer as part of the DDK, so full source to any
driver built with the GPL DDK must be provided. Even your own writings on
this issue would indicate that you would agree with me on that front.

The lowest level binary modules have a 'less public' interface, in that
we do not directly document it (well, at least not yet except for the
header files but some may consider that valid documentation). It does
evolve more quickly over time than the public SDK API, but even so the
drivers ABI is strictly maintained for backwards compatibility, even
though it does evolve. We have a clearly defined interface for evolving
the API while maintaining backwards compatibility, and even doing hot bug
fixes for existing binary drivers as necessary. But above the low level
driver is the public SciTech SNAP API, which evolves much, much more
slowly and is completely documented (both at the header file level and
external documentation level).

Does my position make sense?

Clearly the intention here is to make sure that the GPL version of our
DDK is available for free use by the Free Software community, but if
someone like Intel or NVIDIA wants to write a SNAP driver that they don't
provide source code for, they need to license a proprietry licensed
version of our DDK.


Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400

~ SciTech SNAP - The future of device driver technology! ~

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at