I also seem to recall something about the LGPL requireing that users can replace the LGPLed library with another version of it, including allowing people to reverse engineer your program to the extent required in order to update that library.

I wonder if one could abuse that to for example create a legal workaround for a DRM system.

If I recall correctly, Nvidia abused the LGPL to connect proprietary code with GPL code.

Note that the requirement you mentioned is simpler than you think. Merely being able to swap the DLL file with another one would be enough.

But does the license say that it only applies to a binary compatible version of the library, or could you for example add functionality that would require an initalization call not present in the shipped version? It would seem reasonable to only apply it to a drop-in replacement/upgrade, but is that really the case? I should probably check that license some time.

its only applicable to drop in replacements (same function signatures), there is no requirement to enable users to modify how your code interacts with the library.

The big problem with this requirement comes with closed platforms as it is impossible to comply with the license requirement on those

so no LGPL on iOS, Windows Phone, xbox, playstation, nintendo, etc, for a modern cross platform game LGPL licensed libraries are virtually useless. (Platform wrapper libraries can be useful for Win/Mac/Linux/Android ports but if your game relies on a specific LGPL licensed library to function you are cutting out a large chunk of the possible target platforms)

Interestingly, version 3 talks of "combined work" (so basically, any program using the library) whereas version 2 merely had this clause for "derived work" (which is much more relaxed). For example, a web browser that can be configured and built to include SSL/TLS support via a library such as e.g. OpenSSL or GnuTLS is clearly not a "derived work", but it would certainly count as "combined work".

Reminds me of the mess that's libcurl. Basically it can be built in a myriad of different configurations, and depending on how you built it the library may be permissive, or not compatible with the GPL, or compatible only with the GPL, etc. It's a total mess, it's like the developers basically decided to completely ignore the compatibility between the different licenses. That's seriously dangerous from a legal viewpoint, if one thinks about it.

I also seem to recall something about the LGPL requireing that users can replace the LGPLed library with another version of it, including allowing people to reverse engineer your program to the extent required in order to update that library.

I wonder if one could abuse that to for example create a legal workaround for a DRM system.

If I recall correctly, Nvidia abused the LGPL to connect proprietary code with GPL code.

Note that the requirement you mentioned is simpler than you think. Merely being able to swap the DLL file with another one would be enough.

But does the license say that it only applies to a binary compatible version of the library, or could you for example add functionality that would require an initalization call not present in the shipped version? It would seem reasonable to only apply it to a drop-in replacement/upgrade, but is that really the case? I should probably check that license some time.

its only applicable to drop in replacements (same function signatures), there is no requirement to enable users to modify how your code interacts with the library.

The big problem with this requirement comes with closed platforms as it is impossible to comply with the license requirement on those

so no LGPL on iOS, Windows Phone, xbox, playstation, nintendo, etc, for a modern cross platform game LGPL licensed libraries are virtually useless. (Platform wrapper libraries can be useful for Win/Mac/Linux/Android ports but if your game relies on a specific LGPL licensed library to function you are cutting out a large chunk of the possible target platforms)

It's true that the more liberal Open Source licences are best from the developer point of view - you can just include the source code in your project, which may be easier than dynamically linking, even for platforms like Windows and Android where this is possible.

But I don't think that makes LGPL virtually useless, you just have to take it for what it is. Sure, a BSD licenced library would be better for a developer all other things being equal, but then we might as well say that a proprietary library is useless if it isn't available for every platform, or you don't get the code to include directly. Also in cases where the platform can only run on a device if approved and can't be redistributed, due to legal or technological restrictions, then it is by design of the LGPL that this isn't allowed, and the wishes of the software developer of that library (no different to respecting the licence of any library, Open Source or proprietary). If it's such a problem, complain to the companies making those platforms closed - or pay up for the library that does what you want. Is one way more "open" - well this is just the old debate about preserving freedoms for users versus maximising freedoms for developers, and there isn't a right answer.