> A good example are generics or template programming. E.g. even in C++ if there is heavy use of template programming around the library boundary can make LGP i

> A good example are generics or template programming. E.g. even in C++ if there is heavy use of template programming around the library boundary can make LGP infeasible for that use case. And we are still in C++ which is rather close to C in how it compiles stuff. ... You think people haven't solved this problem for literal decades in c++ ? If your LGPL lib uses a template : If it gets inlined the license says that it's fine and not breaking LGPL that you won't be able to change the call sites. All c++ compilers will still produce a non-inline version of the symbol with weak linkage that can be replaced in the cases where inlining did not happen. Surely rust does the same in order to comply with LD_PRELOAD semantics ? (Even MSVC does that inline symbol exporting afaik). Like, you think people who wrote the LGPL did not consider the case of macros in C for instance ? > If we go a step further, e.g. into Rust it becomes even more of a mess. (It is possible, at least theoretically, with a lot of hacks and restrictions, but totally a nightmare not worth even considering. And again if generics are used a lot, all the generic code at the interface boundary leaks.) If that's such a nightmare then don't depend on the work of people who wrote LGPL libs and find an alternative instead ?