Why do you think it makes any difference whether or not they modified it?

Yes. Your offer says "interested customers", whereas 3(b) says "any third party".

No. If you distribute under 3(b), then as long as I'm not distributing commercially I can distribute under 3(c) and pass on the written offer - which still leaves you responsible for providing the source.

"Must make it available ON REQUEST, to a person who received the binary."

I'd really recommend that you re-read 3(b) of GPLv2, which is what's relevant in this discussion.

Yes, but given that the kernel is under GPLv2 (not v2 or later), what GPLv3 says isn't terribly relevant...

Even then, the written offer must be good for anyone who obtains the object code. I download a firmware image from your site? You're obliged to give me source on request. One of your customers downloads a firmware image and then gives it to me? The same applies.There's no point at which it's limited to your customers.

And by "drivers" here, I also mean "board setup code". I can guarantee you that the MSM code in the Google tree isn't going to know which gpio lines are connected to your tablet's LCD power control, even if the CPU happens to be the same one that was in the G1.

Quoting from the GPL v2 section 3(b):

"Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange"

You don't have to choose that option - you can use 3(a) instead, but that means that the source has to be with the device when you sell it.

By Coby? Telechips released their reference kernel earlier this month, but I've seen no indication that Coby are fulfilling their obligations.

The Google reference kernel code doesn't contain the driver code for any of these tablets, and the vast majority of them are based on SoC platforms that don't exist at all in the Google code. The tablet vendors can't simply point at the Google repositories, they're obliged to either ship the source with the devices or provide a written offer to provide the source to any third party on request.

Firstly, thanks for posting this. It's the kind of thing that we never really got out of previous discussion on the topic, which makes it much harder to make reasonable technical decisions.

Secondly, your results are interesting. I'd be fascinated to know whether they're due to the implicit differences between retention and suspend (ie, transitioning to full suspend stops processes that would otherwise be generating wakeups while retention doesn't, or cuts power planes that should otherwise be powered down manually) or because of fundamental silicon level issues. On the other hand, I don't think it fundamentally matters. We have an rtc that's capable of generating wakeup events, so it's acceptable for the lowest level runtime idle state to be system suspend with the rtc set for the next scheduler tick. Just make sure that the latency values are set correctly and it ought to work fine with the existing cpuidle code.

Some background on this:

Android is written to automatically attempt to enter a sleep state whenever possible. So, for instance, when your phone is in your pocket the hardware is suspended. You get an incoming call. You pick up a phone and press a button. The button press fully wakes up the phone. What stops the phone from suspending again?
Wakelocks are Google's solution to this. Pressing the button takes a named wakelock. While any wakelocks are held, the phone will not go back to sleep. Once the call is complete, userspace can release the wakelock and the phone will suspend again.

The problem here is that your wakelocks are tied to your userspace. Userspace needs to know which wakelocks the kernel takes in order to be able to release them. Which wakelocks you want will depend on how your platform is designed. Google have implemented the wakelocks they need to solve the problems they face - other vendors may wish to use different wakelocks. The end result is that you end up with a kernel that can only usefully run with a specific userland, and userland modifications require kernel modifications. It's broadly like saying that it'd be fine for some kernel drivers to require gnome and some others to require KDE.

What's depressing about this is that it's an entirely unnecessary approach. You don't need the system to fully suspend. Modern ARM hardware supports something generally referred to as retention mode, which is where the hardware enters a power state equivalent to suspend without actually performing a full state transition. Rather than explicitly suspending, if there are no tasks to run then the kernel idle routine will put the CPU into this state. When a task is scheduled to run (either because of a timer or in response to an event), it runs.

The stated objection to this is that applications can't be trusted to behave themselves. If I write an Android application that repaints itself by sleeping for a frame and then drawing, that'll keep waking up the CPU. In the wakelock scenario, the system isn't running and so this isn't a problem. In the retention scenario, it'll keep getting scheduled and battery life will suffer.

There's two easy solutions to this. The first is to use the range timer functionality in the kernel. This allows applications to say "I want to sleep for about a second, and can afford this much inaccuracy". The kernel uses this to attempt to merge wakeups - if an application sleeps for a second and a millisecond later another application does the same, they can both be woken up at once rather than causing two wakeups. But we can also take this to more extreme lengths, for instance by changing the accuracy value to a millennium when the screen is turned off. The application won't get scheduled again until we receive a "wakeup" event and set the timers back. The second approach is even simpler - just SIGSTOP all non-system tasks when we'd otherwise release the wakelocks.

So I wouldn't frame this as refusing to meet Google halfway. People have tried to come up with solutions that would meet the usecases that Google want to deal with and which don't end up forcing people to tie their kernel to their userland. Nokia achieve comparable power consumption without any of the wakelock infrastructure, so it's clearly not a requirement in order to hit these targets. What would you expect a meeting halfway solution to look like?