lkml.org 
[lkml]   [2008]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ndiswrapper and GPL-only symbols redux
On Tue, 29 Jan 2008, Zan Lynx wrote:
> Jon Masters wrote:
> > I wouldn't quite say that. I wasn't going to comment, but...personally,
> > I actually disagree with the assertions that ndiswrapper isn't causing
> > proprietary code to link against GPL functions in the kernel (how is
> > an NDIS implementation any different than a shim layer provided to
> > load a graphics driver?), but I wasn't trying to make that point.
>
> Well, as long as *any* part of the kernel ever links to proprietary code, then
> GPL functions link to it in exactly the same way ndiswrapper enables. It's
> only a matter of how many steps of separation.
>
> A perfectly GPL USB network driver linked to GPL-only functions feeds data
> into the kernel where it swirls about and emerges from a proprietary network
> filesystem driver, for example.

A proprietary network filesystem driver _on a different system_, you
mean? In this case the proprietary code has no direct access to your
kernel data, except through the communication protocol. No tainting is
involved, as all corruption in your kernel is caused by kernel bugs in
visible code that can be debugged.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


\
 
 \ /
  Last update: 2008-01-30 08:45    [W:1.529 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site