静态链接 GLIBC 和专有软件许可 [关闭]答案

【问题标题】：Linking GLIBC statically and proprietary software licensing [closed]静态链接 GLIBC 和专有软件许可 [关闭]
【发布时间】：2012-07-26 10:59:00
【问题描述】：

我对开源和许可证有基本的理解问题。有人可以澄清以下情况的一些问题。请原谅，如果它是非常基本的

我正在编写一个专有软件，我计划在其中使用一些开源库。我还需要 glibc 和 C 编译器，但不想在我的操作系统中使用默认的 gcc 工具链，所以使用 crosstools-ng 构建了我自己的

我的工具链配置如下，如果 glibc 是静态链接还是动态链接，有人可以指出我吗？

Target: x86_64-some-linux-gnu
Configured with: /home/balravin/tools/platform/x86/src/gnu/gcc/4.4.7/.build/src/gcc-4.4.7/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=x86_64-some-linux-gnu --prefix=/home/balravin/tools/platform/x86/obj/gnu/gcc/4.4.7/x86_64-some-linux-gnu --with-sysroot=/home/balravin/tools/platform/x86/obj/gnu/gcc/4.4.7/x86_64-some-linux-gnu/x86_64-some-linux-gnu/sysroot --enable-languages=c,c++,fortran --with-pkgversion='crosstool-NG 1.15.3' --disable-sjlj-exceptions --enable-__cxa_atexit --enable-libmudflap --enable-libgomp --enable-libssp --with-gmp=/home/balravin/tools/platform/x86/src/gnu/gcc/4.4.7/.build/x86_64-some-linux-gnu/buildtools --with-mpfr=/home/balravin/tools/platform/x86/src/gnu/gcc/4.4.7/.build/x86_64-some-linux-gnu/buildtools --with-ppl=/home/balravin/tools/platform/x86/src/gnu/gcc/4.4.7/.build/x86_64-some-linux-gnu/buildtools --with-cloog=/home/balravin/tools/platform/x86/src/gnu/gcc/4.4.7/.build/x86_64-some-linux-gnu/buildtools --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-threads=posix --enable-target-optspace --with-long-double-128 --disable-multilib --with-local-prefix=/home/balravin/tools/platform/x86/obj/gnu/gcc/4.4.7/x86_64-some-linux-gnu/x86_64-some-linux-gnu/sysroot --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.4.7 (crosstool-NG 1.15.3)

【问题讨论】：

如果您有兴趣，我在 area51 上为所有与开源相关的内容创建了站点提案：area51.stackexchange.com/proposals/58715/…
我投票决定将此问题作为离题结束，因为它是关于许可或法律问题，而不是编程或软件开发。 See here 了解详情，help center 了解更多信息。

标签： gcc cross-compiling glibc lgpl

【解决方案1】：

让libc.so动态链接有很多法律和技术原因。

在法律方面，GNU libc 的LGPL 许可证要求您允许您的用户增强他们的 libc；因此，如果您销售静态链接的专有软件（技术上是个坏主意），您需要为您的用户提供将其重新链接到更好版本的 libc 的方法；具体来说，您可能还需要提供软件的 *.o 对象。

在技术方面，所有间接利用libdl.so 或ld.so 的功能几乎都需要动态链接libc.so - 即使用动态链接，特别是与 NSS 相关的函数（如 getpwent 和 getaddrinfo 以及许多其他函数，请参阅 nsswitch.conf(5) 和 nss(5)）。此外，动态链接 libc 效率更高（RAM 几乎由所有使用 libc.so 的进程共享，并且可执行文件大小更小；最重要的是，升级 libc.so 更容易）。

顺便说一句，贵公司是否考虑过让您的 Linux 软件免费（如语音）？它确实有很多优势，很多公司都在选择开源路线。

【讨论】：

非常感谢您的回复。我只是对我的问题进行了一些更正。只有 libstdc++ 是静态链接的。但是，当我静态链接 libc 时，我理解您的反应，正如您所说，我应该考虑释放对象/动态链接，以便我的软件的用户可以使用更新的 libc 重新编译。我正在考虑将我的 linux 软件的某些部分开源（当然，除了开源库，它无论如何都是开源的），但不是整个源代码，会有一些专有代码。
LGPL 仍然需要促进您链接的任何 LGPL 版库的升级。
动态链接并不总是可行的。当您使用 MinGW 编写软件时，在 Windows 下编译和运行时，您会习惯抱怨缺少 libc。如果您正在编写一个不需要自己的目录（即 BIOS 更新程序）的小型技术程序，首选的选择是静态编译 libc。
答案中可能值得一提的是，如果 libc 中存在任何错误或安全漏洞，静态链接它的软件将需要由软件供应商重新链接和重新发布。动态链接它的软件将自动利用操作系统供应商提供的 libc 更新。
@Zboson 该代码实际上并非来自 glibc，因此不存在法律问题（当您的程序包含 libgcc 代码时，gcc 有许可证例外）。