[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: non-free firmware: driver in main or contrib?

Raul Miller <moth@debian.org> wrote:

> Software which we don't and can't ship, which is a part of the platform
> we're running on, which is not application code, and which basically is
> outside the scope of the project is software we ignore.

In many of these cases, we /could/ ship it (well, the license probably
wouldn't let us, but that's a legal problem rather than a technical
one). But at least we're in agreement that it's unambiguously software,
even if it's also hardware under certain circumstances.

>> The social contract uses "require", which is a stronger term than
>> policy's "depend".
> http://dictionary.reference.com/search?q=require

I possibly didn't make that clear. "depend", when used by policy, refers
to dependencies that are expressed by the package management system. As
a result, it's possible to argue that a driver doesn't "depend" on the
firmware that's in a chip on a PCB of the device it drives. But it
certainly requires it.

>> The driver software requires the portion of the
>> hardware that can also be described as software.
> The sentece which uses the word require is:
>    We will never make the system require the use of a non-free component.
> While it's clear from context that "non-free" refers to "non-free
> software", it's also clear that it's "components" which are what need to
> be free.  It's also clear from contenxt that "components" are "components
> of the debian system.

No, that doesn't make sense. If that was what it meant, it would just be
a restatement of the second sentence ("We promise that the Debian system
and all its components will be free according to these guidelines").
Since we've already promised that all the components in Debian will be
free, then the non-free components it's referring to must be outside

> Among other things, you're arguing that hardware [including software
> embedded in that hardware] is a component of the debian system (rather
> than being a part of its infrastructure).

I can probably be convinced that hardware in the traditional sense
(something that's made out of gates and stuff) is not a component in the
way that the social contract refers to. I see no way of arguing that for
stuff that is plainly code.

> But we do not ship hardware, and software embedded in hardware is out
> of scope for us.

I see no justification for that argument.

Matthew Garrett | mjg59-chiark.mail.debian.legal@srcf.ucam.org

Reply to: