Android/Linux’s Future and Advancement of Mobile Software Freedom

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/04/android-vs-gnu.html

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 Harald 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!
:).