Apparently this is fair use according to the US Supreme Court. Technically speaking the case that went to the USSC concerned some prior closed source version of Java, but Oracle doesn't to think there's a material difference since they're not suing Google again for that, and neither do I.
The FSF's argument that linking to GPL libraries require you to relicense the code to GPL rests on the legal argument that APIs, headers, etc. are copyrightable. USSC decided that, well, for only for Google's case, sure, fair use, whatever.
IMHO the GPL was drafted and marketed specifically to make its legal position seem uncertain, and the outcome of the Oracle v Google case doesn't make things clear. I'm not sure whether you'd actually see a court make a decision on the "GPL" given that the case would almost certainly be a matter of copyright infringement, not a matter of license interpretation, so the license text does not matter. If I were a lawyer I'd advice corporate clients to steer waaay clear of anything GPL.
Most importantly, the only reason the courts decided Google wasn't in violation was that Google's purpose, providing a compatible re-implementation of Java for Android, constituted fair use of the interface definition, so Google didn't need a license to use the OpenJDK headers. If Google had copied the OpenJDK headers in order to implement an entirely different system that used the OpenJDK code in a different way, the case would have gone in a fundamentally different direction.
Secondly, the legal reasoning for the GPL goes like this: by default, you don't have any right to re-distribute anyone's code (unless some fair use exception applies). The copyright holder can give you certain limited rights through a license - in our case, the GPL. The GPL can essentially impose any conditions, and if you think they are too onerous, then you just don't redistribute the code, period. If the GPL says "you can't re-distribute my code if you link your program with it unless you also distribute the sources of your program, including all precise compilation and installation instructions, and give your users the same rights and obligations", then there is nothing to dispute. The GPL could have also said "you can't redistribute my code unless you throw a penny in a prominent wishing well and light a candle in 3 different churches", and that would have been binding as well, if you wanted to re-distribute their code.
The subtleties come when you don't actually want to re-distribute GPL code, but would like to interface with it. Say you want to distribute a program that only works if dynamically linked with GCC. If you publish a bundle on your site with your proprietary program + gcc, you are clearly under the incidence of the GPL, since you are distributing GCC and are dynamically linking with it. However, what if you don't distribute GCC at all, and just tell your users "download my program, and then install GCC under /opt/propritary/utils/gcc"? In this case, is your program bound by the GPL or not?
This is a much more complex question, and it is here where you get in the nitty-gritty of what constitutes a derivative work in software. If your program is considered a derivative work of GCC, then you are distributing a derivative of GCC and so you need to respect the terms of the GPL. However, if your program is not a derivative of GCC, then you can entirely ignore the GPL, since you are not stepping on anyone's copyright and so don't need a license. I believe this question is entirely unsettled, and there are plausible arguments (to a layman like myself, at least) both for and against it.
I don't disagree with your take (though I don't know which part of mine you disagree with...)
The idea of derivative work is clear, the confusion is how the FSF kept pushing their interpretations of it.
Programmers are usually not lawyers, and taking legal "advice" (or rather trying to learn legal concepts) from the FSF is not exactly the wisest thing to do.
There's been a lot of confusion why linking GPL libraries would be a "derivative work", and apparently the FSF's stance is... well unless it doesn't use inline functions and macros ( https://lkml.indiana.edu/hypermail/linux/kernel/0301.1/0362.... )... but let's just tell everyone you can't use GPL libraries in proprietary code.
So we have a bunch of rumors about linking mechanisms, speculations that the GPL cares about static vs dynamic linking, kernel interface calls, classpath exceptions, etc.... which shouldn't be a part of the conversation at all, at least not without considering the broader context of how the proprietary software relates to the GPL software.
At some point Google just took the headers of OpenJDK (GPL licensed) and used it in Android, without relicensing Android to GPL. ( https://arstechnica.com/tech-policy/2016/01/android-n-switch... )
Apparently this is fair use according to the US Supreme Court. Technically speaking the case that went to the USSC concerned some prior closed source version of Java, but Oracle doesn't to think there's a material difference since they're not suing Google again for that, and neither do I.
The FSF's argument that linking to GPL libraries require you to relicense the code to GPL rests on the legal argument that APIs, headers, etc. are copyrightable. USSC decided that, well, for only for Google's case, sure, fair use, whatever.
IMHO the GPL was drafted and marketed specifically to make its legal position seem uncertain, and the outcome of the Oracle v Google case doesn't make things clear. I'm not sure whether you'd actually see a court make a decision on the "GPL" given that the case would almost certainly be a matter of copyright infringement, not a matter of license interpretation, so the license text does not matter. If I were a lawyer I'd advice corporate clients to steer waaay clear of anything GPL.