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.

When you pull in a header file as required for function declarations and interoperability, that is allowed in the license. But sadly many GPL projects will include code in the header files beyond the recommendations. [...] the inclusion of the code might be sufficient to trigger the viral aspect if someone wanted to sue.

may convey such object code under terms of your choice;

if(material not limited to [...], accessors, or small macros, inline functions and templates)

give prominent notice and accompany with a copy of the GPL.

(abbreviated from §3 here)

It should in my opinion read "accompany with a copy of the LGPL", but it says "GPL". So basically, as long as it's small inline functions and such, no worries at all, and if it's "big stuff" you need to give prominent notice and include a copy of the GPL [sic], but you can still distribute your own work under whatever license you wish.

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.

While that is indeed so, the clause only allows reverse engineering for the purpose of debugging modifications of the original library only.

You could certainly try writing an awesome LGPLed H264 library and hope that someone (say, CyberLink) uses it, then modify your library and reverse engineer their software to steal the BluRay decryption keys based on "Hey, I have the right to reverse engineer that software". But my guess is, you would likely still find yourself in court, since CyberLink would argue that this is not necessary for the purpose of debugging the modifications to your library.

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".

I was thinking more along the lines of updating say an LGPL'd networking library by modifying it to directly work with the network driver "for performance reasons", which ofcourse just happened (tm) to be incompatible with the products DRM system, "forcing" you to bypass it in order to upgrade the library.

Perhaps something less extreme, such as modifying a renderer to disable the z-buffer when rendering players, giving the modifier an unfair advantage in a multiplayer game.

In many cases, you can greatly affect the behavior of a product by altering a library. I wonder how far one could take it if they were hellbent on messing with [the creator of] the product.

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.

In many cases, you can greatly affect the behavior of a product by altering a library. I wonder how far one could take it if they were hellbent on messing with [the creator of] the product.

Yes, you didn't force them to use your library, nor did they pay anything for it, and yes they acknowledged "no warranty express or implied, no fitness for any purpose" and agreed not to sue you for compensations. However, note the wording "to the extent permitted by applicable law".

If we are to play baseball, and I pay you $100 for signing "no guarantee that you won't get injured, and no damages whatsoever", and then I start hitting you on your head with the bat, that signed paper won't save me from a conviction or from paying your hospital bill. It just doesn't matter what I made you sign, since I clearly did it on purpose.

Worded differently, there is a difference between software that is faulty, and software that is deliberately made to damage someone. Heck, malware writers should just put their malware under GPL otherwise.

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.