Note that I'm neither a lawyer nor a kernel dev. If you're trying to use my posts as legal justification for anything contextually related without getting the opinion of professionals in at least one of those fields, your nuts!
Yours is the first post I've seen to bring out the important SCO headers point. Linux itself is dependent on the principle of headers being factual/technical presentations of the ABI and thus uncopyrightable as such. After all, Unix (R) Signal numbers, etc, as used by Linux, come from such headers. But there's quite some case history establishing such headers as interface facts, not copyrightable at least in the US.
In fact, at least within the US, the principle goes further as well. Independent reimplementations done specifically for interoperability with the public interface as customarily expressed in the headers are generally specifically allowed as well. Again, that's (part of) what let Linux off the hook in terms of the Unix (R) signal interface and (one of) the reason(s) that code couldn't be properly held as evidence of infringement. (Another was the fact that said signal interface code had been published in a public context in sources predating either SCO or Linux, said sources likely being the common source for both, thus SCO's confusion when they appeared to be duplicates.) As such, yes, the kernel headers as BOTH Google Bionic and glibc use them COULD be used as a basis for an independent kernel reimplementation. Without an audit it's certainly possible that a few trivial violations could leak thru, and that's actually what I expect all the experts that FM is pointing at are allowing for -- they've not done that audit and aren't under retainer to do it or to make a legally valid opinion as representing anyone, so they're allowing themselves the typical out that even debaters quickly learn -- don't make all inclusive statements without some out, some qualifier, if one hasn't actually done the work necessary to ensure no trivial logic leak, since an all-inclusive statement without qualifier is disproved with the most trivial possible exception.
But the point is, Google's sufficiently GPL averse to have avoided the Linux kernel and chosen a BSD implementation, or written or bought their own from elsewhere, if the Linux kernel itself didn't have SOME overriding value. That they chose Linux in spite of their otherwise GPL aversion demonstrates the value they consider it to have. Reimplementation? Perhaps, if you've got a couple billion dollars to pour down a rat hole. And why would they do that, starting from scratch, when they could have simply based on a BSD instead, avoiding the whole GPL issue? Certainly, Google's got a lot of money to throw around if it wants, but as equally certainly, it's not going to have it for long if it starts doing such useless things as a from-scratch Linux reimplmentation when it could have started with one of the BSDs instead.
Also, keep in mind that as Greg KH and others are fond of pointing out, Linux now runs on the widest variety of hardware, with drivers for the widest variety of hardware, of any OS out there. And while the USER application binary interface (ABI) as expressed in those headers may be fair game, the in-kernel modular interface expressly is NOT, with many internal kernel declarations exported for module use specifically as
GPL-only and with specifically NO stable internal ABI, so they can and often do change kernel to kernel. Despite the ability to legally write to the publicly exported USER interface, that's going to leave any non-GPL rewrite without the legal ability to use all those drivers, etc, and it's technically a moving target if they try. Which puts any attempter severely in the hole again, as compared to just starting with one of the BSDs, for instance.
So it's unlikely to happen, unless of course perhaps as a personal hobby, perhaps of some random Finnish college student... and who could rightly predict where THAT might lead! =:^)