proprietary firmware

joerg joerg.twinklephone at gmx.de
Fri Feb 8 14:51:53 CET 2008


What's wrong with binary-only device drivers for updating the firmware? Even 
encrypted ones. Except Mr. Stallman thinks this will render whole GNU/Linux 
system in an unusable state and he likes to force manufacturers to change 
sth, as we all know. I don't see any HW-manufacturer to play the game the 
OM/Stallman way. There's "good reason" for every single byte coded in 
firmware, otherwise it had been located in main memory and main-cpu space 
from the beginning to make things cheaper and more easy to develop. HW-mf's 
won't change this on OM's request, and usually they just can not do it. 
There's also good reason not to let "everybody" mess around with the 
firmware, and thus not to disclose the code.
So your statement "We will no longer offer reflashing tools to update 
proprietary firmware, under any license." sounds like a chapter 11 for 
support of the hw you have chosen to use in GTA (especially GTA01 gsm issue).

Please note: not the chip-vendor, but the users "need the ability to update 
the firmware". The vendor usually doesn't care, as long as you don't have a 
really good contract forcing him to handle the issue. Do you?
With common scenarios like PC WiFi-adapters, there's always the win-drivers to 
do reverse engineering (see fullMAC, softMAC, freeMAC) or ndiswrapper. With 
your embedded devices, your policy means there will be no support *at all* 
for this special chip.

*I* am not interested in a system, that's preferring to drop support for the 
special chips, rather than giving a "closed source" ('with the many numeric 
constants forming the firmware, which isn't true src code') updater to the 
users. Mr. Stallman's mileage may vary (though i never heard a statement 
about the BIOS and embedded cpu-microcode updater src-code on his machine ;-)

j





More information about the community mailing list