I ran across this on the web recently, and it raises the question of whether the authors of the page or myself are misunderstanding the terms of the LGPL. I was under the impression that dynamic linking was expressly allowed by the LGPL, but these guys seem to be going very far out of their way to avoid it:

Quote: MHKKit requires libavcodec (part of the ffmpeg project) to decompress MPEG-2 audio files. However, MHKKit is not statically linked or dynamically linked to libavcodec, but rather will attempt to dynamically load libavcodec at runtime if it is found. MHKKit can consequently run with or without libavcodec and is thus in full compliance with the terms of the GNU Lesser General Public License.

Am I misunderstanding the terms of the license?

You can use an LGPL library without releasing your own code as long as you dynamically link to the LGPL library; they seem to be going to an extreme to comply, but they aren't doing anything that violates the license.

Quote: Original post by SiCrane
You can use an LGPL library without releasing your own code as long as you dynamically link to the LGPL library; they seem to be going to an extreme to comply, but they aren't doing anything that violates the license.

Glad to hear I had it right. Yes, I didn't think there were doing anything wrong, it just seems like a lot of trouble to go to.

There are several problem areas with LGPL because it must be completely removable.


Library authors can (usually out of ignorance) implement their libraries so they incorporate portions of the LGPL content into the application code. That causes the normal GPL viral conditions. The usual offenders are inline functions, template expansions, and macros.

Even if the library is well written, the linker might, as a side effect of aggressive optimizations, incorporate some tiny bits of the library content into the application without you realizing it. This kind of violation can be very subtle, but it is still a violation.



Many companies place an absolute ban on GPL, LGPL, and all other viral licenses because of these and other nuances.



It looks like the MHKKit people are choosing to play it safe (which is always a good idea) and ensure that they can run completely independent of the LPGL code.

They do it because the .lib file that stubs your executable for run time linking is actually compiled by the compiler and therefore a product from their source code. Therefore your executable actually contains a derivative product of their code. Yes it's extreme and they probably got the advice from a lawyer :P

Quote: Original post by asp_
They do it because the .lib file that stubs your executable for run time linking is actually compiled by the compiler and therefore a product from their source code. Therefore your executable actually contains a derivative product of their code. Yes it's extreme and they probably got the advice from a lawyer :P

This isn't necessarily a problem with the LGPL, and enters the gray area I mentioned in my post.

That is acceptable use, by definition within the LGPL. The specific wording is "any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library."

The linker (almost always) limits itself to the interface, which is fine. Aggressive optimization between files might incorporate more than just the interface. That's where it gets a little vague, and good lawyers don't like vague.

For my security, when I use someone else software, I use things licensed under cool licenses like BSD-like :)

I currently avoid GPL and LGPL at all costs when the work can be considered commercial (even it if is not, that is, if the work is in a gray area between comercial and non-commercial, I avoid GPL-like licenses)

But I am not against opensource or anything, I use several GPL softwares, but as I said, I use GPL SOFTWARES, not libraries...