On Mon, Aug 27, 2012 at 11:04:31AM +1000, Ben Sturmfels wrote:
> Adam Bolte <abo...@systemsaviour.com> writes:
> > If my above assumptions are correct, why treat graphics driver firmware
> > specially? I'm certainly not saying it's wrong to demand free firmware,
> > however I'm curious why some firmware is treated differently. Is it because
> > one lives in your filesystem on your HDD, but the other is stored in an 
> > (and if so, why does this matter)?
> Yes, for me, that's it exactly. I distinguish between devices that
> require non-free firmware to be uploaded each time I turn them on and
> devices that have firmware inside but don't require me to touch it.

Thanks for the clarification. I respect your opinion.

Personally, I feel that if the firmware is uploaded from the file system via
free software, as opposed to being uploaded by a closed system external to the
kernel which I don't control, I'd rather have it on my file system.

> ...and devices that have firmware inside but don't require me to touch it.
If the firmware is freely distributable under a "do whatever you want"-type
license (but still proprietary), you don't actually have to touch anything
yourself. It's generally no different to firmware on EEPROM from a user
perspective, if the drivers are coded correctly.

Actually, maybe *you* do have to touch something since you run Trisquel, but
for the vast majority of GNU/Linux users this will go unnoticed. (Note: I'm
not trying to have a go at you and want to be absolutely clear about that, but
it must be noted that proprietary firmware is a much bigger deal for you
than most because you chose to make it so - regardless of it being right or
wrong. I had forgotten this when this thread all began).

> It's important to me to draw clear lines between the free and the
> non-free software. I don't want my operating system project to have to
> distribute non-free software, because fully-free operating systems are
> so much more powerful as an advocacy tool. That's why I use Trisquel;
> because it makes no exceptions.

Trisquel might give some people the illusion that they can run their computer
with 100% free software at least, and certainly they are doing their best to
make sure that you are running as little as absolutely possible (even if it
means non-functioning hardware). When hardware does function however, I do not
want it to be just because the proprietary bits have been swept under the rug.

> Beyond that, I also think it's important that we have free firmware for
> devices that come with it embedded such as motherboards and hard
> drives). These are a smaller violation of freedom though, and cleanly
> segmented from operating system distributions. Right now I prefer
> instead to focus on the bigger problems for freedom such as Skype and
> Adobe Flash.

Interesting. As per information pointed to me by Chris, it appears that
microcode is loaded into the CPU via the BIOS upon boot. This microcode (along
with the BIOS generally) is proprietary. What you appear to be saying is that
if AMD's graphics firmware was also loaded by the BIOS instead (where you
would actually have less control over how and what gets loaded), it's not so

My view on all this is that I don't care about boundaries so much. If there
are tiny bits of proprietary software on my file-system required to have a
functioning computer, that's fine - *provided* the end result is an overall
larger reduction in proprietary software over what it would be by segregating
it to different storage systems (such as EEPROMs) that can be more difficult
to access.

As a small side-benefit, I would expect having separate firmware files loaded
by the kernel would make reverse engineering efforts slightly easier, as there
would be no requirement to figure out how to dump EEPROMs, and you can
directly compare it against all the other firmware files for similar hardware
- likely all distributed within the same package.

Of course, I'd prefer to not have any proprietary firmwares, microcodes, etc.
stored anywhere on my systems... I'm just drawing a different line for myself.


Attachment: signature.asc
Description: Digital signature

Free-software-melb mailing list

Reply via email to