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.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
Google has bought silence on this issue
Have you tried
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
... google fanboy. copying very feature from iOS a few months later will hardly make apple irrelevant.
RE: Google's Android fork defended, debated, dissected ... again
The great thing is that it is being discussed in the open, nothing hidden.
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
RE: Google's Android fork defended, debated, dissected ... again
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
they should answer the question rather than...
RE: Google's Android fork defended, debated, dissected ... again
Jargon
RE: Google's Android fork defended, debated, dissected ... again
Confusion about open source
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
Google Open Source Guy
I'm not "in the know"
RE: Google's Android fork defended, debated, dissected ... again
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?
RE: Google's Android fork defended, debated, dissected ... again
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.