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.


Open-Sourcing MFC: What Do You Think?

There is an idea on Visual Studio User Voice about open-sourcing MFC.

What do you think about it? Would it be good or bad for the development of MFC and for the MFC community?

For new C++ projects there are several options available. For example: using Qt to develop cross-platform C++ applications, or WTL for something more Windows-specific, just to name a few.

But MFC is still used in several C++ legacy projects (including very large enterprise applications) still active in maintenance mode. With MFC open source, the community and Microsoft could submit new code and patches while Microsoft could monitor the quality of the submitted code and support an official branch.

My original Visual C++ 6 box.
My original Visual C++ 6 box (…memories from the MFC’s “Golden Days” 🙂 )

Please feel free to share your opinions on Visual Studio User Voice, or leave comments here.

Please try to develop a civilized discussion, and be courteous and kind even when you disagree.