Message-ID: <170EBA504C3AD511A3FE00508BB89A9202085B63@exnanycmbx4.ipc.com>
From: "Downing, Thomas" <Thomas.Downing@ipc.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>,
       Simon Kelley <simon@thekelleys.org.uk>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: RE: Binary firmware in the kernel - licensing issues.
Date: Tue, 6 May 2003 08:54:33 -0400 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1505
Lines: 37

-----Original Message-----
From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
>
> So you can't distribute it at all unless there is other paperwork
> involved.
>
>> Given the current SCO-IBM situation I don't want to be responsible for
>> introducing any legally questionable IP into the kernel tree.
>> 
>> This situation must have come up before, how was it solved then?
>
> The easiest approach is to do the firmware load from userspace - which
> also keeps the driver size down and makes updating the firmware images
> easier for end users.
>
> (Debian as policy will rip the firmware out anyway regardless of what
> Linus does btw)
>
> The hotplug interface can be used to handle this.

I am writing a USB driver for a well-known vendor's USB device which
requires firmware download.  The vendor is considering allowing me
to publish the driver under GPL.  They will _not_ allow me to include
the binary firmware under any conditions.

So I will be loading the firmware from userspace - but the user must
obtain the firmware as a part of a larger application package.
(Complete crap IMO, but what can I do...)

PS:  what would be the preferred place to load the firmware
from, if no option giving the firmware pathname is passed to the 
module at load time?
-
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/