Yes, LGPL makes this clearer, but that doesn't address the broad range of interpretation in the GPL.
That would be the "broad range of interpretation".
If that is NOT compatible with your goals, do not use the GPL. Also, do not include any software using the GPL. For example, embedded systems using BusyBox.
However, adopting the GPL (and those user rights) should give you an advantage -- code that works and provides a time to market advantage.
However, adopting the GPL (and those user rights) should give you an advantage -- code that works and provides a time to market advantage."
In its current state, I have no intention to use the GPL for anything, even though I agree with the principals behind it (of ensuring that the code for free/libre software stays accessible to the public).
If you'd be happy to see GPL-style licences become less popular/relevant, by all means ignore the issues people have with them, but if you'd rather see their popularity grow then perhaps it's worth discussing further, especially as the main complaint is over the licence clarity, not something that has to undermine the goals of the FSF.
If compromising the core principles that make the GPL and copyleft software special is what's necessary to get people to use it, then we've already lost.
I honestly don't see any lack of clarity in the license unless you're actively trying to find a way to make proprietary software that utilizes GPL components. The courts might not agree with Stallman about the word derivative but the spirit of the license is clear and simple. If someone releases their work under the GPL and you use it in yours, then the combined work must be Free Software.