Because the language of the GPL is highly centered around "linking", a GPL operating system doesn't present the same kind of corporate use/acceptance/etc issues as a GPL app or library.
Uh... the word "link" doesn't even appear in the GPLv2, so the idea that its language is centered around it is sort of laughable. I think you're trying to talk about the derived works definition and the fact that the kernel license has express language with a specific definition that excludes running programs on the kernel.
I'm not really interested in arguing, except to point out that the kind of ignorance you're showing about how the GPL actually works has far more to do with "corporate acceptance" in "industry" than the actual details do.
GPLV2: "This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library"
Consider that perhaps I'm not an idiot.
Regardless of pedantry, a GPL OS does not raise the same kinds of issues for a typical corporation that a GPL library or application does.
I see the downvotes. Funny, because this really is the part of the GPL that stirs up controversy at corporations.
Yes, it doesn't say "linking" exactly. It talks about "derivative works". Then, the FSF, separately, says that linking to a GPL library (or integrating into a GPL program) is a derivative work.
Or, have a look at the LGPL, created specifically to address this problem. Note that the FSF isn't thrilled about the LGPL.
That's the big driver behind why a GPL OS doesn't create the kind of stir in a corporation that a GPL app or library does. Not saying it's right or wrong, just pointing out the difference.
