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

Re: Why does Debian distributed firmware not need to be Depends: upon? [was Re: LCC and blobs]

On Sun, Jan 09, 2005 at 06:11:54PM +0100, Miguel Gea Milvaques wrote:

> This is the same point. You are going to care very much abut *which*
> firmware are you loading on your driver. 

> >    The firmware used by a NIC driver, on the other hand, has no
> >    user-visible content; certainly it has no content that the user
> >    specifically cares about.  In the common case, there is nothing to
> >    distinguish between one firmware release and the next, other than
> >    bugs fixed according to the release notes.  In the less common case,
> >    some versions of the firmware will add usable features to the
> >    driver, like hardware checksumming of TCP packets.  Even then,
> >    although the user may say "I want version X of this firmware because
> >    I heard it makes the driver faster", there's still a limited and
> >    predictable range of firmware content people might ever want.  To
> >    the extent that this ceases to be true (as, for example, with
> >    Linux-based wireless access point hardware, where a community
> >    develops around producing non-vendor firmware that does cool new
> >    things), it begins to make sense to treat those cases as data
> >    loaders which needn't provide or depend on specific data files.

> > 3. There's a very real expectation, in the PDF case, that the user
> >    could create his or her *own* PDF files, using any number of tools
> >    in Debian or not in Debian.  The user could quite reasonably wish to
> >    install xpdf *solely* to view locally created content.  If you find
> >    that hard to believe, think about how most people use xdvi.

> >    Firmware files are not the sort of thing people can create their own
> >    versions of.  In most cases the format is not documented and there
> >    are no free or even publicly available tools for this, and even in
> >    cases where it *is* documented, this is not by any stretch of the
> >    imagination a typical use case.
> Yes, but the difference is only the difficult could be create them. Then
> if you have a more difficult working sofware, it must be in contrib?

It is not enough to say that you *could* create free firmware files.  As a
user of xpdf, I can unequivocally say that there are pdfs that I have full
rights to, because *I created them*.  I cannot say that about firmware
files.  If you have a free firmware file that works with the driver in
question, please produce it for us to see.  It should become part of the
package immediately, and be loaded by default by the driver.

If, on the other hand, we know that the driver needs to load firmware from
disk before it can actually be usable with any device, and we don't have any
real, working firmware images that are free, it is disingenuous to handwave
this away by saying that "free firmware could exist".  We either have free
firmware for use with the device, or we don't.  If we don't, then the driver
won't work for our users without additional effort, and we should be honest
about that.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: