Re: non-free firmware: driver in main or contrib?
> Raul Miller <moth@debian.org> wrote:
> > I said similar, not identical.
> >
> > The difference I was referring to was the difference of convenience --
> > using software from contrib requires a few extra steps. Similarly,
> > using an external copy of firmware requires a few extra steps.
On Tue, Oct 26, 2004 at 02:52:28PM +0100, Matthew Garrett wrote:
> The contrib distinction is nothing to do with convenience
Ok, so contrib is just as convenient as main, for everyone.
> - it's to do with segregation of free material from material with non-free
> dependencies. We do this because we are a free software distribution.
> You might as well claim that the difference is similar in character
> between Debian and Ubuntu - an installation of Debian requires a few
> extra steps to get X configured. It's true, but it's not useful.
I agree that the purpose for having contrib is so that we can easily
distinguish between software which we have depend on non-free software
and software where we don't have such dependencies.
> >> Note that the social contract does not use the word "depends".
> >
> > It uses "require", which is close enough.
>
> No. "Depends" has a very specific meaning within Debian. All dependecies
> are requirements - not all requirements are dependencies.
"Depends: " has a very specific meaning within Debian.
This doesn't mean that "depends" loses all other meaning within Debian.
> >> All of the hardware under discussion requires non-free code.
> >
> > That's one way of looking at it.
> >
> >>From within a framework of thought that looks at the issue that way:
> > where meeting the hardware's non-free code requirements is totally out
> > of our control, we don't do anything about the issue.
>
> That's a viewpoint that isn't enshrined in policy or the social
> contract.
True, in the sense that it's an informal point of view, and not a
sacred one.
However, the question is really one of scope. For example, all known
instances of the x86 architecture require non-free code in their
manufacture. We consider those requirements to be outside the scope
of Debian.
> Point 1 of the social contract is quite clear that we can't
> distribute material in main if it requires non-free components. The
> firmware in these devices is non-free. The logical conclusion is that we
> can't ship any driver that requires non-free frimware, regardless of
> whether this is in ROM or on CD.
The problem with logic is that when you feed it garbage you get garbage
results.
Alternatively, you can treat the presence of garbage results as an
indication that your data is garbage.
Since your claim is equivalent to claiming that Debian should distribute
nothing in main, I'm going to treat your fundamental assertions as
garbage. This is not a criticism of your person, I just don't see any
positive benefit in what you are currently advocating.
> The other logical conclusion is that the social contract is buggy and
> needs fixing. The benefit of hindsight, eh?
[1] "Fixing the social contract" is outside the scope of debian-legal.
[2] In the context of debian-legal, the spirit of the social contract
is the issue, not some narrow technical reading.
[3] The social contract is written in english, which means that there
will always be ambiguous interpretations which conflict with what we want.
> > Similarly, we distribute web browsers which visit servers where those
> > servers require non-free code. For the cases where those servers are
> > totally out of our control, we don't do anything about that issue.
>
> Browsers do not require non-free code - they are merely able to make use
> of it.
That's a valid point. That is, it's valid as long as you limit your
scope of consideration to so that you're ignoring non-free code in the
design, manufacture or support of the systems needed for the typical
operation of that browser. [For example, non-free code at internet
routers and switches.]
--
Raul
Reply to: