Re: can a kernel in main depend on firmware in non-free to work?
> That's why packages that contain Free Software along with
> documentation under licenses that don't pass the DFSG end up split
> into separate packages. Keeping the documentation that didn't pass
> the DFSG wasn't deemed acceptable, neither was moving the whole
> package to non-free.
The difference between main and contrib is not at all the same as the
difference between main and non-free.
> > Because the kernel is perfectly usable without the firmwares.
> But how about the specific modules that require them, the ones that
> got this sub-thread started in the first place? It doesn't make
> sense to me to frame the discussion in such terms as most of Linux is
> useful without the component's dependencies, when what we're talking
> about is the component, not the whole.
This really is about our package dependency relationships.
1) The Social Contract says we will not make the system require the use
of non-free components. We interpret this to mean 'main' (i.e.,
Debian GNU/Linux) needs to be a closure across Depends.
2) We recognize that a lot of free software does depend on non-free
components - hence our 'contrib' section. However, we do _not_ say
that contrib is not free software. So the reason we have contrib is
_not_ so that Debian can be only free software, but so that Debian
can be self-contained.
3) From a technical standpoint, if you have one big package that has
lots of little executables or plugins or modules, some of which do
not work unless a third-party component is present, obviously you
can do it either of two ways:
3a) main package Suggests: plugin package
plugin package Depends: third-party package
3b) full package Suggests: third-party package
The effect on "user freedom" is exactly the same. We are shipping
(in main) only software that meets our licensing requirements.
Users have the same choice of whether to install the non-free
software to obtain the corresponding functionality. The only real
difference (again, from a technical standpoint) is whether there are
2 packages to keep track of, or 3.
> > Does the kernel require the firmwares in non-free for execution?
> Portions of it do, for sure. Those portions are artificially
> packaged together with the rest of Linux. If that's an argument to
> put something in main rather than contrib, then there's no reason for
> contrib to exist, since all of main+contrib amounts to a single
> "package" called Debian.
It is not artificial; our kernel package follows the same aggregation
as upstream (ftp.kernel.org). It is true that we could decide to
unbundle some or all modules, for various reasons. But the bundling is
certainly more convenient, and (as I argue in points 3a / 3b above) I
don't believe it has any real effect on user freedom.
HOWEVER, if we had several packages originally separate, and decided to
bundle them not for technical reasons, but so that a 'contrib' package
could be pulled into 'main', I think that would be wrong. Because, as
you say, that would be gaming the system, letting a technical decision
be adversely affected by a desire to exploit a loophole in our
interpretation of the Social Contract. We aren't, or shouldn't be,
looking for loopholes. We are, or should be, making the best technical
decisions we can, and then ensuring that those decisions are consistent
with our foundation documents.
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/