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