> Good point, I thought that the requirement was substitutability and dynamic linking was just given as an example of how a library can be substitutable, but it appears that dynamic linking is sufficient.

You can satisfy the requirement without dynamically linking (by shipping object files or source code instead), making dynamic linking sufficient but not necessary. In practice, though, nobody seems to attempt anything other than dynamic linking against an LGPL library, or shipping enough source code for static linking (even if not all the source code).

> It's not clear to me exactly the meaning of these sections; if including bits from header files is truly allowed, then you could effectively circumvent the substitutability goal by simply inlining the whole library.

Substitutability represents a technical goal, and the library has to support that goal for it to prove useful. If the library provides the entirety of its functionality via inlines in header files, they clearly don't care about substitutability. And if you modify the library to move all of it into header files, you still have to supply the source for the modified version of the library, so you've broken substitutability but you haven't broken the copyleft. As far as I can tell, the LGPL's goal of substitutability seems primarily aimed at cases where you don't intend to substantially modify the library; after all, you can also change the library's API/ABI and thus make the original no longer substitutable. (Personally, I don't really see the point of the substitutability provisions anymore; I really just want a copyleft on the library itself.)

> I don't either, but I write a BSD-licensed library that I absolutely want to be usable with proprietary software without any difficulty.

Fair enough. However, in that case the copyleft on the LGPL software seems equally onerous, since users of your library would need to ship the source of talloc, even though they don't need to ship the source of your library. (One other interesting provision: the users of your library couldn't use a license that prohibits reverse-engineering.)

In any case, yes, talloc's license effectively makes it unusable by libraries that want to provide an all-permissive license. If you really want to use talloc, you might consider writing to the authors of talloc; they might prove sympathetic to the needs of a BSD-licensed library, and grant a suitable exception. (Personally, I'd like to see some standard wording for an exception similar to the one used in UPX, namely that you can use it under an all-permissive license as long as you use an unmodified version.)