Manoj Srivastava <[EMAIL PROTECTED]> wrote: > On Tue, 14 Dec 2004 14:21:54 +0100, Simon Richter <[EMAIL PROTECTED]> said: > >> Hi, >>> It's fine for software in main to be able to do stuff with non-free >>> data; that's not the issue. The question is whether there *exists* >>> any free data that it works with, and if not, whether that's a >>> problem. > >> I don't believe that is a problem. We don't ship the non-free data, >> we just allow its use. I can see your point, however, that it is >> useless to ship an utility that cannot be used at present without >> having non-free data installed. > > Well, if you need the non-free component to be on the file > system, why is this different from contrib?
When the issue of binary blobs in the kernel was first discussed here, if I'm not mistaken the proposed solution was to rewrite the respective drivers to be able to load the blob at runtime from "somewhere", and that somewhere would then be populated from non-free or an external source. And it was said that if the hardware device generally works without firmware loading, just with worse performance, or if most devices supported by the driver worked without, and just a minority depended upon it, then the driver (the kernel module or monolitic kernel) would be Free. Is this right? If yes, I don't see why this firmware loading software isn't free. Surely, for the kernel, the firmware loading code shouldn't be written dozens of times for dozens of drivers, but rather once in an external source file that is included by all those drivers to do the actual loading. And if the kernel can be freed by this procedure, this firmware loading code must be free. Why should analogous code, just in userland, be non-free? Or why isn't a firmware loading application analogous to kernel firmware loading code? Thanks in advance, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
