proprietary firmware

[Paul Jimenez]

+1 

Software by its nature is easier to fix than hardware or even
firmware; this approach does the Right Thing: vendors win
because the firmware layer just got a whole lot easier to write
and the rest of the world wins because we get as much control
as legally permissible of our hardware.

On Friday, Feb 8, 2008, Wolfgang Spraul writes:
>Dear Community,
>
>Some of our chips or chipsets contain proprietary firmware in flash  
>memory. For example, in GTA02 these include the Wi-Fi, GPS, and GSM  
>chipsets.
>Ideally, we would have liked to use chipsets for which even the  
>firmware code would be free, but they don't exist right now.
>So we accepted proprietary firmware, as long as it was in flash or ROM.
>
>Then we ran into problems when bugs were found in the firmware, and we  
>wanted to update handsets out in the field.
>The vendors would give us firmware updates and reflashing tools, but  
>they wouldn't let us redistribute those tools to our users. We asked  
>for special licenses to allow us to distribute those flashing tools to  
>our users, and got them in some cases, after months of licensing  
>negotiations.
>Next we discovered that those reflashing tools had further issues: for  
>example, they would only allow loading cryptographically signed  
>firmware into the chipset flash memory. The tools do this because  
>vendors are worried that people would disassemble, patch, and  
>reassemble the firmware, triggering regulatory reclassification of  
>their chipsets (software controlled radio).
>Furthermore, we see that for upcoming chipsets, vendors are switching  
>from storing the firmware in flash memory to loading the firmware into  
>RAM at run time. One reason for this is that RAM needs less power and  
>is cheaper. In this case the firmware, whether original or updated,  
>has to be loaded each time the device boots, requiring that the binary- 
>only, restrictively licensed firmware updater be included in the  
>OpenMoko distribution.
>
>This got quite frustrating, until we met Richard Stallman last  
>weekend. And he cleared it up for us rather quickly :-)
>
>He suggested we treat any chipset with proprietary firmware as a black- 
>box, a circuit. He suggested we ignore the firmware inside. If the  
>firmware is buggy and the vendor needs the ability to update the  
>firmware, we instead ask the vendor to reduce the firmware to the bare  
>minimum, so that it can be very simple and bug free, and move the rest  
>of the logic into the GPL'ed driver running on the main CPU. This way  
>we completely avoid the issue of distributing proprietary firmware  
>updates and binary firmware updaters with restrictive licensing that  
>load only cryptographically signed firmware.
>
>We liked his advice. It speeds up our decision making and allows us to  
>focus on what we do best: Developing Free Software that is available  
>in full source code, running on the main CPU, that we and anyone else  
>can modify and optimize. There are downsides: We will no longer offer  
>reflashing tools to update proprietary firmware, under any license.  
>For critical firmware bugs, we will accept returns, or in some cases  
>fix the bug in-house.
>We will push vendors to simplify the functionality of their  
>proprietary firmware, so we can implement more of this on the main CPU  
>as Free Software. Maybe some vendors will even open up firmware for  
>Free Software development, that would be the ideal outcome we are  
>working towards.
>
>We hope this helps clarify OpenMoko's current position on proprietary  
>firmware: Ignore them while they stay inside of a chip or chipset, and  
>refuse to touch them. Focus on what Free Software can do.
>Feedback and comments are always very welcome.
>Best Regards,
>Wolfgang
>
>_______________________________________________
>OpenMoko community mailing list
>community at lists.openmoko.org
>http://lists.openmoko.org/mailman/listinfo/community
>