What are the implications of glibc? The library is installed on most GNU/Linux systems (and maybe others, don't know). The thing is it is supposedly licensed with LGPL, but I am not sure which version (their website, unlike other free software projects, is ambigous about it). Anyways I have am slightly worried about the implications of it. Firstly: the LGPL supposedly allows commercial projects. It places however some restrictions on the programs that use it. Since every program written in C uses standard library functions (or not every but most), then it would mean that somehow linking the program with the library makes the program bound by LGPL license. What if glibc had LGPL v3 license, at least for some files. In this case, would my program be susceptible IN ANY WAY to the restrictions against "tivoization"? I hope my understaning of this issue is wrong and LGPL does not apply to any part of my program whatsoever, even if I use standard C lib functions in my software. I would be glad for clarification of this issue, even if it seems stupid for some of you.
-
2According to the libc README, the library's licensing is in COPYING.LIB, which currently holds the text of the LGPL v2.1. However, I think as a hypothetical, "What would be required with respect to Tivozation if I use an LGPLv3 libc library?" is a fine question (and one which I am personally not prepared to answer at the moment).– apsillers ♦Commented Sep 20, 2016 at 15:34
2 Answers
Under the normal circumstances that your question present (i.e. dynamic linking to a library assumed to exist on the user's system and thus not distributed with the program) the following part of the license text will save the day for any program using glibc:
A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a “work that uses the Library”. Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
-
thank you, this is the answer I needed and clears up the issue.– SpidyCommented Sep 20, 2016 at 19:07
-
What if you want to put a copy of glibc in your tivoized box, either as a dynamic library, or statically linked with some binary blob? Is that OK?– KevinCommented Sep 20, 2016 at 22:18
-
1@Kevin: if you put a library in your tivoized box, then you are distributing it and you need to follow the term of the license (and then LGPL3 forbids this).– Zimm i48Commented Sep 21, 2016 at 8:33
-
2This answer is actually not correct, the quoted section is referring to the source code of the work. When the source code is linked, it IS covered by LGPL. The next line of the LGPL says the following, "However, linking a 'work that uses the Library' with the Library creates an executable that is a derivative of the Library [...] the executable is therefore covered by this License". Now, if the software is linked against another LIBC library, but works with GLIBC when run, then it would not be covered.– syplexCommented Aug 23, 2019 at 18:49
Whatever the glibc license is, it implements, as you note, standard C lib functions. That is, it implements a standard API. Consequently, a program which uses functions from the library (without modifying the library) cannot be considered a derivative work of the library (because you could replace the library by any other implementation of the same standard API).
That being said, if you bundled the library along with your program and distributed the whole, you would still be bound by some of the terms of the license, but if you just assume the user's system has a standard C lib and dynamic link to it (as suggested by @MansGunnarsson), then you are not bound by any of these terms (whatever they may be). So the question of the license being LGPL, GPL or proprietary does not matter anymore.
-
4Unless you use non-standard functions, which glibc contains plenty of. Commented Mar 19, 2018 at 23:35