Weekly Engineering News 37/2008

Wolfgang Spraul wolfgang at openmoko.com
Wed Sep 17 19:07:41 CEST 2008

Hi everybody,
I don't have much actual news about last week, in Taipei the big focus  
was bugfixing for our stable distribution.
Minh HaDuong did a much better job than I could have ever done  
reporting what was going on the last weeks by initiating the community  
written community update at

There was one important thing last week internally still - we debated  
for a long time about how 'open' Openmoko products should be.
The debate got started because we are now evaluating Marvell's Wi-Fi  
chips like 8688 for upcoming phones, as reported last week.
Like many new Wi-Fi chips (also Atheros' AR 6002 that we look at as  
well), the Marvell 8688 has a firmware that needs to be uploaded into  
the memory of the chip at each cold boot. Before, many chips (like  
Atheros AR6001 used in GTA02) had the firmware in flash inside the  
chip. However, flash is more expensive and needs more power than  
memory so vendors are switching to firmwares that need to be uploaded  
at boot time.
The FSF and Richard Stallman don't like that. Their position is that  
all software in a computer needs to be Free Software. Firmwares that  
are not Free Software are only acceptable if they are not user  
upgradeable and can be considered part of the chip's 'circuit'.

So the question was - do Openmoko's phones have to meet an _absolute_  
freedom level, defined somewhere, or do they just have to be the _most  
free_ phones available at the time?
First we came up with a list of freedom preferences (thanks to  
Werner :-)):

The 1st best option is that all software on the phone is Free  
Software. Everything that runs on the main CPU, as well as all  
firmwares in other chips. Everything should be buildable entirely from  
Free Software sources using Free Software tools. This is what Openmoko  
really wants, but it's highly unlikely to happen anytime soon.  
Firmware inside our GPS chip for example is very complex, and opening  
it up brings little value to anybody. Firmware in the GSM chip  
operates in a highly regulated radio band, and the GSM network is  
generally considered too 'weak' to sustain the protocol 'storm' that  
would result from freely programmable firmwares.
Maybe Wi-Fi firmware can one day be open, and Openmoko is willing to  
support this although we know it is probably a multi-year effort.
Looking for allies we found that some people are already working on  
free replacements for Marvell Wi-Fi firmwares: http://wiki.laptop.org/go/Marvell_microkernel
This is also known as 'Software Defined Radio' (SDR) and the Software  
Freedom Law Center (SFLC) published a short note about the legal  
status of this at http://www.softwarefreedom.org/news/2007/jul/06/sdr-paper/

The 2nd best option would be that all software on the main CPU is Free  
Software, and other firmwares are not user-upgradeable, do not have to  
be loaded at boot time, and can thus be considered to be part of the  
'circuit' of that chip, a black box. Some people find this option  
laughable, as it looks like someone not wanting to know the truth, but  
for a number of reasons the FSF and Richard Stallman believe this is  
the right way to protect freedom. GTA02 is at this level, let's call  
it the 'FSF level' :-)

The 3rd best option would allow user-upgradeable firmwares, even if  
they were proprietary binary firmwares that would need to be loaded at  
boot time. These firmware files are typically stored in the file  
system, because Linux kernel standards try to keep binary blobs  
outside of kernel sources. They are loaded at boot time. At this level  
(the 3rd best), the loading would happen entirely through the GPL  
driver, not a proprietary 'upload utility' running on the main CPU.  
Ideally we would like this proprietary firmware to be as thin as  
possible and let the Linux kernel on the main CPU handle most logic.  
This may conflict with power savings (suspend mode) though.
Marvell released some thin firmwares to support this idea, for example  
for the Marvell 8388 Wi-Fi chip: http://wireless.kernel.org/en/users/Drivers/libertastf
We will contact Marvell about the possibility of releasing such a thin  
firmware to Openmoko as well.
For all these proprietary firmwares, to be Openmoko's "3rd best"  
option would mean to give worldwide redistribution rights to Openmoko  
and all our users and developers. Since our developer program is  
totally open, the redistribution rights essentially need to be  
available to everyone. Restrictions against reverse-engineering or  
modification of the binary firmware would be acceptable for Openmoko.
This is the redistribution license Marvell gave to OLPC, for example: http://dev.laptop.org/pub/firmware/libertas/LICENSE
Our goal would be to get a firmware from Marvell with similar  
redistribution rights.

The 4th best option would be to have proprietary firmware, but no  
redistribution rights, so Openmoko could only flash them onto the  
phones in the factory, but nobody else could easily create and  
distribute fully functional images. There are some variants to this,  
for example on some desktop Linux distributions, some drivers will  
prompt a download dialog during installation, where the binary  
firmware has to be downloaded form the vendor's website.

The 5th best option would be to have non-redistributable proprietary  
firmwares, and a proprietary upload utility that runs on the main CPU.

The 6th best option would be to have no Free Software at all on the  
phone :-)

Bottom line of our discussion: Openmoko's phones do not try to meet an  
absolute freedom level. We are making phones that are 'as free as  
possible'. We would probably not want to go down to level 4 or even 5,  
then we rather delay a new model or feature until we achieved the  
freedom level we want. But anything on levels 1 to 3 goes. The higher  
the better.

Phew - done. A lot of text and details, I hope it still helps to  
understand some of our thinking...
Feedback very welcome - are we doing the right thing? Should we change  
Best Regards,

More information about the devel mailing list