Glenn Maynard writes: > On Thu, Oct 28, 2004 at 10:05:05PM -0400, Michael Poole wrote: > > > BIOSes are in the EPROM case that I've described--part of the hardware, > > > already present--and go in main. > > > > How does this exception follow from either the SC, DFSG or Policy? > > Hardware is not part of Debian, and the fact that Debian depends on > non-free pieces of hardware has never been considered to violate any of > the above. (And, as I've said a few times, stuff tucked away in an > EPROM acts like part of the hardware.) I acknowledge that this isn't > the only possible interpretation, but I believe it's the one that Debian > is currently acting on, I believe it follows without any stretches of > logic from the SC, and I believe it's a useful, functional interpretation > (from the perspective of Debian's goals).
I disagree that it is a useful interpretation, since many firmwares are for FPGAs that have non-free build requirements. Convincing hardware vendors to free their HDL code -- which is approximately as likely as SCO admitting total defeat tomorrow, even if they have all of their code -- would not achieve useful results for users or many developers. Someone might implement a good free synthesis and place-and-route toolchain; assuming the major EDA and FPGA vendors do not sue the developers for patent infringement, it might only take 5 or 10 years to make it support a reasonable fraction of FPGAs out there. Firmware for processors is obviously a different case, but there is just as much pressure to open or reimplement that code when the firmware is in non-free as when both the firmware is non-free and the driver is in contrib. > If you don't like this, and think it's inconsistent, or that Debian's > goals would be better served with a different interpretation or a different > SC, you're free to lobby for change, of course. Thus this discussion. Perhaps obviously. > > I disagree that pointing fooclient at server.com makes it functional > > on its own. The essential function is not complete without the other > > end, and for the cases I described the other end cannot be satisfied > > within Debian. > > I'm not sure that this disagreement is important to the comparison: a > client requiring a non-free piece of data to make use of a server is not > complete without that data, and (going back to the reason for making > this comparison) a driver requiring a non-free piece of firmware to make > use of a piece of hardware is not complete without that piece of firmware. Non-free servers all require non-free pieces of data: the server. Without that, the client is not complete. You think how the server or device gets non-free data is important. I think the low-level interface is more important. Michael Poole
