The Android kernel code is more than just the few weird drivers that were in the drivers/staging/android subdirectory in the kernel. In order to get a working Android system, you need the new lock type they have created, as well as hooks in the core system for their security model.

Now adding new features to the kernel is quite OK. If the changes are sound, stable and help Linux in general, the kernel community will gladly accept such changes upstream. I was sure Google was well aware of this process and according to their promises, I was also sure that they clearly understood that Upstream Is King.

This seems to be wrong. It is up to Google to fix this problem. Google hackers should make sure this situation is solved for the best of upstream ASAP.

If this doesn’t get solved, the kernel running Android is a fork. An incompatible fork, as Greg concludes:

Because of this, Google has now prevented a large chunk of hardware drivers and platform code from ever getting merged into the main kernel tree. Effectively creating a kernel branch that a number of different vendors are now relying on.

Forking the linux kernel is the worst possible outcome. Tell Google what you think of this. Use your contacts inside Google to make sure they understand the magnitude of this problem (however, I am quite sure that the smart Google peeps know this already, which makes this even more strange).

[UPDATE] In october last year we already heard a bit about Google trying to work better with upstream, as described here (thanks to @haypo in the comments):

Linus asked: why aren’t these patches upstream? Is it because Google is embarrassed by them, or is it secret stuff that they don’t want to disclose, or is it a matter of internal process problems? The answer was simply “yes.” Some of this code is ugly stuff which has been carried forward from the 2.4.18 kernel. There are also doubts internally about how much of this stuff will be actually useful to the rest of the world. But, perhaps, maybe about half of this code could be upstreamed eventually.

One can only wonder. They know there is a problem, they promise to change this as supporting forks is expensive and not really sustainable (quelle surprise!) but still, it seems they are not walking the walk.[/UPDATE]

FLASH-MOB Call

In case you are going to the FOSDEM Beer Event this friday, join the flashmob. Google will sponsor free beer – refuse it. Don’t take the free beer. Insist on the integrity of the kernel community.

You can miss the party (We’d miss you) but I think that equating a fork with something bad misses the point of the GPL and free software in its entirely.

Now, if we were not opening up our code, then I’d skip our beer, but just because Google’s goals for the kernel for android don’t match that of the mainline, well, it seems very childish to complain about forking.

I will also note that it seems to me that the mainline doesn’t like our architecture and thus aren’t going to adopt our code.

At least one non-issue: you said “supporting forks is expensive and not really sustainable”, but that really doesn’t matter. Cellular platforms have amazingly short lives. Any operating system you develop for them has to be considered disposable.

If Google has studied other cellular manufacturers, they may well look at the whole Andriod exercise quite a bit differently than someone coming from a background of a more stable environment.

While forking the kernel isn’t perhaps the smartest decision (unless you have huge resources, like a certain massive search company), the whole point of Linux is the freedom to fork. So honestly I don’t understand what the problem is here. One comment suggested boycotting free Google beer, which is wrong on two counts: (a) Google aren’t doing anything bad (stupid maybe, but not wrong, illegal, bad or immoral), and (b) .. free beer!

Having said that: if you’re not drinking – more beer for others. Just don’t be assholes about it. Quiet protests, fine. Flyers, interfering with distribution of beer, or generally being a pain: not on.

You are rallying opposition to Google based on a lot of very shaky assumptions that you are asserting with little or no grounding. This kind of reactionary behavior is exactly why many enterprises are leery of dealing with the upstream madness. Who are you to say what

Forking any FOSS project is clearly the right of any developer or enterprise if they feel they need control of that development and they are willing to abide by the GPL. The notion that it is more expensive to support a forked project implies that community support for that fork was going to be requested/required. Again – your assumption. It is also rather untrue as many enterprises develop and support proprietary code around GPL code quite successfully and without the support of the community.

If you think that snubbing Google is the way to bring them back into the community – good luck with that. Forcing Google to abide by your decisions on what “changes are sound, stable and help Linux in general” is very specifically anti-FOSS.

We’d love to see Android support end up in the mainline kernel so you could build “out of the box” for Nexus One or other Android devices.

We obviously have a number of areas where we do things differently than existing mainline infrastructure (though honestly fewer than a lot of people seem to think), which are not going to be quickly integrated: Mainline Linux, rightly so, has their standards and ways of doing things. Likewise, we are busy enabling millions of mobile devices to ship and throwing everything that’s already working away and starting over is not a practical solution for us. Hopefully we’ll all find some place to meet in the middle, but I’m sure this will take time.

In the mean time, we pretty aggressively rebase against mainline roughly every other release (currently snapping up to 2.6.32, and will move to .33 or .34 after the upcoming “Froyo” platform release). We’ve been doing this since we started at 2.6.14 and will continue to do so. It’s our hope that eventually the delta between our working trees and mainline will shrink over time and this process will only become easier.

Our kernel code remains available in git repositories at http://android.git.kernel.org/, where we do active development and people are welcome to do whatever with it. It’s all GPLv2 (with the occasional BSD licensed piece). Share and enjoy!