I'm writing a library which is a template-rich C++ library. All templated functions and classes are defined inside headers. It also has some non-templated functions, which are implemented inside headers and included in the program when a special macro is defined. I also want to offer a dynamic library (and possibly a static library too) with all non-templated functions and classes (included in the library source files from headers with the help of the preprocessor). I want to license it under GNU LGPLv3, but I'm not sure is that right.

As far as I know, LGPL is OK for header-only libraries. But what about dynamic and static linking?

3 Answers 3


You, the library author, can publish your library under any valid license, and as far as we know, the LPGL 3 is considered a valid license. The question you need to focus on is not "is the LGPL OK to use for <library of type x>", but instead "does the LGPL have the intended effect on <library of type x>".

The key point of the LGPL is (in my opinion), that the users of your library can use the library in non-(L)GPL products, so your library can get used in more places. At the same time, the LGPL ensures that the users of the product where your library is incorporated still have the the same freedom for working on the code of your library and using a modified version of your library as if this third-party product were GPL licensed.

In LGPL v3, section 3 limits the freedom provided to downstream users in the case that there is significant code in header files: That code gets compiled into the executable, and authors of programs that uses your header files is not required to open-source their code. The only requirement is to notify the downstream user about the use of the LPGL library and to include the LGPL and the GPL1 in the distribution.

The way the LGPL works is that the author of a program using an LGPL library needs to enable the downstream user to replace the object code from the LGPL library used by arbitrary different object code. As the contents and logic of the header files enter the application itself, not (only) the object code of the library, the downstream user can not replace the header parts of the library. If a library is mostly header-only, there is only little "freedom to adapt/extend/fix the LGPL library in non-GPL products" remaining. Basically, the LGPL v3 has the same effect on header-only libraries as a permissive license like MIT or two-clause BSD, allowing anyone to link your library, as long as you are credited.

If you are happy with this effect of the LGPL v3, you should consider using MIT or BSD directly instead of using the LGPL v3, because both of these permissive licenses are easier to understand and mentioning LGPL may scare potential users of your library. On the other hand, if you are not happy with LGPL v3 working that way, and want a more strict copyleft requirement, consider these choices:

  • Use GPL v3 instead. This forces the authors of programs using the library to publish them using (L)GPL compatible license terms.
  • Use LGPL v2.1, which forces the author of a program using your library to release enough of the source code so that all non-trivial functions in the header files can be replaced, which allow significant changes on your library in an otherwise closed-source program. Make sure you do not include the "or, at your option, any later version" clause in your LGPL v2.1 license declaration, because that would allow authors of program using your library to "upgrade" to LGPL v3 and get to use the headers "for free".

1With LGPL v3, the LGPL text is not a complete license, but it contains only a set of clauses that explain in what way it is different from the GPL v3, and includes the GPL v3 "by reference". So to convey terms in completeness, you need to include the GPL v3 as well.

  • 1
    Header files have special status under section 3 of the LGPL v3. Their use will not force downstream users of the library to permit changes to the LGPL-covered parts, and will not force them to make their source available. For a header-only library, LGPLv3 is very similar to MIT.
    – amon
    Commented Jan 13, 2021 at 23:04
  • 1
    Regarding your footnote: The LGPLv3 is an extension to the GPLv3 to give additional permissions. Because of how the extension mechanism works, a copy of the GPLv3 license needs to be distributed as well. Commented Jul 10, 2023 at 7:18
  • @BartvanIngenSchenau Thanks for pointing it out. Footnote updated. I should have read the LGPL v3 more thouroughly before re-writing that answer, so I should have notived this reason myself. Commented Jul 11, 2023 at 22:38

It's not ok for LGPLv2.1, but it's ok for LGPLv3.

Terms under Section 5 of LGPLv2.1, will cause applications using LGPLv2.1-licensed C++ template header libraries to themselves be licensed under LGPLv2.1, if those template functions are more than ten lines of code each. This effectively turns it into a strong copyleft license, pretty much like GPLv2.

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.)

Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself.

Meanwhile, LGPLv3 fixed this problem by introducing Section 3:

  1. Object Code Incorporating Material from Library Header Files.

The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following:

a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License. b) Accompany the object code with a copy of the GNU GPL and this license document.

However, please note that Section 3 of LGPLv3 does not free the application author from the obligations of Sections 4d and 4e, which requires the application author to provide a way for the recipient of the combined software to modify the LGPLv3-licensed library, relink it with the application and install it.

For a LGPLv3-licensed C++ template-only header library, this makes it really hard for the application author, as he would have to make the minimum application source code, that uses the library, available to the recipient of the combined software, so that the recipient may recompile and relink the application with his modified version of the library.

Also, please note that application source code, and not object code, is required to recompile and link application software to its template source code.

This may cause proprietary application authors to avoid using LGPL-licensed C++ template header libraries, as they may not wish to expose any source code of their proprietary application.

This is explained in the libstd++ FAQ:

The LGPL requires that users be able to replace the LGPL code with a modified version; this is trivial if the library in question is a C shared library. But there's no way to make that work with C++, where much of the library consists of inline functions and templates, which are expanded inside the code that uses the library. So to allow people to replace the library code, someone using the library would have to distribute their own source, rendering the LGPL equivalent to the GPL.

This issue can be circumvented by using the LGPL-3.0-linking-exception. Please see this answer for details.

Another alternative, is to use the Mozilla Public License 2.0 (MPL2) license, instead of LGPLv3, as the better alternative for C++ template header libraries. It's also compatible with LGPLv2.1 and GPLv2. This too is explained in this answer.

Meanwhile, libstd++ solved this by using the GCC Runtime Library Exception, as linking exception to GPLv3.

  • "although the minimum application code does not have to be released under an open source license..." - I'm not sure if this is accurate. In LGPL it says under 4d0 that you must "Convey the Minimal Corresponding Source under the terms of this License.", where this License means the LGPL 3.0. So it seems that the proprietary app will need to divide the app into a proprietary portion and an "LGPL" portion that is indeed released under that license.
    – Brandin
    Commented Jul 12, 2023 at 8:06
  • @Brandin Thanks. I have removed that statement.
    – ruben2020
    Commented Jul 12, 2023 at 10:43
  • Is there an unambiguous definition whether including header files with nontrivial functions will create a "Combined Work", if no library code is linked? Granted, the definition "produced by combining or linking" can be read this way - but I can't find a legal of "combining", and given the permission to distribute object files using nontrivial functions "under terms of your choice", a point could be made that the intent of the license might be to not consider this kind of use as "combining". Commented Jul 12, 2023 at 11:42

You can definitely use LGPL 3 for both static and dynamic linking.

The way a program is "linked" to your library doesn't change the conceptual relationship between them - another author's application uses your library to perform some functionality. They are allowed to redistribute your library in order to perform this functionality but must state so, must note your copyright and must make the source available.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.