Re: On the freeness of a BLOB-containing driver
On Sat, Dec 11, 2004 at 05:52:36PM -0800, Bruce Perens wrote:
> 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.
Not in the same way: we don't have to include it; the device driver does
not have to be supplied a copy of it for it to work.
> 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.
If it comes down to "the driver, on its own, would not be acceptable for
main because it is not functional; but as a practical matter, we allow
it aggregated with the rest of the kernel because splitting individual
drivers into contrib is a pain for everyone involved and not worth the
theoretical benefits", I can live with that.
It's "we're pretending the driver is fully functional and does not have a
dependency on the firmware, even though it asks for it by name, opens and
parses the file, and doesn't do anything useful without it" that I'm
uncomfortable with.
> Moving something from contrib to main doesn't violate Debian's
> principles. Moving something from non-free to main or contrib without
> the necessary license change would. Contrib is there to tell you that
> something is DFSG-free but is not functional without a non-DFSG-free
> component. Contrib provides a a message to the user and a convenience
> for the Debian developers, it is not a purgatory for almost-free software.
"contrib" exists for software which is free but fails SC#1, "we will never
make the system depend on an item of non-free software". Moving something
from contrib to main that does, in fact, depend on such an item is a pretty
basic violation of Debian's principles.
--
Glenn Maynard
Reply to: