Openmoko strives for openness (smedia glamo)

Crane, Matthew mcrane03 at
Thu Apr 3 20:30:43 CEST 2008

Really, it's intellectual property being sold.  Skimping on docs is just trying to sell less for more.  It costs money to produce documentation and documentation is regularly the final victim of tight schedules in the design factory.  The best docs do seem to be from companies that have intergrated their docs with their development, so that it updates automatically or is tied together some other way.  If a company has crappy docs, maybe they have a crappy dev process.

I do think minimal docs are just the way things are done, you gotta be able to figure out some things as developers.  What can be expected is that it's coverage is feature complete and exactly correct, at a minimum.   If there are blank spaces that can be reasonably infered *or experimented with* to figure out, that's ok.  An asic company just ain't going to know how there product behaves in all conditions, or the best way to adapt a given application, and it's difficult and time consuming to communicate subtlies to them, you just have to play with things.  Otherwise, how else can you know your absolutely correct??  Not with the docs.. 


-----Original Message-----
From: community-bounces at [mailto:community-bounces at] On Behalf Of Wolfgang Spraul
Sent: Thursday, April 03, 2008 12:14 PM
To: herve.couvelard at; List for Openmoko community discussion
Subject: Re: Openmoko strives for openness (smedia glamo)

Dear Hervé,
here is my perspective:
Most chip vendors see their business in selling chips. Documentation  
is just a necessary evil to them, they are trying to get away with the  
minimum amount of documentation that will still sell the chip.
Unless in very few cases, chip vendors do not see good documentation  
as a strategic asset that will help sell their chips. Maybe down the  
road we are lucky and Intel becomes a vendor that sees documentation  
like this, but I will believe it when I see it. NXP also came around  
to us in a very nice way.
We would like to publish documentation for the Toshiba ASIC in our  
LCM, very hard with Toshiba (I'm not complaining, it's a big company  
and we are a minuscule customer).
Samsung seems to be going closed, even though they joined the Open  
Handset Alliance and are a big supporter of Android!

Why that? Well, let's think from their perspective: Again - they are  
selling chips, not books or PDF files.
In the case of Samsung, the legal department may look at a given PDF  
file (say 1000 pages long) and see LOTS OF RISKS! When their lawyers  
read this document (and they won't understand most of the technical  
stuff in there), they are very concerned that the document will  
provide grounds for lawsuits against Samsung later on.
If they just sell the chips as-is, those risks are reduced.
Plus they will say "why do we have to release THIS particular PDF?"  
Why not a much shorter version, say a 2-page high-level overview,  
which the legal department can carefully check word-by-word before  
release? And if it has to be this specific PDF, why not release even  
much more? Samsung certainly has another 100,000 pages documentation  
for each chip, internally.

If you think about it from their perspective documentation is a very  
random thing. You cannot easily convince them that if they release a  
1000-page PDF file about the say 6400 chip, they will sell this many  
more chips compared to just releasing a 2-page PDF file.

So we at Openmoko need to be smart, and accept realities out there:

The current model: We try to convince vendors to open up documentation  
to the public, ideally allowing us (or even better everyone else) to  
redistribute the documentation. Like Intel is doing with Creative  
Commons now.

We can try to 'buy' chips+documentation, make the PDF file part of the  
purchase. We would then put the PDF file behind a click-through  
license, which says that the PDF behind the click-through license is  
just part of the Neo product, and does not guarantee product behavior.  
The legal effectiveness of such a click-through license is debatable,  
and we would still need the vendor to like the idea and agree to give  
us documents under these terms.

We can sign traditional NDAs and alert our vendors that we are legally  
hiring respected FOSS engineers on a nominal basis (say 1 USD/month),  
in order to give them access to the documents we have under NDA and  
allow them to write FOSS software same as our traditional, fully-paid  
engineers can. Again we could only do this with vendors who understand  
what we are doing, trust us, and generally agree to the idea. We would  
not mass-hire thousands of people this way, say having a form on the  
web where you can 'hire' yourself, then download all docs. It all has  
to be reasonable and ideas and intentions must not be ridiculed. But I  
could imagine that this is doable, first with a few selected people,  
later maybe dozens or even hundreds of people? The bigger we make this  
the more our own legal department will get concerned :-)

We can become much more aggressive in documenting our source codes.  
Most vendors would actually like that! Remember what I said above that  
the legal departments see documentation THEY publish as a risk! But if  
we publish something we wrote ourselves they usually don't care, in  
fact they like if someone does free work for them. We can say whatever  
we want about a vendor's chips, worst case we will get sued, not  
them :-) So maybe we should just go ahead and EXTENSIVELY document  
source codes, to the point that you basically have long lists of well- 
documented defines in header files, long commented-out texts  
describing certain chip behavior, more or less based on what we read  
in the documentation (just rewritten), etc. Same as always, we would  
only do this with vendors that understand & agree to this, but as with  
#2 and #3 there is actually a good chance many vendors would be  

There is no perfect solution to cover all cases. We need to work case  
by case (vendor by vendor) to open up documentation, so that we Free  
The Phone, as we have set out to do.
I see a big tendency to write 'pseudo' open source codes, where it's  
nominally written say in C, but actually it's just long lists of  
writing magic 32-bit values into magic memory registers. This is not  
much different from having a binary driver outright, in fact a quick  
run of a binary driver through IDA Pro might then result in the same  
type of C 'source code' that you have otherwise.
In that case 'open source' would be meaningless.
This is what we all want to avoid.
Open Source must mean that every individual out there can UNDERSTAND  
how the chip functions, and how to hack the chip in such a way to make  
interesting new things happen!
Hope this helps, Best Regards,

On Apr 3, 2008, at 10:16 PM, herve couvelard wrote:

>> what if you become part of openmoko?  Just sign some kind of work
>> contract (like other freelancers had and still have with openmoko),
>> but with only USD 1  in return for your work, adding a clause that  
>> you
>> keep the copyright on your work?
>> This way you are legally part of openmoko, have access to the docs,  
>> and
>> can work on the code.
> I don't think it's fair. the world of free software should be a  
> world of truthfulness and this "way" is not. They don't want their  
> specs to run out the world, so let's keep these specs on the shelve.
> Let's the 'market' decide :
> - If it come a chip with better package [hard+spec] for gta03, too  
> bad for Glamo and they will not be in gta03.
> - if the users don't like freerunner because there is no cool 3D  
> stuff, freerunner won't be sold that much and they wont sell to much  
> chips.
> the long term war vs closed sources specs is not to use them : no  
> specs, no cool feature, bad product, product gonna die.
> it is irrelevant to spare time to develop driver for a product when  
> the owner don't want a driver to be develop. Let's concentrate on  
> another open field, ready to switch to a more open chips.
> hervé
> _______________________________________________
> Openmoko community mailing list
> community at

Openmoko community mailing list
community at

More information about the community mailing list