Seems GPL2 or GPL3 already requires this

Seems GPL2 or GPL3 already requires this

I advise you to be less combative, but yes, I can: https://www.gnu.org/licenses/gpl-faq.html#MereAggregation

> Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
>
> If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
>
> By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

Note that I never said that "running another program *prevents* a derived work relationship". I said that such a relationship is not necessarily created by running another program or even depending on some properties of its output. Even if you "popen() some other programme, have it perform some task for you and take the resulting output and use it, such that your programme /depends/ on that other programme". The FSF seems to agree with me.

While I'm clearly not a lawyer, it is my belief that "depending" on the names of the binaries created by the upstream build scripts is far too insignificant of a dependency to be considered a basis for a derived-work relationship.