+1 Good and smart decision from my point of view. On Feb 8, 2008 11:58 AM, Paul Jimenez <[EMAIL PROTECTED]> wrote:
> > +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 > >[email protected] > >http://lists.openmoko.org/mailman/listinfo/community > > > > _______________________________________________ > OpenMoko community mailing list > [email protected] > http://lists.openmoko.org/mailman/listinfo/community >
_______________________________________________ OpenMoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
