4

Similar questions have been asked before, but I'm not satisfied with the answers.

In LGPL v2.1, Section 5 states that a binary may be derivative to an LGPL library if it was compiled with the library's headers, because its object code can be derivative to the library, and so it should follow the obligations from Section 6 of the license.

The following exception is given: using "numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length)" does not trigger the Section 6.

Now consider a simple program using the function strlen and linking dynamically to glibc which licensed under LGPL v2.1. The function clearly does not fall under any of the cases of the exception - it's not a macro, and it's not defined as inline. Therefore for the compiled binary to be legally distributed, it should be accompanied with a copy of the glibc sources and with the program's object files - to comply with Section 6 of the license.

Right? Except that nobody does that. So what am I getting wrong about this?

Improve this question
2
  • Normally, the object files would only have to be distributed in case of static linking, or on systems that don't allow replacing the LGPL library in question with a modified one. As far as I'm aware, that's always been possible on GNU/Linux with shared libraries (e.g. you can replace the .so with a different one or you can update the symlink to point to a different one). Same applies to Windows and macOS. Not sure about Android and/or iOS, though.
    – Brandin
    Commented Apr 16 at 11:49
  • Can you substantiate your claim that the program must be accompanied by the glibc sources. For example, prove that the implementation for strlen really get copied from the glibc library into the test executable. Note that for functions like strlen the compiler itself may know about them and expand them without relying on glibc. In that case, the glibc license is irrelevant.
    – Bart van Ingen Schenau
    Commented Apr 17 at 10:51

1 Answer 1

Reset to default
3

First of all, any recent glibc is under the LGPL v3 rather than v2.1 so I'll refer to the LGPL v3 here, but the same principle applies for v2.1 just with different wording in the licenses.

The LGPL v3 is a set of additional permissions to the GPL v3; when distributing the binary of a GPL work you must include the "corresponding source". "Corresponding source" is defined in Section 1 of the GPL v3 as

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries [...]

That last sentence there is the critical bit - (g)libc is almost by definition the system library so is not required to be distributed.

Improve this answer
7
  • 1
    Firstly, it still uses "GNU Lesser General Public License v2.1 or later" license. Secondly, my understanding of that statement about "Corresponding source" is that if your project is using some other LGPL library, and you're preparing a source bundle to fulfill LGPL obligations for that other library, you're allowed to skip glibc and similar system libraries. It does not cover this case.
    – user44168
    Commented Apr 16 at 11:12
  • This is one of the reasons RMS says that "Linux" distros are properly called GNU/Linux. Of course you can make a distro with some other libc or none at all, but then it wouldn't be a general-purpose system anymore. OP could you explain why the System Library statement "does not cover this case", i.e. why you do you think glibc is not a System Library according to this definition?
    – Brandin
    Commented Apr 16 at 11:46
  • The way I'm reading it, it's a sanity statement. When you're fulfilling your obligations to, say, GnuTLS, you don't need to include "the major components [...] of the operating system on which the executable runs" (to quote LGPL v2.1). However when you're fulfilling your obligations to glibc, glibc is not just a part of the ecosystem, it's the library that the license pertains to.
    – user44168
    Commented Apr 16 at 11:59
  • Note that the crucial thing I'd like to know is whether Section 5 triggers Section 6 at all, not if Section 6 offers some exceptions for providing the software bundle. To reiterate: is every binary compiled with glibc headers a derivative of glibc (in legal terms)?
    – user44168
    Commented Apr 16 at 12:02
  • 1
    @user44168 GPL v2 says that it need not be included "unless that component itself accompanies the executable." I don't recall seeing glibc itself normally being distributed with GNU/Linux programs. Of course, if it's a modified version of glibc, then LGPL would obligate that you distribute the source to that version anyway.
    – Brandin
    Commented Apr 16 at 13:18

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.