[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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: