Google’s announced plans to delay the public release of the source code for Honeycomb, the tablet version of Android, are causing some indignation to be vented among the partisans of open source. But should it? This is a good time to reflect on what the freedoms guaranteed by the Open Source Definition actually mean and what they’re for.
Google says it wants to hold Honeycomb close to its chest for a while because it doesn’t want random hardware vendors trying to jam it onto cellphones before it’s ready. Release is being restricted to a handful of tablet vendors Google is partnered with.
Considering the disappointing crappiness and ridiculously high prices of the Android tablets that have shipped so far, it’s hard to blame Google for wanting to exert some quality control. There are difficult tradeoffs here. On the one hand, it serves nobody if handset vendors jump into shipping phones that are as flaky and nasty as the tablets we’ve seen so far; on the other hand, restricting source access also forfeits the code auditing and early field testing Google would otherwise get from early release. Also, Google pisses off the unfavored vendors and at least a substantial minority of the open-source community.
But the controversy isn’t about whether the move is a good idea, it’s about whether Google is violating the norms of the open-source community and (in the most hyperventilating accusations) has turned evil and deceptive.
I don’t think it has. This sort of release delay is an unusual thing to do, but it has happened before without a lot of screaming and finger-pointing. The Ghostscript and mySQL projects used to make a regular policy of time-delayed open-source releases lagging a leading-edge source tree they shipped only to paying customers; mySQL may still do this, I haven’t been keeping close enough track of them to know.
We didn’t see pitchforks and torches at the castle gates of the companies developing mySQL and Ghostscript, because the Open Source Definition doesn’t forbid behavior like this. Nor does the web of customs surrounding the GNU general Public License. Neither these nor any other community norms actually require any development group to release code it thinks is half-baked. They don’t even forbid selective close-to-the-kimono releases – in fact, even the hardest-core zealots at the Free Software Foundation have never fussed about that and they’re conspicuously not doing so now.
What the OSD and other community norms are designed to guarantee is that when there is a public release, you have a right to redistribute it, modify it, and reuse portions in your own code. Google has not attempted to infringe on this right and there is no sign that it intends to try.
One reason I’m relaxed about Google’s plans is that I think I understand Google’s grand strategy. Actually attempting to renege on the rights guaranteed by Android’s OSD-conformant licenses would be suicidally disruptive of that strategy – the change in other players’ cost and business-risk calculations would blow the Android coalition apart.
Thus, it makes sense for the Honeycomb delay to be exactly the interim measure that Google says it is. I have frankly been a bit puzzled about why they’re catching as much flak as they are, which is why I’m a bit late responding to the controversy. Everybody calm down, please! This is no big deal. There’s precedent, and Google’s self-interest will require it to release Honeycomb source publicly when it’s fully baked.