Re: can a kernel in main depend on firmware in non-free to work?
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 <ben@decadent.org.uk> 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 oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Reply to: