[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 08:52:36AM -0400, Michael Poole wrote:
> > In both the network protocol cases and the unwritable format cases, if
> > you do not have appropriate non-Debian software, neither the hardware
> > nor the client (software) do anything useful.  I am not convinced that
> > the data being transferred is relevant to the dependency relationship,
> > in part because different firmwares -- or even different hardware --
> > may implement the necessary interface.
> I don't follow this logic.  If you don't have the appropriate piece of
> extra software (firmware, bytecode, pieces of AIM.EXE), the client doesn't
> do anything useful.  That's "contrib" in a nutshell, as far as I understand
> it.
> 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"?  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"?

> 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.  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.

> > One IM protocol (AIM, if memory serves) asked the client to send a
> > randomly selected region of the official AIM client, and if the
> > response did not match, rejected the client.  I suspect this was so
> > the provider could file copyright infringement claims against people
> > who made compatible clients.  I am not sure whether they still do
> > this, but AOL has apparently done other things[1] that resemble that.
> > The big "non-free" IM providers each put significant effort into
> > blocking unauthorized or all third-party clients.
> That's the case I was thinking of, but I used the "functional bytecode"
> case to draw a closer parallel to the firmware case.
> It does make me curious what the AIM situation is today: I'm assuming
> the current clients work out-of-the-box, without making you download
> AIM and stick it somewhere before it works.  (My Windows client, Trillian,
> does, too.)  If they dropped this particular approach, it makes me
> wonder why ...

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.

Michael Poole

Reply to: