Message-ID: <47A00D43.60602@acm.org>
Date: Tue, 29 Jan 2008 22:38:11 -0700
From: Zan Lynx <zlynx@acm.org>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Jon Masters <jonathan@jonmasters.org>
CC: Pavel Roskin <proski@gnu.org>, linux-kernel@vger.kernel.org,
       Rusty Russell <rusty@rustcorp.com.au>,
       Giridhar Pemmasani <pgiri@yahoo.com>
Subject: Re: ndiswrapper and GPL-only symbols redux
References: <1201641765.18773.35.camel@dv> <1201652420.2271.91.camel@perihelion> <1201657701.24898.14.camel@dv> <20080130050424.GA22444@dallas.jonmasters.org>
In-Reply-To: <20080130050424.GA22444@dallas.jonmasters.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1012
Lines: 20

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/