proprietary firmware

[Fred Janon]

+1 Good and smart decision from my point of view.

On Feb 8, 2008 11:58 AM, Paul Jimenez <pj at place.org> 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
> >community at lists.openmoko.org
> >http://lists.openmoko.org/mailman/listinfo/community
> >
>
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20080208/ce456e01/attachment.htm