Is LGPL OK for mostly header only library?

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:

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

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 GPL¹ 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".

¹With 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.

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.