Google's Android fork defended, debated, dissected ... again

Google's Android fork defended, debated, dissected ... again

Summary: It should come as no surprise that Google's purported forking of the Linux kernel -- which is shaping up to be a Hatfield-McCoy scale conflict - took center stage at LinuxCon's opening day.On Tuesday, tension was evident at a session examining lessons learned from the Android/Linux debacle.


It should come as no surprise that Google's purported forking of the Linux kernel -- which is shaping up to be a Hatfield-McCoy scale conflict - took center stage at LinuxCon's opening day.

On Tuesday, tension was evident at a session examining lessons learned from the Android/Linux debacle. Later that day, panelists on both sides of the fence argued forcefully about whether Google was right or wrong about not sheparding Android into the kernel.

This time, Google had some strong supporters. Among them was Red Hat's Matthew Garrett, a Linux kernel contributor who works on power consumption issues.

At his session, Andoid/Linux: Lessons Learned, Garrett noted that the "partial forking" of the Android code is unfortunate but maintained that there are very good technical and social reasons why Google's Android code is not yet integrated into the kernel and that other companies -- including his own -- have released Linux code and patches to its customers that are not contributed to the kernel.

The big lesson learned?

"Sometimes it's difficult to be a good community member," Garrett said. "Maybe [Google should have] involved us first before the code was written but it's not fair to say they're a bad community member," he said at the Boston-based conference.

Even Red Hat ships out some Linux patches in its Linux distribution patches for its enterprise customers that don't make their way to the kernel. "It's not realistic to do all patches [to a shipping product] upstream," he told his audience. "I'd prefer the world to not be that way but [it is]."

Google provided Android code to the Linux kernel team in 2008 and improved and refined the code twice before it was pulled from the Linux kernel allegedly due to lack of participation by Google.

He said one major difficulty is that Google's wave lock code is unique to Android and not a baseline technology that would  be used by other mobile platforms.

The "partial forking" is disappointing but much better than not having any open source mobile platform to compete against Apple's iPhone, the Red Hat executive said.

Some of Garrett's comments were directed at one gentleman who kept peppering him with questions about the propriety of Google's so called unwillingness to fix and contribute the Android code to the mainline kernel.

He tried to address the man's questions diplomatically but failed to silence him. First, he told him to talk to relevant people after the session. When that failed, he asked the man to "Be Quiet."

When that command failed, too, he asked the man to leave the room, and then called out to some unknown attendant to get him out of the room.  You know it's tense when  someone gets 86'd before lunch.

[I was attending via webcast and was unable to chase the man down but would love to get an email from him or someone who knows who it was so that I could ask some questions myself].

The topic hit fever pitch again later in the day, when panelists from Google and Novell sparred a bit about the so called Android fork.

Ted Ts'o, a Linux kernel maintainer who joined Google in January 2010, said both Novell and Red Hat ship patches that were rejected by the Linux kernel but no one describes their distributions as Linux forks.

It's nothing new," he said. "Novell has a number of patches and SUSE ships with code somebody rejected but no one says Novell forked the Linux code. Red Hat ships SystemTap and no one says Red Hat forked the kernel."

Ts'o claims that Google is taking the heat because of the immense popularity of Android. Its lack of inclusion in the kernel makes it cumbersome for third party developers and manufacturers in the Android ecosystem who have to maintain two separate driver code bases.

Novell's James Bottomley sees it differently. He maintains that the Android fork is evolving in to a long term problem and that the scope of that product should not be compared to patches by distributors.  Google met with Linux kernel developers in April but has not taken serious steps to address Android's absence from the kernel, the Novell developer said.  There are "troubling signs that Google is not interested," Bottomley said.

Nobody got thrown out of the room this time around but those are fightin' words -- aren't they?

In an e-mail interview with this blogger in March, Google's open source guru Chris DiBona said the Android code will make it into the mainline Linux kernel in time but technical issues and mobile platform issues needs to be ironed out before it makes sense.

He also said in May that Google would hire a couple of developers to work closely with kernel. org.

At LinuxCon, Bottomley claimed that it might take a lot of effort for Google to resolve the issue but that the end result should "benefit the whole community, not just Google."

{editor's note: Chris DiBona's first name was incorrectly identified in this original posting. This blogger regrets the error.

Topics: Hardware, Android, Google, Mobile OS, Mobility, Smartphones

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Google has bought silence on this issue

    This is a HUGE issue that is being silenced by Linux people and companies like Redhat who have a stake in the Google moneypot. The second group of apologists are the Android fanboys who all have blinkers on their eyes. Redhat people have increasingly been acting like douchebags as we recently saw with their smearing of Ubuntu. Redhat may have contributed greatly to the Linux kernel but they have also been the ones to profit the most. The rules that FOSS is built on can't be bent to please some mega corporation you happen to like. Either you comply or get called out and fined.
    • Have you tried

      @Discourselives Have you tried CentOS? Much more stable and reliable than ubuntu if you ask me. Now seeing this is based off of RHEL I do understand their angst... Of course if Red Hat were smart they wouldn't charge $99 for their desktop with a years worth of updates (this makes Windows look cheap).

      As for Google, I think they should do whatever it takes to keep chipping away at Apple until Apple is largely irrelevant and even if this means they never standardize it with the kernel.
      • dream on

        @Peter Perry
        ... google fanboy. copying very feature from iOS a few months later will hardly make apple irrelevant.
        banned from zdnet
      • RE: Google's Android fork defended, debated, dissected ... again

        Android fork<a href=""><font color="light&amp;height"> about it</font></a> is bank that <a href=""><font color="light&amp;height">website</font></a> attacked from the <a href=""><font color="light&amp;height">site support</font></a> from any soldier <a href=""><font color="light&amp;height">site</font></a> to the light <a href=""><font color="light&amp;height">home page</font></a> is great defended
  • The great thing is that it is being discussed in the open, nothing hidden.

    You have to have these descussions.
    • Excuse me,


      If they through him out of the room, how can you call it being discussed in the OPEN?
      • RE: Google's Android fork defended, debated, dissected ... again


        I was there. Nobody threw anyone out of the room. The person in question was becoming disruptive, and was asked to leave so discussion could continue. A few people, myself included, applauded (literally) his exit.
  • RE: Google's Android fork defended, debated, dissected ... again

    Isn't one of the supposed advantages of linux is that you can take the code and do whatever you want? Now that Google did that the linux people want the code? Sheehs, linux users are never happy no matter what you do.
    Loverock Davidson
    • RE: Google's Android fork defended, debated, dissected ... again

      @Loverock Davidson

      You can do whatever you want but you have to follow the rules of the GPL. Google has not. As I said, "The rules that FOSS is built on can't be bent to please some mega corporation you happen to like. Either you comply or get called out and fined."
      • RE: Google's Android fork defended, debated, dissected ... again

        @Discourselives I thought Google did submit the source code and make it available, but it was rejected by the Linux Kernal gurus.
  • they should answer the question rather than...

    kicking a guy out to the room for asking it. Even if they are pure and wholesome, this wreaks of covering up something that people wouldn't like. I have been quite a fan and user of Google stuff until their evil deal with Verizon in the last few days,but now I am really questioning whether to continue using their stuff. But me aside, LINUX needs companies like Google and RedHat to contribute reliable improvements to the kernel to keep the foundation solid. The more each LINUX distro strays from the core, the less likely LINUX is to secure a large faithful following.
    • RE: Google's Android fork defended, debated, dissected ... again

      @RedVeg Garrett DID answer that man, the man just didn't like what he heard and decided to be obnoxious and belligerent about it. Sounds to me like he never really wanted an answer, but to vent in a public forum.
  • Jargon

    It will very difficult to get the public interested in important issues concerning open source computing if the community insists on discussing issues in arcane jargon, like "Android fork." To a non-propeller head, this sounds like some sort of instrument for eating an Android. Good grief, Charlie Brown.
    • RE: Google's Android fork defended, debated, dissected ... again

      @Legal_Beagle So suggest better terminology. TBH I don't think "fork" is too difficult conceptually for the "public" to understand. Envision a fork in the road. There, you've got it. I imagine it'd be tougher to explain what a kernel is than to explain what forking means once the whole "kernel" concept is grokked. Or maybe this was just a bad example for your complaint and you ought to head over to a blog complaining about the Xorg OpenGL 1.4 debacle or something.
  • Confusion about open source

    Let's be clear. The code *has* been contributed to the Linux Kernel. The code has been rejected. It is always OK for people to have out of tree patches in their products. Sony Televisions, Amazon Kindles, and other Linux using products all of out-of-tree patches. Most of the time, the manufacturers satisfy the terms of the GPL by simply making the sources available in a tarball on an FTP server somewhere.

    Google has already gone above and beyond this by submitting the patches to LKML, revising the patches multiple times, and spending literally hundreds of man hours trying to get the Linux Kernel Developers to accept their patches. If after spending all of this time, the answer is still Nyet! Nyet! Nyet!!!, the members of the Android team who have spent a lot of time trying to convince LKML developers that this is a good thing have still made headway, for them to take a step back so they can do other silly things, like say shipping product, is completely understandable.

    -- Ted
  • Red Hat Vs Google

    Personally Ubunutu Linux is very stable and secure for starters. Second, Red Hat is just a reliable foundation for the entire Linux Projects [distros]. And finally Google using the Linux based products has to be better for Linux than red Hat is.
  • Google Open Source Guy

    Google's open source guru is Chris DiBona.
  • I'm not "in the know"

    But strictly speaking, if Android is using a custom kernel, <em>is</em> it Linux?
    x I'm tc
  • RE: Google's Android fork defended, debated, dissected ... again

    ?Sometimes it?s difficult to be a good community member,? Garrett said.

    Its not a your decision as a developer, its licence right? If you use the code, you are obliged to return the improvements in source form. Its a violation not to, is it not?

    If you don't want to return the code, and you still want to keep it open source, start it all again yourself and put whatever licence you like on it.

    Without this committment up front, who would have been interested in Android in the first place? Is there something I have missed here?
    Philip Copeman
    • RE: Google's Android fork defended, debated, dissected ... again

      @Philip Copeman
      Google has gone way beyond what the license requires. They have submitted their code multiple times and answered numerous requests for changes. It still wasn't sufficient for the mainline kernel developers, the majority of whom apparently still just don't agree with the requirements.