While true, this means that packaging Python is harder than a typical C application, and requires knowledge of the C building process. That's not what people have in mind when installing Python software.

The methods you mention are exactly the reason why it is so complicated. Everyone wants to use their own method to install Python software.

That said, there's about a million packaging systems and most of them don't offer anything materially different from the others (except in weird edge cases that aren't advertised). The space is involved and annoying. It's emphatically not at all like C, which has very strong and well-documented defaults that do the things you expect (usually).

E.g. When you use a patched version of Linux in your router, then you'd need to make those patches / the patched code available, but you would not need to make the code of your web GUI available.

If you are using libviralgpl.dll in your ProprietarySecrets.dll though, your entire application becomes a subject of the GPL.

In general, a reasonable boundary is that if it runs the GPL'd work as a command, then it's not a derivative work, but if it links against the GPL'd work, then it is. (This is of course not a distinction established in law, which knows nothing of subprocesses and linkers, but it's a good approximation, most of the time. Making a modification to a GPL'd binary to expose a particular interface for another non-GPL'd process to call probably makes that non-GPL'd process a derivative work, though. Conversely, using a standardized API that happens to be implemented by a GPL'd library probably does not make the program linking it a derivative work.)

The GPLv3 says:

> A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

GOG presumably believes that they are shipping an aggregate, and DOSBox is an individual work, and the game they're shipping is a separate individual work, and the wrapper script to put them together is its own work, independent of the specific game or specific emulator. They must comply with the license of DOSBox, i.e., they must provide the corresponding sources, but that license doesn't apply to other things in the aggregate.

For comparison, the Linux kernel also says:

> NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work".

https://www.baeldung.com/jlink