And in a world were C was the only language that mattered, that might have been fine. But more modern languages might have more diverse notions of what linking is and ain't, and there might be gray areas, too.
It's completely untested in court and a lot of legal scholars doubt the reasoning and interpretations given by the FSF (namely that dynamically linking with a GPLed work transfers the same GPL license to that work) would be allowed by current copyright law.
More or less amounts to the question of "do you need to use parts of the original work to make a derivative work".
Another, possibly far bigger problem, is that it's entirely possible to effectively neuter the GPL with a secondary contract. We know this is legally possible because of what Red Hat does (cut you off as a customer if you redistribute the source code of RHEL) as well as a far more direct legal case in Germany where a WordPress theme maker was able to prevent distribution of a theme they made by arguing that the contract made when the theme was sold overrode the terms of the GPL and prevented the buyer from sharing the theme because of agreed to terms in the contract.
For GPL, that means you can only include GPLed code if you make the whole program available for user to modify and redistribute.
For LGPL, you can include LGPLed code if you make just the LGPLed part of the app available for easy replacement. (so normally this means some form of dynamic linking, and very commonly used in practice with eg. glibc)
So if some company statically links (L)GPLed code to their app or makes it in other ways hard to modify/replace, it's a violation.
The problem is that the GPL isn't the law; it's something (a license or a contract, the interpretation of which is a toss-up; the FSF wants it to be a license since it allows shrinkwrapping the terms, all legal enforcement has it treated as a contract) that relies on existing law to function. Which fails to work if it tries to do something that legal framework doesn't allow you to do. You can't enforce copyright over derivatives if it's not considered a derivative to begin with.
If the FSF conceded that the GPL was actually a contract and were to write more explicit terms stating that this is a requirement to using GPL'ed source code, they'd probably not run into this problem, but because they insist on forcing it through the framework of copyright the virality of the license only goes as far as the definition of derivative works go.
[0]: https://joinup.ec.europa.eu/collection/eupl/licence-compatib...
> “If the man go to this water and drown himself, it is, will he nill he, he goes - mark you that.” (Hamlet.V.1)
Though I admit I didn't know this until I actually looked it up just now :)
Well, that's at least what the internet told me, last time I checked.
What case was that?
I don't really think that's a problem, per se.
Regarding your second example, that's totally fair: effectively the theme maker (who is presumably also the sole copyright holder) did not actually give the theme to the other party licensed under the GPL: they licensed it differently in that sale, which is 100% their right to do.
The Red Hat example is a little more complex, I think. The GPL says you cannot add extra conditions to redistribution. If Red Hat owned the copyright for everything they distribute, that would be fine: they couldn't say RHEL was GPL-licensed, but they'd be in the clear.
I'm actually surprised they've gotten away with this: as far as "ambiguity in GPL enforcement" goes, I feel like it's not all that ambiguous that RH is committing a GPL violation by adding that condition. All it would take would be for rightsholders of a major component of RHEL (like perhaps the Linux kernel) to complain about this. (Then again, there may be no publicly-stated contract or policy here; RH may just cut off customers who share, and cite vague "we reserve the right to cut you off for any reason" policies.)
(Also I might be getting details wrong here; I'm just going by your description and haven't done my own research into these cases.)