Brian Nelson <[EMAIL PROTECTED]> writes:
> 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.
We don't care about hardware implementations. The hardware is not put
into main, contrib or non-free. Its software is.
The relationship between a driver and the firmware file it loads is
pretty clear for me, esspecially if both are available as deb
packages. Are you saying the driver.deb should not depend on or
suggest (depending on how needed the firmware is) the firmware.deb?
I hope veryone agrees that with a driver.deb and firmware.deb the
later should show up in the package relationship. The only question
here should be as depends, recommends or suggests.
For firmware not in debian the same result should happen to the
driver.deb as if the firmware would be in non-free. If the firmware is
distributable someone would/could package it. Lack thereof shows it
beeing even less free than non-free.
Hence my opinion of (non-free) firmware in non-free and drivers in
contrib if the firmware is required and not just optional (for most).
> --
> For every sprinkle I find, I shall kill you!
MfG
Goswin
