Re: On the freeness of a BLOB-containing driver
Bruce Perens <bruce@perens.com> writes:
> Glenn Maynard wrote:
>
>>It's free, but it has a non-optional dependency on non-free software, which
>>means contrib, not main.
>>
> In the case of a device driver, that dependency would still be there
> if the firmware was in ROM. Which would put pretty much all of our
> device drivers, X (talks to VESA code), APM and ACPI (talks to BIOS),
> and so on, in contrib too.
I draw the line there at what the user has to do. Does he have to copy
the file to his filesystem and taint it or not? Preinstalled firmware
in flash just is there. It's a black box that somehow magically
displays coloured images on our monitor.
Debian packages can only express dependencies on other packages and
you couldn't make a package containing the rom (as in the chip). With
a downloadable firmware file you can make a deb and most would have a
deb in non-free.
If there is (can be) a deb then there is a package relationship of
some kind.
> The only logical demarcation I can see is that we have Free Software
> down to the bus programming interface. What lives on the other side of
> the bus programming interface isn't our problem unless we have to put
> it there, just as the fact that proprietary software runs in the other
> systems that we talk to on the network does not comprimise the
> freeness of our system.
I come to the same but using the filesystem as rule. If it has to be
in the filesystem tree then it is of concern.
>>In reality, it doesn't talk to an arbitrary
>>firmware file; it has to talk to a functional one, or the driver is not
>>going to do anything useful.
>>
> I agree that it would have to be working firmware and it is
> anticipated that it will not be Free Software.
>
>>That type of notice is a big hint that something belongs in contrib, IMO; the
>>real effects are the same as saying "go download and install this non-free
>>JRE".
>>
>>
> Stuff in contrib generally has a package dependency on something in
> non-free that is necessary to install it, and the entire package is
> not functional if that dependency is not fulfilled. The driver is a
> component of the larger kernel which remains functional.
Only if it is in the kernel. As said before, drivers in the kernel
should cause a suggest while as standalone package it would be depends
(and then contrib).
MfG
Goswin
Reply to: