> The userspace ABI is stable and intended not to cause anything targeting it to become a derived work. But once again, this seems to be a way in which the kernel project seems to think it has the power to interpret the GPL. In their minds, targeting the userspace ABI doesn't make a derived work, but writing a module does, unless it only targets GPL_ONLY symbols, in which case for some reason it isn't.
I think this whole part applies as much to the text of the GPL itself as to the common Linux explanation. The GPL draws a distinction between dynamic linking, static linking, and use over a network or through a CLI style interface to decide if a work is a derived work of the GPL program. But, this distinction is just a novel legal theory proposal at best - there is nothing in copyright law that would make the GPL distinctions authoritative.
A license simply doesn't get to decide what constitutes a derived work - that's entirely up to copyright law itself and the court system to decide.
On the other hand, unless and until Congress decides to explicitly legislate how copyright should apply to software, the courts can very well take common industry practice into consideration for judging what is and is not a derived work of a program, and in this sense the Linux kernel developers' opinion is in no way less impactful than the proposals in the GPL itself.
Furthermore, in a matter of contract law (so assuming that the work is indeed judged to be derived according to copyright law, but now judging whether the GPL may offer some relevant exemptions), the stated intentions and interpretations of the parties of the contract are indeed relevant. If there is a long history of kernel developers publicly stating that as long as you are not using GPL_ONLY symbols, your work should not be considered to be under the purview of the GPL, and if this has not been commonly publicly contested, I think that in an actual trial this will matter much more than other interpretations of the GPL.