The LGPL and Libraries Exposing a C++-Interface

The LGPL is a common open-source license for libraries. One of the key point of the LGPL is the separation of the LGPL-licensed library from the products using it; in particular, users should be able to supply their own versions of a given LGPL library to replace the one shipped with a software product.

If you provide the source code of your software product, then it’s kind of easy: users can recompile everything (i.e. your software’s source code and their own version of the LGPL library).

But what happens when you want to use an LGPL-licensed library in a closed-source commercial product?

Many developers say: “Just dynamically-link to the LGPL-library!” The idea here is to build the LGPL library as a DLL (on Windows), and to have your commercial software dynamically linking to that. So users can replace the DLL that ships with your commercial software with their own version of the DLL, built from their own version of the LGPL library. Unfortunately, this theory is not always true in practice.

In particular, let’s consider the case of an LGPL library written in C++, built as a DLL on Windows, and exposing a C++ interface that uses some STL classes. As we saw in a previous blog post, this is a highly-constraining design. For that to work properly, both the DLL and the calling EXE must be built with the same C++ compiler version, they must be both dynamically-linked to the same flavor of the CRT, etc. That’s very fragile.

So, in this context, just replacing the DLL that ships with the commercial product with a user-provided DLL won’t work in the general case, for example when the user-provided DLL is built with a different version of the Visual C++ compiler used for the EXE.

In other words, in this case the only way for users to replace the original DLL shipped with the product with their own version is to recompile everything, which does require access to the product’s source code (or at least to some parts of it).

So, in such cases, the LGPL doesn’t seem feasible for a commercial closed-source software product.

On the other hand, C-interface DLLs (designed with proper care for dynamically-allocated memory at the boundaries) are safely replaceable by users, without requiring recompilation of other modules dynamically-linked to them.

Disclaimer: I’m not a lawyer, and this post is not meant to give legal advice, but just to discuss a topic from a software developer’s perspective. As always, respectful constructive comments are welcome.

 

7 Replies to “The LGPL and Libraries Exposing a C++-Interface”

  1. Well, there is nothing preventing the user from finding out what compiler you used to build your closed source and using the same one to rebuild the LGPL library. They don’t need your source code and still can update the LGPL library with a matching version.

    1. David: Thanks for your comment. But is it a *restriction* of the LGPL to force the user to a given specific C++ compiler to rebuild the DLL?

      1. The LGPL doesn’t discuss anything about which toolset is used. It does not prohibit you from building with an ultra expensive and rare compiler; It only says the user must be free to substitute a different version of the LGPL library to work with your program. It’s easiest to comply by dynamically linking to the LGPL library, since the user can then just substitute the DLLs at runtime. But, it is possible to comply even with static linking – simply make your .obj files (either separate or bundled into a .lib) available, and the user can then link this with the desired version of the LGPL library. Of course, whatever the packaging, the modules must be binary compatible with your .exe, as you say.

        1. So, are you saying that it’s not a violation of the LGPL to restrict the toolset (e.g. specific C++ compiler) for building and substituting an LGPL-licensed DLL? That’s a key point for me.

          For example, in the Qt FAQ section 3.7 “What are my obligations when using Qt under the LGPL?”, it reads:

          “The user of your application has to be able to re-link your application against a different or modified version of the Qt library.”

          What if the “different or modified version of the Qt library” requires a different version of the Visual C++ compiler than the one used to build your closed-source commercial software?

          Thanks.

          1. The provider of the ‘different or modified version of the Qt library’ is responsible for ensuring it is binary compatible with the closed source application.

  2. Not a lawyer here too, but here are another 0.5c:
    The QT (and in principle LGPL) license says, my emph: “The user has to be able to re-link your application against *a* different version “. This is very different from “The user of your application has to be able to re-link your application against *any* different version”.

    Forming the application so the user could re-link against *any* version is obviously an absurd requirement. For one, the user can insert bugs that would prevent linkage – would that be an LGPL violation? It is only reasonable for the application writer to enforce limitations on the versions that can be linked against the app, and compiler version is a very reasonable one at that.

    1. Thanks for posting your comment. What you wrote makes sense. I emailed FSF Licensing a few days ago asking about that, but so far got no answer.

Leave a Reply

Your email address will not be published. Required fields are marked *