
The FSF is papering over a binary blob - blasdel
http://lwn.net/Articles/460654/
======
_delirium
It's an interesting edge case when you have someone actually _moving_ from one
model to another. But I think even OpenBSD's famously strong policy on binary
blobs would allow this one, at least as they've implemented the policy in the
past. They require source for _drivers_ , which means anything you need to
load onto the chip or use to communicate with it, but not for every piece of
ROM that's internal to a chip. For example, Intel and AMD both microcode some
instructions in firmware on their chips, rather than implementing them in
silicon, and OpenBSD is ok with that, treating the silicon and microcoded part
as all part of the blackbox chip package, rather than as a "driver" that
requires source.

~~~
tedunangst
Actually, the requirement for adding firmware (something that is loaded onto a
chip) to OpenBSD is that it be modifiable. Source isn't required. (Speaking
only about firmware that goes on the chip, not HAL layers that run on the CPU.
Those are banned in binary form.)

I'd say the biggest difference here is that OpenBSD's goal is to make a free
operating system, not a free phone.

------
jrockway
To be fair, I'm pretty sure the FCC would not allow you to sell a device in
the US that lets you modify the RF firmware. So even if we had full source
code to the radio's firmware, it would be illegal to sell a device that could
be user-programmed. Or something.

(I don't know how widely enforced this is, though. I've never had any trouble
telling my wifi equipment I'm outside of the US to get access to extra
channels. I guess this is a federal crime, but good luck enforcing it.)

~~~
MostAwesomeDude
This argument used to be used all the time by WiFi device manufacturers, and
it turns out to be bullshit. The truth is that _you_ , the operator of the
device, assume all liability for your modifications, but there is no reason
you can't flash/modify your firmware to, say, improve your power-saving
abilities or improve your scanning times.

We have enough source code for Atheros devices to be able to reprogram them as
we see fit, and the FCC doesn't really care.

~~~
jrockway
Glad to be proven wrong.

------
av500
So Richard Stallman would be OK to use a PC with a closed source BIOS as long
as there is no way to update it?

~~~
matthavener
I doubt it. RMS uses some laptop specifically because the processor is open
source. From his wiki page: "Stallman's only computer is a Lemote Yeeloong
netbook (using the same company's Loongson processor) which he chose because
it can run with 100% free software even at the BIOS level, stating "freedom is
my priority. I've campaigned for freedom since 1983, and I am not going to
surrender that freedom for the sake of a more convenient computer."[57] Lemote
is a joint venture of the Institute of Computing Technology of the Chinese
Academy of Sciences, an institution of the State Council of China."

~~~
tobylane
China? Could he not side with someone who dislikes USA more? Surely there's a
North Korean laptop that fits his requirements. Not that anyone other than
Stallman is right, it's just odd.

~~~
astine
Your complaint seems just a little bit ridiculous considering that most
Americans, yourself probably included, use computers made in China or made
with parts made in China. In fact, it's probably easier to find and computer
100% free of proprietary software than a computer 100% free of Chinese
components. Considering that, national security concerns aside, free trade
between countries is usually mutually beneficial, I see no reason to fault
Stallman for this.

~~~
tobylane
I meant that he cares about total freedom and control of his hardware, and yet
bought from a country that likes the opposite. Who knows if some part of it
isn't actually open source, and if it isn't, China and NK are the least
trustable countries (not companies per se) for it to be from.

------
smoyer
Isn't all my other non-free software just blobs that are loaded by my free
software? Why isn't it my right as a user to choose the closed software? If
hiding the blob from the user makes it okay, why not apply that thinking to
drivers wrapped by the NDISwrapper?

~~~
zdw
The problem is that binary-only drivers are in privileged locations and
frequently cause OS kernel problems. As they're binary only, they've basically
undebuggable, and frequently nonportable to other systems.

OpenBSD is very strong on this, and often has drivers that are blob-free when
other OS's don't: <http://onlamp.com/bsd/2006/04/27/openbsd-3_9.html>

This isn't restricted only to free OS's either - nearly 30% of Vista crashes
were attributed to buggy nVidia drivers:

[http://arstechnica.com/hardware/news/2008/03/vista-
capable-l...](http://arstechnica.com/hardware/news/2008/03/vista-capable-
lawsuit-paints-picture-of-buggy-nvidia-drivers.ars)

In short, if you want a system you can at least have a chance at fixing when
it breaks, you need the source code to your drivers.

This case in particular is a firmware load into a 3rd party chip, which isn't
usually as bad a a binary driver, but can be a hassle if there are
restrictions on distribution of the firmware.

~~~
Someone
_"This case in particular is a firmware load into a 3rd party chip, which
isn't usually as bad a a binary driver"_

In most scenarios where I think a '3rd party chip with its own firmware' makes
sense, that chip can generate interrupts and/or do DMA. Both cases will
(typically) allow that firmware to crash the OS on the other CPU (or bring it
to its knees by DDOS-ing it with interrupts)

Because of that, I do not see why a blob running on that 3rd party chip would
be less of an issue than a blob running on the main CPU.

~~~
tedunangst
Why is a blob running on a 3rd party chip less of an issue than hard coded
transistors on a 3rd party chip?

~~~
Someone
Good argument. I would say it is not less of an issue, but I also think it
isn't less of an issue than having a blob running on the main CPU. IMO, such
blobs only become problematic if they do not work properly or aren't flexible
enough. Whether they are made in soft-, firm-, or hardware is immaterial for
that.

In the end, for almost every case (yes, you probably _can_ build your own 1kW
6502-class CPU from sand, if you are good, start young and persevere for a
couple of decennia) it boils down to the fact that you will have to trust some
other people. After all, you cannot reasonably verify that say a x64 CPU
really behaves as its documentation states it does.

~~~
tedunangst
One reason the blob on the CPU is so different is the way it interfaces with
your code. In that regard, it is almost never flexible enough and the exposed
interface surface is generally enormous. Your kernel version is supported only
at the mercy of nvidia or whoever.

Firmware chunks have a very simple interface: load. Anybody with the firmware
file and some basic documentation can make it happen.

------
zokier
I wonder how hard it is to swap peripheral chips in embedded solutions like
this? And more importantly, are there any WLAN chips with good blobless
drivers? Somehow it seems that they always have been a pita for Linux

------
sliverstorm
This solution seems rather _less_ "free" to me. I can't update the firmware?
Because it makes you feel dirty to allow me to?

~~~
jws
Yes. And when a malicious packet is discovered that compromises the RTOS on
the chip, and the vendor patches it, this cost raising ideological kludge will
leave you devices vulnerable forever.

(I say this, knowing full well that I suffer from the closed nature of this
device. The DreamPlug uses this, and the access point version of the firmware
only supports 8 devices. That doesn't go very far with the usual complement of
mobile devices people carry. I am powerless to patch it and will have to add a
dedicated access point to work around it, but paying to freeze this particular
deficient version of code is ridiculous.)

------
derleth
What if, instead of moving the software to a binary blob, they went a bit nuts
and moved it to an ASIC that did the same job in random logic? That is, what
if they re-implemented the software in pure hardware?

~~~
sliverstorm
Are you suggesting they reimplement the Marvell WLAN chip themselves? "Hey
guys, I know, let's add an analog ASIC! It can't be that hard!"

~~~
derleth
Don't be so literal. I'm saying hardware and software are more interchangeable
than people realize.

