[clug] The GPL and kernel modules
Peter Barker
pbarker at barker.dropbear.id.au
Wed Jun 21 01:17:33 GMT 2006
On Wed, 21 Jun 2006, Robert Edwards wrote:
> I'm wondering if it might not be technically feasible to move
> some of these binary-only kernel modules into user-space and
> provide necessary hooks across some virtualisation scheme into
You might like to read up on this OpenBSD wireless driver:
http://kerneltrap.org/node/6650
Quick summary is that passing stuff off to a userland app caused massive
bloatage (well... perhaps "contributed to" would be closer?).
> kernel space to actually talk to the hardware? I know that so-
> called micro-kernels take this approach. If someone where to
> provide the necessary API, would it then violate the GPL to
> have binary-only code working with that API across into the
> kernel?
I believe this has been hashed out a bit elsewhere (LKML?), but you could
start with a base case of someone writing a "pass through" kernel module
which just happens to export all the symbols to userland that you need to
write your restricted binary - but all the symbols do is wrap kernel
calls. How much do you need to change that module before you wouldn't call
it a "derivative work"?
Additionally - there are already ways to define licenced "interfaces"
in the kernel - "EXPORT_SYMBOL" and "EXPORT_SYMBOL_GPL".... I'm not sure
what the policy on using one or the other is.
Lastly.... the /kernel/ is supposed to be the layer between the hardware
and userland. Passing stuff verbatim between the hardware and userland is
stuff we're supposed to be moving /away/ from :) People are still hoping
that Xorg will do that shortly!
> Bob Edwards.
Yours,
--
Peter Barker | N _--_|\ /---- Barham, Vic
Programmer,Sysadmin,Geek | W + E / /\
pbarker at barker.dropbear.id.au | S \_,--?_*<-- Canberra
You need a bigger hammer. | v [35S, 149E]
"Peter is apathetic, and I'm vaguely apathetic" -- Rachel, thinking of organising a movie trip
More information about the linux
mailing list