Maybe the time has come to stand up to the GPL's insane anti-dynamic-linking nonsense.
Dynamic linking is mere use.
If you say that "this cannot be called from certain kinds of programs", you're restricting use, not merely redistribution.
That is because such programs can be shipped to users without including the GPLed code (thus without redistributing it), so that the users then instruct the software to load the GPLed code that they separately obtain.
Any GPLed program which isn't a shared library could be turned into one, and it could be turned into one by a project which completely complies with the GPL.
For instance, if I'd like my proprietary program to be able to use Bash without spawning a process, I can make a public "Libbash" project which turns Bash into a library (without switching the license to LGPL, which I have no right to do).
In my proprietary program, I can test for the presence of Libbash on a system, and use dlopen or LoadLibrary to use the thing if it is present, otherwise fall back on spawning an external process. If I do this, the crazy FSF zealots think I'm a violator, even though I didn't ship a single line of GPLed code with my program.
So, whereas the jury is out on P = NP, but to me, it is clear that GPL = LGPL. :)
If the GPL is regarded as inapplicable to dynamic linking, then its purpose is the same as that of the LGPL.
Independently of the linking issue, the GPL prevents redistribution in non-source-code form.
It ensures that users have access to the source code of the covered work, and can modify that code, share the modifications, and build the code to produce a component which replaces the one which the proprietary program uses.
Continuing with the fictitious "Libbash", it means that users can patch or upgrade their "Libbash". My proprietary program will use whatever version they have installed, just like it will use whatever version of /bin/bash they have installed. If I were to statically link "libbash.a" into my program, then there would be a violation: users cannot upgrade or replace that. And, of course, it necessarily must be shipped with my program, being an inseparable part of it, so I cannot avoid redistributing.
Dynamic linking is no different from command line invocation. Having it embroiled in the licensing rhetoric is a pointless mingling of C-and-Unix technology concepts with freedom concepts.
Rather, I think the difference between them hinges on use restrictions. They should both be replaced by a license which is simply silent on the issue: a license which simply forbids the redistribution of the Work in such a way that it is combined into a single image with incompatibly-licensed works, but permits every conceivable use.
By the way, I think even static linking is fair, if the program is distributed as separate images, and only linked as a part of use. (Which is why the LGPL is silly.)
That is to say, suppose we have a "Libbash" library version of Bash. I could ship my program such that when the user installs it and runs its wrapper program, it statically links itself prior to execution. If it finds a "libbash.a" on the system, then it statically links that. Otherwise it falls back on linking to its own "libbash-stub.a" which works by spawning a process. Since I didn't redistribute any part of Bash, I cannot possibly be infringing on any copyright.
According the LGPL (if that were the license), I would be infringing because of the specific linking technology that is identifiable as "static". (Though it is de facto dynamic by being delayed as long as possible, happening on the user's target machine).
Yet note how the user has full rights over "libbash.a". The user can update to a new version or make local modifications, and rebuild this. When the user runs my program, it will notice there is a newer "libbash.a" and re-run the static linking steps.
From the point of view of copyright, I think this scenario may not have the results you want: the user is effectively preparing a derivative work. In fact, your wrapper is.
Preparing a derivative work is an exclusive right of the copyright holder, meaning they can prevent it or place conditions on it. It's not only distribution.
Now, no one (afaik) in the free/open software communities will focus on the user here, they may focus on the wrapper/Libbash writer: if the work you're creating is a derivative work, then it is within the scope of copyright of the parts.
Dynamic linking is mere use.
If you say that "this cannot be called from certain kinds of programs", you're restricting use, not merely redistribution.
That is because such programs can be shipped to users without including the GPLed code (thus without redistributing it), so that the users then instruct the software to load the GPLed code that they separately obtain.
Any GPLed program which isn't a shared library could be turned into one, and it could be turned into one by a project which completely complies with the GPL.
For instance, if I'd like my proprietary program to be able to use Bash without spawning a process, I can make a public "Libbash" project which turns Bash into a library (without switching the license to LGPL, which I have no right to do).
In my proprietary program, I can test for the presence of Libbash on a system, and use dlopen or LoadLibrary to use the thing if it is present, otherwise fall back on spawning an external process. If I do this, the crazy FSF zealots think I'm a violator, even though I didn't ship a single line of GPLed code with my program.
So, whereas the jury is out on P = NP, but to me, it is clear that GPL = LGPL. :)