Linked by Thom Holwerda on Thu 1st Feb 2007 14:41 UTC, submitted by Oliver
FreeBSD "Linux has a large amount of device drivers for hardware not supported on FreeBSD, especially USB devices. Not rarely, such drivers have been written based on information derived by protocol sniffing, reverse engineering and the like. This makes the code highly undocumented, and renders the porting effort extremely error prone. To help with this task, I decided to start working on an emulation layer that would let us recompile the linux source code on FreeBSD, and provide a sufficiently complete emulation of the kernel APIs so that device drivers (or at least certain classes) could be used without modifications to their source code."
Thread beginning with comment 208097
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: license incompatiablity
by elsewhere on Thu 1st Feb 2007 18:52 UTC in reply to "RE[4]: license incompatiablity"
Member since:

According to butters, the license of the kernel module doesn't matter, as long as you don't distribute the linked binary. And that's exactly what NVidia is doing: they're not distributing linked binary kernel modules.

Actually, they are. nVidia does make binary modules compiled against specific versions of Suse distribution kernels available for download, for instance.

Their legal department seems comfortable with the fact that their binary blob is not derivative of the kernel, since it is OS-agnostic and the exact same blob is used on Windows and *nix. I suspect their legal department is correct.

Reply Parent Score: 4

jimveta Member since:

Actually, AFAIK -- and someone correct me if I'm wrong -- the binary modules are NOT LINKED (even when "compiled against" or basically using the kernel source/headers from a specific distro). I think all drivers for *nix OSs are like that: they are essentially like *.o object files and are NOT LINKED until loaded into the kernel.

There is not a pre-established dependency in the *.ko or drivers of where to find its external functions. In other words, there is no nothing in the module themselves that state they strictly require a linux kernel. It's theoretically possible to load and link those modules against a different kernel. To "link" means to establish a dependency for symbol resolution. But in these cases, the drivers don't care where they find their external symbols as long as they're found.

On the other hand, compiling the modules into the kernel as part of the kernel boot image then distributing it, would I think violate the GPL.

Reply Parent Score: 1