By Bradley M. Kuhn: Harald Welte knows more about development of embedded systems than I ever will. So, I generally defer completely to his views about software freedom development for embedded systems. However, as you can tell by that opening, I am setting myself up to disagree a little bit with him just this once on the topic.
But first, let me point out where we agree: I think his recent blog post about what Android/Linux is not should be read by everyone interested in software freedom for mobile devices. (Harald’s post also refers to a presentation by Matt Porter. I agree with Harald that talk is worth looking at closely.) The primary point Matt and Harlad both make is one that Stallman has actually made for years: Linux is an operating system kernel, not a whole system for a user. That’s why I started saying Android/Linux to refer to this new phone platform. It’s just the kernel, Linux, with a bunch of Java stuff on top. As Matt points out, it doesn’t even use a common Linux-oriented C Library, such as uClibc or the GNU C Library; it used a BSD-derived libc called Bionic.
Indeed, my colleague Aaron Williamson discovered this fact quickly five months ago when he started trying to make a fully FaiF Android/Linux platform on the HTC Dream. I was amazed and aghast when he told me about
adb and how there is no real shell on the device by default. It’s not a GNU/Linux system, and that becomes quickly and painfully obvious to anyone who looks at developing for the platform. On this much, I agree with Harald entirely: this is a foreign system that will be very strange to most GNU/Linux hackers.
Once I learned this fact, I immediately pondered: “Why did Google build Android in this way? Why not make it GNU/Linux like the OpenMoko?” I concluded that there are probably a few reasons:
* First, while Linux is easy to cram into a small space, particularly with BusyBox and uClibc, if you want things both really small and have a nice GUI API, it’s a bit tougher to get right. There is a reason the OpenMoko software stack was tough to get right and still has issues. Maemo, too, has had great struggles in its history that may not be fully overcome.
* Second, Google probably badly wanted Java as the native application language, due to its ubiquity. I dislike Java more than the average, but there’s no denying that nearly all undergraduate Computer Science students of the last ten years did most of their work in Java. Java is more foreign to most GNU/Linux developers than Python, Perl, Ruby and the like, but to the average programmer in the world, Java is the lingua franca.
* Third, and probably most troubling, Google wanted to have as little GPL’d and LGPL’d stuff in the stack as possible. Their goal isn’t software freedom; it is to convince phone carriers and manufacturers to make Google’s proprietary applications the default mobile application set. The operating system is pure commodity to sell the proprietary applications. So, from Google’s perspective, the more permissively licensed stuff in the Android/Linux base system, the better.
Once you ponder all this, the obvious next question is: “Should we bother with this platform, or focus on GNU/Linux instead?” In fact, this very question comes up almost weekly over on the Replicant project’s IRC channel (#replicant on freenode). Harald’s arguments for GNU/Linux are good ones, and as I tell my fellow Replicant hackers, I don’t begrudge anyone who wants to focus on that line of development. However, I think this is the place where I disagree with Harald: I think the freed Android code does have an important future in the advancement of software freedom.
We have to consider carefully here, as Android/Linux puts us in a place software freedom developers have never been in before. Namely, we have an operating system whose primary deployments are proprietary, but the code is mostly available to us as Free Software, too. Furthermore, this operating system runs on platforms that we don’t have a fully working port of GNU/Linux yet. I think these factors make the decision to port GNU/Linux or fork the mostly FaiF release into nearly a coin-flip decision.
However, when deciding where to focus development effort, I think the slight edge goes to Android/Linux. It’s not a huge favorite — maybe 54% (i.e., for my fellow poker players, all-in-prelfop in HE, Android would be the pair, not the unsuited overcards :). Android/Linux deserves the edge primarily because Google and their redistributors (carriers and phone makers) will put a lot of marketing and work into gaining public acceptance of “Android” as an iPhone replacement. We can take advantage of this, and say: “What we have is Android too, but you can modify and improve it and run more applications not available in the Android Market! Oh, and if you really really do want that proprietary application from the Market, those will run on our system, too (but we urge you not to use proprietary software)”. It’s simply going to be easier to get people to jailbreak their phones and install a FaiF firmware if it looks almost identical to the one they have, but with a few more features they don’t have already.
So, by all means, if porting GNU/Linux and/or BusyBox/Linux to strange new worlds is your hobby, then by all means make it run on the HTC Dream too. In fact, as a pure user I’ll probably prefer it once it’s ready for prime time. However, I think the strategic move to get more software freedom in the world is to invest development effort into a completely freedom-respecting fork of Android/Linux. (And, yet another shameless plug, we need driver hacker help on Replicant! :).
Verbatim copying and distribution of this entire page is permitted in any medium, provided this notice is preserved.
Digital Ocean is a VPS/Cloud hosting provider. For just $5 per month, you can get yourself a Cloud server with 512 MB of RAM, 20 GB super-fast SSD, free snapshots, plus backups for a minimal fee. All via a simple graphical interface.
And by signing up with this referral link, you can help support this website.
If you are reading this, your ad could also be occupying this space. Contact us to make it happen.