Re: firmware status for eagle-usb-*
On Thu, Oct 28, 2004 at 06:50:43PM -0400, Michael Poole wrote:
> > It's true that different firmwares (or bytecodes, or pieces) might satisfy
> > this, but all that's important is whether there exist at least one of
> > them which is free and in main. If they're all free, the existance of
> > several non-free alternatives doesn't change anything.
>
> Do you therefore agree that boot loaders depend on the BIOS, and
> therefore grub, lilo, etc. must go into "contrib"?
BIOSes are in the EPROM case that I've described--part of the hardware,
already present--and go in main.
> Do you agree that
> packages that require a non-free server (or PDA or whatever is on the
> far end of a wire) to do anything useful must go into "contrib"?
Requiring a non-free server on the other end of the wire is a different
case.
What I'm describing here is client software that, in order to function
usefully, must have access to a piece of non-free stuff (bytecode, firmware,
AIM.EXE) to send to the server; without that stuff, the client and server
do nothing useful, and it exits with "where's the data?" when you try to
use it.
(The above is a repeat of what I've already said--I'm just making sure we
stay on the same page.)
This is distinct from software which merely interacts with a non-free server,
but--as far as that functionality is concerned--is complete and able to do
so on its own.
In practice, the distinction manifests itself in an obvious way: if I can
say "apt-get install fooclient" and then say "fooclient server.com" and
have it work, it's functional on its own. If I get a notice saying
"before you even bother trying to use this, grab this data and install
it", or if I try to run it and it says "AIM.EXE not found, put it somewhere",
it's not functional on its own. This is clearly a case where--if we
were allowed to redistribute it at all--we'd say "Depends: aim-binary-package"
and stick aim-binary-package in non-free. (The firmware case is identical.)
> > This doesn't extend to the "unwritable format" case, because being able
> > to read a file format is useful in and of itself, even if you can't write
> > it (and presumably the software reads and write other formats).
>
> I rather doubt that packages like libntfs do much more than read data
> produced by non-free software.
... which doesn't imply that data is non-free. I store lots of Free
data on NTFS partitions. If you like, I'll create an NTFS filesystem
containing some Free stuff that you're probably not interested in, and
stick the data up on an FTP--there's some free data it can be used with.
> Besides, being able to implement one
> end of a protocol is just as useful as being able to read an format
> that cannot be written with Debian.
Sure. However, if the client is required to send a non-free (firmware,
EXE contents), you havn't implemented the client side of the protocol
if you don't have that data to send.
> gaim appears to work around this by querying a web service at
> gaim.sourceforge.net to get the right data to send back. Neither
> gaim-1.0.2 nor Debian seem to provide this: another place where gaim
> effectively requires non-Debian software.
Hmm. This is a strange case, and I'm having trouble fitting it into
any of the above. It feels like a workaround for a blatent copyright
abuse--for example, it could be used against garage door openers[1].
[1] http://www.eff.org/effector/17/32.php#III
--
Glenn Maynard
Reply to: