Re: Controversy over dynamic linking -- how to end the panic

Craig Milo Rogers (rogers@ISI.EDU)
Thu, 21 Jun 2001 13:34:20 -0700


IANAL. I also dislike fencepost errors. Hence, these
comments.

The GNU GPL Version 2, June 1991, (hereafter the GPL), applies
"to the modified work as a whole". Consequently:

>2. A driver or other kernel component which is statically linked to
> the kernel *is* to be considered a derivative work.

The kernel image, including the statically-linked device
driver, is the primary derived work licensed by the GPL. That portion
of the kernel image that represents some actual device driver binary
code (continuing the example above, and assuming that the device
driver's unlinked object code isn't already subject to the provisions
of the GPL), may or may not be a derived work under copyright law,
depending upon what modifications the linker made to the binary code
during linking. If the device driver didn't become a derived work
during compilation, and it didn't (for example) resolve any kernel
symbols during linking, it would not be a derived work under copyright
law, right? Of course, right.

>3. A kernel module loaded at runtime, after kernel build, *is not*
> to be considered a derivative work.

The in-core kernel image, including a dynamically-loaded
driver, is clearly a derived work per copyright law. As above, the
portion consisting only of the dynamically-loaded driver's binary code
may or may not be a derived work per the GPL. It doesn't much matter
under the GPL, anyway, so long as the in-code kernel image isn't
"copied or distributed".

Looking to the future, what if Linux is enhanced with the
ability to take a snapshot of a running system (including any
dynamically-loaded driver modules), and the snapshots are copied and
distributed by, say, a PDA vendor to make an instant-on Linux system?
I think it's reasonable to argue that the GPL requirements must apply
to all parts of the distributed kernel image, even the parts that were
derived from pre-snapshot dynamically-loaded modules.

The act of "copying and distributing" a linked kernel image
containing GPL'ed code and, say, a non-GPL'ed device driver, requires
that the distributor follow the requirements of the GPL as applied to
the work as a whole, which means that source code must be available
for *all* portions of the linked kernel, which means that source code
for the driver must be made available... under the terms of sections 1
and 2 of the GPL. The GPL's source code availability requirement
applies even to those identifiable sections of the linked kernel image
which themselves are not derived (per copyright law) from GPL'ed
sources.

Remember, however, that the GPL, as written, imposes
requirements upon the the *distributor* of a combined work, not upon
the owner of the non-GPL'ed portions that were included in the
combined work. It is the distributor's responsibility to make source
code available as require by the GPL. This is *not* the same as
saying that any non-GPL'ed source code in question has, automatically,
itself become licensed under the GPL (sections 1 and 2).

Craig Milo Rogers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/