Non-opensource drivers

Toby Smithe toby.smithe at
Sun Nov 26 20:55:58 GMT 2006

On Sun, 2006-11-26 at 20:12 +0000, Colin Watson wrote:
> On Sat, Nov 25, 2006 at 05:05:40PM +0000, Toby Smithe wrote:
> > On Sat, 2006-11-25 at 16:56 +0000, Colin Watson wrote: 
> > > On Sat, Nov 25, 2006 at 04:53:53PM +0000, Toby Smithe wrote:
> > > > On Sat, 2006-11-25 at 16:44 +0000, Colin Watson wrote:
> > > > > Question: should the same checkbox govern binary wireless drivers (e.g.)
> > > > > too, i.e. turn off the restricted component altogether?
> > > > 
> > > > No. This should be separate. People always need wireless more than fancy
> > > > graphics.
> > > 
> > > The reason I ask is: why would you have moral objections to one but not
> > > the other?
> > 
> > Hmm... I dunno. But the wireless blob is purely firmware in most cases,
> > not just the driver. This is the same question as asking why don't you
> > run a free BIOS if you don't want proprietary drivers.
> Let's have specifics. We have the following non-video-driver bits in
> linux-restricted-modules:
>   madwifi: (dual-licensed) GPLed driver, but requires the HAL blobs
>   which have a no-modification licence. These are firmware, though
>   shipped as objects which end up as kernel modules.
>   AVM: partly LGPL, partly proprietary: the licence states that part of
>   the driver is proprietary, as well as firmware.
>   ltmodem: non-free in that (at least) it doesn't allow you to combine
>   it with anything other than Linux unless overridden by applicable law.
>   Shipped as objects which end up as kernel modules.
>   IPW3945d: binary-only program, IIRC for controlling the frequency of
>   some Intel wireless cards.
>   ACX: not sure of the licence; firmware.
> Most of our wireless firmware (Atmel, IPW2[12]00, Prism, etc.) is in
> fact in main, as long as we have sufficient permissions regarding it
> (I'm not sure of the exact details; Ben knows). My understanding is that
> those that are cleanly separated from the kernel and are just blobs that
> the driver needs to load at run-time are generally in main.
> Perhaps that helps to clarify things.

Seeing as we have a large(-ish) number of binary drivers, it would be
tedious to have options for each one (even if it works by looking at the
user's hardware, and offering the list based on that). I do think that
we should have one option for proprietary drivers, but make it off by
default, and *clearly* explain why, and what benefits they would bring
in comparison to the issues.

> (I don't really buy into the free BIOS analogy, chiefly because, well,
> we aren't shipping the BIOS so it's not our business.)

No; I was talking about the user: why should the user be arguing against
the firmware blobs when they aren't using a free BIOS? I think that on
this point, having non-free firmware only by default is acceptable. When
free BIOSes become more prevalent, we can turn off the non-free firmware

More information about the ubuntu-devel mailing list