I was trying to write a counter-argument to your other post in this thread, and then stopped. You do raise a fascinating point.
Stallman's own words seem to indicate that one would put a library under GPL (instead of LGPL) so that it cannot be used by proprietary software, even through dynamic linking. However, the only "use" of the GPL library by the proprietary software in such a case would be the API interface. But without copyright protection of the API, maybe it is as you say: a GPL library simply becomes a LGPL library.
Looking at this from another direction, what happens if someone writes a proprietary library that duplicates the function of a GPL library? Does that infringe? I don't think so, because it doesn't use the GPL library, it replaces it. Now, what if someone (maybe even the same person or company) writes a proprietary program that uses this proprietary replacement? Does either the program or the proprietary library infringe? Again, I don't think so. Now for the really interesting part: what if someone runs the proprietary program with the now plug-compatible GPL library? Is anyone infringing? If so, who?
IANAL, so hopefully someone will correct me, but for a while I've had a nagging worry that the GPL relies on a very fuzzy notion of what constitutes a "derived work", and that things like Maven might have already punched a gaping hole in it a while ago, even for GPLv3.
Say you write a program including a GPL library. One could argue that (a) the compiled program as a whole is "a derived work", or (b) even the uncompiled code you wrote is a "derived work" as some of it was influenced by the design of the library. This judgment seems to knock (b) out of the water, as APIs are not copyrightable now. But even before, if you write your part first it's clearly not derived, and you then write a connector shim to the API, then it's hard to argue any part of your source-code other than the shim was derived. So (a), the compiled whole application is the derived work, looks like being the main argument.
But here's the thing. Maven and other build systems mean that you can get a compiled derived work onto thousands of customers' machines without ever distributing (or even in GPLv3 terms "propagating") the library, or the compiled derived work, yourself. The customer just gets your code (not the library) from you, together with a build script. Maven or some other little builder on the customer's machine then handily troops off, gets the libraries from Maven central repository or wherever, and ties them together. The GPL explicitly allows building the library in whatever code you like in a private copy -- and that is just what Maven at your customers' behest has done. So does that mean the derived work ends up running "privately" on a hypothetically large number of people's machines, without ever being propagated in the language of the license?
I wonder if it could be argued that a lot of the Java open source world effectively relies on this. Projects provide the source for their own parts, but not necessarily of the GPL libraries they use. Maven build files contain an identifier (organisation, artifact, version) to each library to fetch. But this build file does not necessarily state which repository (the URL) Maven will find each library on when it does its search (or whether that repository will contain a source bundle as well as a compiled bundle of that library). Whereas the GPL asks "provided you maintain clear directions next to the object code saying where to find the Corresponding Source" (emphasis added). It could be argued that people aren't being diligent about fulfilling that clause. But is a legally acceptable response to the accusation "you're not supplying clear directions saying where to find the corresponding source" to say simply "That's ok, because we're not propagating that library or a derived work of it at all -- their project published it, you fetched it, and your own machine produced the derived work"?