I agree that too much is being made of this issue.
The distinction which many people fail to make is between what the LGPL is versus what the LGPL mandates. In other words, the LGPL propogates itself to works which are modifications of the original LGPL'd work, but the LGPL only slightly constrains what you do with a (executable) program that uses the LGPL's work unmodified. Those constraints are delineated in Section 6 of the LGPL. Those constraints are not the same thing as the LGPL.
Now, if people are up in arms simply because the LGPL constrains how you distribute software which relies on LGPL's software, um, tough. They should be grateful that the LGPL is as unencumbering as it is, in comparison to the GPL.
Slashdot Mirror
You only need to make such an offer (Section 6(c)) if you don't comply with 6(b), which is using a "suitable shared library mechanism".
As long as you're doing something like dynamic linking, you don't need to provide the LGPL'd software in any form whatsoever.
You're right to point out that Section 6 applies something less than the whole LGPL.
The distinction which many people fail to make is between what the LGPL is versus what the LGPL mandates. In other words, the LGPL propogates itself to works which are modifications of the original LGPL'd work, but the LGPL only slightly constrains what you do with a (executable) program that uses the LGPL's work unmodified. Those constraints are delineated in Section 6 of the LGPL. Those constraints are not the same thing as the LGPL.
Awhile ago I wrote up this http://www.cs.utah.edu/~gk/teem/lgpl.html to clarify that distinction and justify why I chose LGPL for my software.
Now, if people are up in arms simply because the LGPL constrains how you distribute software which relies on LGPL's software, um, tough. They should be grateful that the LGPL is as unencumbering as it is, in comparison to the GPL.