Re: LCC and blobs
On Sat, Dec 11, 2004 at 05:49:26PM -0500, Glenn Maynard wrote:
> On Sat, Dec 11, 2004 at 02:23:16PM -0800, Brian Nelson wrote:
> > While you have your pen and paper out, go ahead and write some hardware
> > that a contrib device driver can use without needing firmware loadable
> > by the kernel. Put the firmware on the device itself. That contrib
> > driver is now completely suitable for main by your definition.
> >
> > There is no direct relationship between a device driver and a binary
> > firmware blob. The driver simply drives a device. It does not and
> > should not care how a device gets the firmware loaded.
>
> If the driver has to be able to open the file and read the blob so it
> can send it to the device, there's a clear relationship and dependency
> between the driver and the blob: if you don't have a copy of the blob,
> the driver doesn't work. (Spewing out "hardware error, firmware not
> loaded" doesn't count to me as "working".)
>
> The difference is simple: if running a device requires that a driver
> have access to a piece of data, the user must have access to that
> data (and so its copyright restrictions kick in; I might not be allowed
> to give it to you, even if the company that made the device no longer
> exists). If the device merely stores that software on the device itself,
> that isn't the case.
>
> If the user must be subjected to non-free restrictions to use a piece
> of software (such as a driver), it belongs in contrib; that's what
> contrib was created for.
>
> (The fact that this is a result of hardware implementation decisions
> is irrelevant.)
Fundamentally, I think it comes down to this: we have to draw the line
somewhere, and that line has always been drawn at the software/hardware
boundary. Neither the Linux kernel nor Debian have ever considered the
"freeness" of hardware an issue. We don't care if the hardware's BIOS
and firmware is free software. We distribute an operating system that
users may use on any hardware they like.
Firmware, although itself software, is fundamental to the hardware.
Whether a device has firmware or not is traditionally an area we have
not stuck our noses into. We have never cared before about hardware
implementation decisions, and see no reason to start caring now.
So, some hardware requires the firmware to be loaded by some method
external to the device. So what? We have absolutely no obligation to
distribute and load the firmware--ultimately it's the manufacturer's
problem. We may choose to do so and we may not. It still doesn't
change the fact that we don't care about hardware implementations.
Contrib exists for software dependencies. This is not a software
dependency issue. There is no direct relationship between firmware and
drivers.
--
For every sprinkle I find, I shall kill you!
Reply to: