Sorry that it took so long to respond, I'm not on this list, and I'm not even sure I could/should be.
Anyhow, the evidence you presented to support your opinion seems to me to actually support the opposite of your opinion, so please bear with me while I get myself acquainted with Debian's positions and procedures. On Oct 25, 2008, Ben Hutchings <[EMAIL PROTECTED]> wrote: > On Sat, 2008-10-25 at 18:28 -0200, Alexandre Oliva wrote: >> My understanding is that portions of the Debian system that depend on >> non-Free Software, in spite of being Free themselves, belong in >> contrib, not in main. > The relationship from linux-image-2.6.* to firmware-* cannot be > described as Depends or Recommends, So, it doesn't match some of the listed consequences (thus ...) of the rule set forth in 2.2.1. But I don't see that the wording excludes the case at hand: the packages in main * must not require a package outside of main for compilation or *execution* [emphasis mine] And then, 2.2.2 says: Examples of packages which would be included in contrib are: * free packages which require contrib, non-free packages [...] for compilation or execution, and * wrapper packages or other sorts of free accessories for non-free programs. Now, I don't think one would get very far arguing that a driver that requires non-Free firmware for the device to work doesn't require the non-Free firmware for execution, except in some convoluted and artificially narrow interpretation of execution. Many drivers that require firmware do so at initialization time, and nothing else in the driver ever gets a chance to execute before initialization is complete. And then, just like the GCC driver isn't a compiler per se, it just offers a nicer front end for someone who wants the compiler to run, a driver for a device is just a nice front end for someone who wants the device to work. If firmware is required by the device, this would make the driver in the kernel an accessory to the non-Free program that runs on the device's CPU. FTR, Jeff Carr's understanding of the term firmware comes off as quite narrow, so much so that it doesn't match *any* of the pieces of non-Free firmware that are present in the kernel. That's not to say that initialization sequences without sources don't exist, or that more general hardware configuration information couldn't be held blobs, it's just that his narrow definition isn't relevant to the discussion at hand. Most, if not all, of the blobs that are deemed non-Free are actual programs, that run on the device's CPU. Some are called microcode, some are called firmware, some are called voodoo or ctx_prog, but context makes it quite clear that they're not just register initialization sequences. I've come across register initialization sequences that I had to deem non-Free as well, but not because they were missing non-existent corresponding sources, but rather because they had been copied (by various means) from other programs (most often drivers) without permission, and they were too large to neglect the risk that they amounted to copyright infringement. > because most systems do not require the drivers in question. But is this the correct criterion? Say, would you defend the inclusion of the non-Free firmwares in main just becase most users wouldn't ever run that firmware on their systems, thus making the restrictions imposed by the copyright holders of that code nearly irrelevant for most users? Say, if you had a data compression program that supported plugins for compression formats, and one of the plugin only worked in the presence of a dlopened libraries available in non-free, would this plugin belong in main rather than in contrib, just because the compression format implemented by it was so rare that most systems wouldn't ever run it (or even install it) anyway? Say, if these drivers that require non-Free firmware *were* shipped as separate packages (for whatever reason), would they really belong in main, rather than in contrib? (Note: *some* of the drivers that can load firmware actually work, and get the device to work, without the corresponding firmware, for various reasons. These are some that could quite likely remain in main. It's those that really don't stand a chance of working without the existing firmware that I'm talking about above.) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist [EMAIL PROTECTED], gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]