Re: firmware status for eagle-usb-*
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
Reply to: