9

I compiled SFML using CMake for MinGW. After running "mingw32-make install" everything is built and installed with no errors. But when running the examples - pong.exe, sound.exe, sound-capture.exe and voip.exe all depend upon openal32.dll.

I specified SFML_USE_STATIC_LIBS = true when configuring CMake and all other dependencies of the example executables are only upon native windows dlls.

Can anyone explain why it has dynamically linked to openal32 (but nothing else)?

Edit: I just came across this thread http://en.sfml-dev.org/forums/index.php?topic=262.0 which is discussing exactly the same problem. I would've thought (since this is from 2008) that this would have been implemented by now. Or is it still in the same situation?

Edit 2: The responses here http://en.sfml-dev.org/forums/index.php?topic=18119.0 would indicate that OpenAL must be linked dynamically due to the license. Can anyone confirm whether or not the license allows distribution of openal32.dll with the executable?

Kvothe
  • 1,819
  • 2
  • 23
  • 37

1 Answers1

5

I am not a lawyer (and I did not stay at a popular hotel chain last night).

The OpenAL implementation they are using is licensed under the GNU Library General Public License (LGPL), version 2. LGPL v2 requires that:

If you link a program with the library, you must provide complete object files to the recipients so that they can relink them with the library, after making changes to the library and recompiling it. And you must show them these terms so they know their rights.

The easiest way to allow users to relink a closed-source game with a modified OpenAL library, is to make that game link dynamically with the openal32.dll. That way, they can simply swap out the openal32.dll with a modified one, and place it beside your game executable.

As for this part of the license:

And you must show them these terms so they know their rights.

Simply inform your users that your game uses OpenAL, and somehow give them access to the body of the LGPL v2 text.

You may distribute the openal32.dll with your game, under these conditions:

For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code.

That can be met by simply informing your users that your game uses OpenAL, and providing a link to where they can download the source code.

To inform your users of their rights regarding OpenAL, you could do it in an "About" page within the game iteself, or in an preface/appendix of the distributed game manual. For example:

This game uses the following open-source software:

And while you're informing your users of OpenAL, you could also volunteer to give attribution to other open-source libraries that your game uses, such as SFML.

Emile Cormier
  • 28,391
  • 15
  • 94
  • 122
  • Excellent, thank you! I had come to similar conclusions about the LGPL terms but your answer has cleared things up for me immensely. – Kvothe May 10 '15 at 14:27
  • Does this mean that if you were to statically link to a library licensed under LGPL that you would have to make the object files generated by your source code available (but not the source code itself) so that the user could relink them together with a different version of the static library? – Kvothe May 10 '15 at 14:39
  • 1
    It says so directly in the LGPL license itself: _If you link a program with the library, you must provide complete object files to the recipients so that they can relink them with the library, after making changes to the library and recompiling it._ – Emile Cormier May 10 '15 at 18:25
  • 1
    So, for a closed-source game, it's either: (game object files + static lib) or (game executable + dynamic lib). I don't have any statistics, but it's my impression that the vast majority would prefer the latter method for practical reasons. – Emile Cormier May 10 '15 at 18:31