I have a question regarding the use of LGPL code in (commercial) closed-source software. (in this case games)

I'm currently implementing OpenAL soft into my game-engine.

OpenAL soft is licensed under the LGPL v2 license.(Link to the license on Github).

From what i've been able to gather is that as long as you link dynamically with the LGPL code (OpenAL) and thus allow the user to replace the LGPL part with his own version, then your code doesn't fall under the LGPL license. 

But i'm unsure about two things:

1) This section from the LGPL license:

Quote

However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library".  The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.

When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library.  The
threshold for this to be true is not precisely defined by law.

If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object
file is unrestricted, regardless of whether it is legally a derivative
work.  (Executables containing this object code plus portions of the
Library will still fall under Section 6.)

OpenAL soft provides us a DLL, the header files and an import library (.lib) for the function adresses (to which i'll get shortly)

So, does this mean that simply using/including the header files in my engine (even though they basically consist only of macros/constants and especially function declarations, but no implementations) results in the engine falling under the LGPL license simply because i included header files? (maybe i misread the license?)

2) Import libraries

The DLL provides an import library (.lib) which stores the function pointers of the DLL. Now, here is the thing: the DLL may be easily swappable after the game was compiled (which is not the case with a static library), but the import library is also linked at compile time.

Given that the .lib file stores the function adresses of the DLL, recompiling/modifying the DLL could theorethically break those function pointers as the binary would be different. > This wouldn't allow the DLL to be easily replacable.

Does this effectively fall under the "static linking" rule of the LGPL license?

If that's the case, is getProcAddress() (essentially getting the function pointers manually at runtime) the only "true" way of dynamically linking a DLL without making your own code fall under the LGPL license?

Any information on this topic would be greatly appreciated.

Short answer: no, including headers and statically linking the import lib are common practice. You're fine and have nothing to worry about. 

Long answer:

If you wanted to really shrink that grey area, you could wrap their DLL in your own headerless DLL, and link to that one at runtime with GetProcAddress, but that is madness

LGPL is a total grey area, and even though this is common practice, anyone can sue you for anything at any time, whether they have a good reason or not. If you want to be as safe as possible, get clarification in writing from OpenAL themselves, or use something with a normal licence. 

On 5/14/2018 at 12:03 AM, Hodgman said:

including headers and statically linking the import lib are common practice

So, statically linking the import lib still allows you to replace the DLL without issues?

From what i've read, import libs store the location of DLL functions inside the binary, thus i assumed that changing and recompiling the DLL (which results in a different binary) would make it incompatible with the statically linked import library.

39 minutes ago, Lewa said:

From what i've read, import libs store the location of DLL functions inside the binary, thus i assumed that changing and recompiling the DLL (which results in a different binary) would make it incompatible with the statically linked import library

Even if that is the case, the license only requires that you make sure that your program "will operate properly with a modified version of the Library that is interface-compatible with the Linked Version". In your case, it sounds like the actual authors of the library have decided (by themselves) to use header files and a static import lib as the interface to their library? If so, I would suggest that this is the interface that modified versions are supposed to be able to match, and if matching it is a difficult task, that's not your fault.