On Sat, Jun 27, 2020 at 8:51 AM JacobK622 via Gcc-help <gcc-help@xxxxxxxxxxx> wrote: > What is the email for the glibc list and would it be bad netiquette to post this there? See https://sourceware.org/lists.html It would only be bad netiquette if your question was already answered. > "For questions about glibc's licence you should ask the glibc list or > consult a lawyer. The first paragraph of clause 5 of LGPL v2.1 seems > clear to me: > ... > The second sentence in the LGPLv2.1 section 5 says "However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables." Keep reading! Two lines down, it says "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. " I'll bet you'll find that the public header files for glibc meet the above description, i.e. nothing you use from them is a macro or inline function longer than 10 lines. That means you're safe to ship commercial code that links to glibc in the normal way, and you won't have to release your source code. If you decide your app needs to be statically linked to a C standard library, you may want to look at newlib instead. But you almost certainly don't want to do that; linking to glibc in the usual (dynamic) way is fine for 99.9% of applications. - Dan
