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

Re: On the freeness of a BLOB-containing driver

Bruce Perens <bruce@perens.com> writes:

> Is a driver that loads a BLOB Free Software? The problem is
> connected with distribution. The BLOB is unquestionably software. It
> runs below the bus,

Yes, I would agree that a non software blob is so unlikely that we can
rule it out. If it is non-software it should document what the data
means (like: // These are the 12000 filter offsets for the highpass
filter ...). I'm sure a documented file of constants would be

On the other hand the blobs mostly come as source files to be compiled
with gcc. We might not like the way the source looks (char data[] = {
... }) but does that legaly have any impact?

If the blob comes with a DFSG free license and complies to all its
terms should we still reject it because we don't like the way the code

With firmware a lot of people would say include the firmware. If
someone would try the same with a game the reaction would be quite the
opposite I believe.

Imagine a source where all variables are named v<number> and all
functions f<number>. Is that still free? Where do we draw the line?
When does source stop to be bad style and start to become obfuscated
and unacceptable for main?

> which is our usual demarcation between Free Software and the rest of
> the system, but it starts life above the bus at boot time, and we
> have to distribute it.
> Keep thinking about distribution, that's where our principles are
> being violated.
> There are a number of reasons that a device's firmware won't
> generally be opened to us:
> 1. The manufacturer's concerns regarding the proprietary nature of
> information about their device that is below the bus.
> 2. The fact that misprogramming the device at that level can damage
> the hardware.
> 3. They aren't going to want to support more firmware versions than
> they have to.
> So, about the most we can do with the BLOB is to stick it in
> non-free, not declare a dependency from the kernel to the driver,
> and make sure the driver fails gracefully if the firmware is not
> there.
> What about the rest of the driver? I think that if you remove the
> BLOB, it's Free Software. It talks to a bus interface, which is a


> natural demarcation between our Free Software and the proprietary
> hardware design. It loads an arbitrary firmware file into the
> device. The device might not work without the BLOB, but the driver's
> still free as long as it does not incorporate the BLOB.  A good
> hardware design would put this code in FLASH on the board. If you
> don't have a good hardware design, BLOBs belong in files, not the
> driver. The 2.6 kernel boots up with at least initramfs accessable
> to it, and later initrd, if it needs a BLOB it should load it from
> there.
> Thanks
>     Bruce

So does the driver depend on the firmware and goes to contrib? When
does it depend and when suggest?


Reply to: