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 FS

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.html 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.