As the whole the kernel developers don't seem to care to enforce the license in the case of fairly overt violations, like extensions to the kernel with proprietary binary blobs
I am afraid I don't understand why pointing out that GPL-style licenses are generally unenforceable (i.e. gratuitous) in this regard is a strawman. Suppose a vendor took things one step further and distributed a device with dynamically loaded proprietary drivers. GPLv2 and GPLv3 are both vague enough that a legal action against that would probably fail as well, and there doesn't appear to be anything that could be done to fix the problem without destroying the utility of the license in the first place.
If, for example, the FSF really wanted to fix the problem in GPLv4, they could add language like: "conveyance of this code on the same media or on the same physical device with code licensed under any license incompatible with this one is not allowed under the terms of this license".
The needle the the FSF is trying to thread with both licenses involves much too general (and thus easily circumvented) descriptions of what they are trying to prohibit. "Intent" is not a stable property of a piece of software. Nor is "purpose", nor "extension". "Compatible" might be, but then the license starts to look useless again.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds