Linked by Thom Holwerda on Tue 9th Nov 2010 22:24 UTC, submitted by koki
GNU, GPL, Open Source Now this is interesting. We see what is at its core a very valid concern, in practice not a problem to anyone, and, thanks to the tone of the press release, close to trolling. The Free Software Foundation Latin America is complaining about something that has been known for a while - there is some non-Free code stuck in the Linux kernel (mostly firmware). A valid issue of concern from an idealogical viewpoint, but sadly, the tone of the press release turns this valid concern into something close to trolling.
Thread beginning with comment 449318
To read all comments associated with this story, please click here.
UltraZelda64
Member since:
2006-12-05

On the one hand, it pisses me off royally when a piece of hardware refuses to work due to some stupid missing driver. Wireless cards, for example--which have pissed me off to extreme levels to where I just don't care any more, I'll take the blobs.

On the other hand, it seems that some FSF-approved distros do surprisingly well when it comes to compatibility with some hardware, and in some cases (somehow) manage to work with some hardware that refuses to work on just about any FSF non-compliant distro out there (including even Ubuntu and openSUSE).

I think my stance is that I'd rather be using a 100% "free" OS, but will tolerate some blobs if absolutely necessary. So far, those tend to be display drivers (nVidia) and wireless cards (Broadcom). To be fair, nVidia's proprietary drivers actually are very good and tend to be well-supported, but it can still be a pain in the ass to get them installed on some distros, or at least an inconvenience having to do so manually.

Reply Score: 1

phoenix Member since:
2005-07-11

On the one hand, it pisses me off royally when a piece of hardware refuses to work due to some stupid missing driver.


Repeat after me: firmware blobs are not binary drivers. Firmware blobs are not part of the kernel. Firmware blobs are not part of the OS. Firmware blobs are not run on the CPU.

Wireless cards, for example--which have pissed me off to extreme levels to where I just don't care any more, I'll take the blobs.


You're confusing "binary drivers" with "binary firmware". They are not the same thing. You are arguing about the wrong thing.

On the other hand, it seems that some FSF-approved distros do surprisingly well when it comes to compatibility with some hardware, and in some cases (somehow) manage to work with some hardware that refuses to work on just about any FSF non-compliant distro out there (including even Ubuntu and openSUSE).


And they still use binary firmware, without any "OMG, i haz not the open-sources!"

I think my stance is that I'd rather be using a 100% "free" OS, but will tolerate some blobs if absolutely necessary. So far, those tend to be display drivers (nVidia) and wireless cards (Broadcom).


Again, completely beside the point. Firmware is not a driver.

Really, what needs to happen is for more end-user education into the differences between "device firmware" running on the physical device, and "device driver" running in the kernel as part of the OS. They are *very* different things, and the OSSness of one does not affect the OSSness of the other.

Reply Parent Score: 15

umccullough Member since:
2006-01-26

Really, what needs to happen is for more end-user education into the differences between "device firmware" running on the physical device, and "device driver" running in the kernel as part of the OS. They are *very* different things, and the OSSness of one does not affect the OSSness of the other.


Correct - the distinction is that the firmware runs on the device's built-in processor utilizing its own "private" memory space. It should have no direct access to the host computer's processor/memory space without the kernel that is running on the host computer explicitly providing access to it via the driver.

Reply Parent Score: 5

raboof Member since:
2005-07-24

Really, what needs to happen is for more end-user education into the differences between "device firmware" running on the physical device, and "device driver" running in the kernel as part of the OS.


It is obvious this distinction exists.

They are *very* different things, and the OSSness of one does not affect the OSSness of the other.


The GPL talks about a 'work' that is 'distributed'.

From the license:

You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License


It's obvious the Linux Kernel is a work that in part contains another GPL'ed work (many, actually). You could certainly argue that because the firmware blobs, even though they're not drivers, are distributed with the kernel, they are part of 'the work' and thus should be licensed under the terms of the GPL.

Now I'm not saying that's the only interpretation - but it's certainly not an entirely unreasonable one.

I'm not taking sides - but if the question whether it's acceptable to have binary firmware blobs in the kernel were a trivial clear-cut one, this debate wouldn't keep popping up like it does.

Reply Parent Score: 2

manjabes Member since:
2005-08-27

/ot

Really, what needs to happen is for more end-user education into the differences between "device firmware" running on the physical device, and "device driver" running in the kernel as part of the OS.


Why not wish for something at least theoretically doable, like, I don't know, world peace or something. Here in my dimension, I cannot recall any end-users who give a fraction of a fcuk about such things.

Reply Parent Score: 6

aargh Member since:
2009-10-12

Repeat after me: firmware blobs are not binary drivers. Firmware blobs are not part of the kernel. Firmware blobs are not part of the OS. Firmware blobs are not run on the CPU.

You're confusing "binary drivers" with "binary firmware". They are not the same thing. You are arguing about the wrong thing.


Repeat after me: Copyright restricts distribution. Unauthorized distribution of firmware is not different from drivers or music or books.

Reply Parent Score: 3

jabbotts Member since:
2007-09-06

The firmware is often bundled into the driver so when Windows folk think of "driver" they are thinking "driver + firmware injected when driver loads". The driver is no use without the firmware and the firmware may make the hardware work but without a driver...

To make matters worse, when you ask a manufacturer why they don't provide an open source driver "we do not own all the relevant patents" or "the driver contains trade secrets" which boils down to "the firmware is bundled into the driver and we won't separate the two".

It's not such a surprise that people consider firmware part of the driver.

Reply Parent Score: 2