What you will have to ask is, what will a non-technical judge think is one work with different labeled parts, or two separated works that are interacting. Questions like "If I remove one, do I still have a something that make sense to call a work?", "how was it created and what was the intention of the creator", "how would a end-user perceive the result", and in many jurisdictions, "what is the industry standard" (judges has shown a tendency to avoid decision which would cause disruption in the market).
> let's say a company decides to make a proprietary fork of a GPL software application
If they intentionally trying to go against the wishes of the author, its likely infringing the license regardless if you use technology X or technology Y.
This is the type of vagueness that a future GPL revision should seek to address, by refining what is meant by 'dynamic linking'.
Law is never certain, but I suspect the answer to the thought experiment is that the application is creating a derivative work. It could however be that the application is only providing compatibility with SoX, among many other similar programs installed on customers machine, in which case it might be fair use or maybe not a derivative work at all. It depends on the details.
A similar thought experiment is to ask why no large company has tried to challenge the guideline of dynamic linking as line in the sand regarding derivative work. How rare would it be that a company want to include non-core optional features in their proprietary products that need to be dynamically linked rather than using inter-process communication, and they want to go to court about it?
https://www.gnu.org/licenses/gpl-faq.en.html#SystemLibraryEx...
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.
As regards your example, I don't think the GPLv3 permits that, so if a company tries to circumvent the GPL using that approach, it would probably lose the rights to distribute the GPL software application.