Geert Uytterhoeven <[EMAIL PROTECTED]> writes: > 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.
Untrusted code doesn't necessarily violate the GPL. The two issues are orthogonal. -- Måns Rullgård [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
