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