LinuxDevices.com: Using M-Systems' DiskOnChip driver without violating GPL
Jul 13, 2000, 01:18 (2 Talkback[s])
(Other stories by Stuart Lynne)
Re-Imagining Linux Platforms to Meet the Needs of Cloud Service Providers
[ Thanks to LinuxDevices.com for this link.
"Introduction, by Rick Lehrbaum: According to a recent poll of
developers of embedded Linux based systems, a third of all new
systems will contain an M-Systems DiskOnChip Flash disk as the
primary boot and storage device. However, proper operation of the
DiskOnChip currently depends on a proprietary M-Systems binary
driver. Since the DiskOnChip is the "drive" from which the Linux
kernel must boot, there would appear to be a conflict with the GPL
status of the kernel (since the DiskOnChip must be operational in
order for the kernel to load). In this writeup, which was
originally posted at the LinuxDevices.com Embedded Linux Forum,
Stuart Lynne describes a process that has been successfully
employed to make use of M-Systems' proprietary driver (which comes
free with every DiskOnChip) without violating the terms of the
Linux GPL (as defined by Linus Torvalds). Lynne writes . . ."
"We now look at what we have to provide the customer if we want
to distribute this. According to Linus' interpretation of GPL we
need to make available all source code to anything linked into the
kernel. We can do that (just send a copy of the appropriate kernel
tgz). Also we have various and sundry GPL'd files in the INITRD
package (glibc, init, cpio, busybox, ash etc). We can include them.
We also have some device modules. If these are GPL they need have
source made available."
"But if they are proprietary (e.g. DOC) then going back to
Linus' interpretation of GPL WRT to the kernel we do not have to.
He has specifically said that it is ok to distribute binary only
drivers as modules as he does not interpret loading at run time to
be the same as linking into the binary. (He also has made some
other caustic remarks that show he does not like this but he does
allow it. He also has said that if you do this do not expect
support from the kernel development team WRT to keeping the run
time load environment the same to support you etc.)"