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

Dealing with drivers that need firmware on the filesystem

It's becomingly increasingly common for hardware to require firmware to
be loaded by the device driver on boot, rather than containing it in
ROM. This is unfortunate, because in most cases the firmware is
non-free. As a result, a naive application of policy suggests that
drivers which require this firmware should appear in contrib.

This causes two problems. The first is practical - there's currently no
way that we can provide these drivers on the install media. The second
is philosophical - we effectively penalise drivers that require their
non-free firmware to appear on the filesystem rather than in a piece of

The free/non-free distinction was made because we felt that people
should use free software rather than non-free software when available.
In cases where there was no free alternative, failing to provide the
non-free version would encourage the development of a free one.
Irritating for the user, but good for free software. Fair enough.

In the firmware case, the choice is rather different. At present, the
choice is not between free firmware or non-free firmware. The choice is
between non-free firmware on disk or non-free firmware in ROM. Putting
drivers in contrib penalises the former, and as a result implicitly
encourages the latter.

So, a couple of questions:

a) Does having these drivers in contrib benefit either (i) our users, or
(ii) free software? (Bear in mind again that removing these drivers from
main doesn't encourage people to write free firmware, it encourages them
to buy hardware that has firmware in flash. Ironically, it therefore
becomes harder to produce free firmware...)

b) If not, what's the correct approach?

We /could/ put non-free firmware in main, on the grounds that while it
is in many cases executable code, it does not execute on any processor
that is under the direct control of the operating system. This would
possibly require a small alteration to the social contract. A result of
this would be that not everything in main would be DFSG free.

An alternative would be to leave non-free firmware in non-free, but not
to enforce the requirement that drivers depending on it end up in
contrib. This is possibly the most straight forward, and by squinting
funny we could possibly even argue that the social contract already
allows this.

A third possibility would be to create a new section for material that
is non-free but whose freeness we don't really care about. Drivers in
main would be allowed to depend on this, and we'd include it on the
install media. This would require changing the social contract.

The firmware situation now is similar to the free software situation in
the early 80s. Back then, free software depended on the existence of
proprietary code. It still does now, but the proprietary code has moved
further down the stack. I think it's entirely justifiable to try to
sever that dependence in the future, but we can't do it now. Trying
would be equivalent to trying to ship an entirely free distribution in
1985 - we have some free components, but there's no free versions of
their dependencies.

Until we've actually made a start on removing that dependency, I think
it's unreasonable to punish our users over it.
Matthew Garrett | mjg59@srcf.ucam.org

Reply to: