3

I have basic understanding problem with open source and licenses. Could someone please clarify some questions for the below scenario. Excuse me if it is very basic

  1. I'm writing a proprietary software in which i plan to use some open source libraries. I will also need glibc and a C compiler, but did not want to use the default gcc toolchain from my OS, so built my own using crosstools-ng

  2. Now in ct-ng, i guess the libstdc++ library gets linked statically(which is for c++ and i won't be using that in most case i guess) but from my toolchain configuration is my libc statically or dynamically linked? If that is the case, given that glibc is LGPL, and that i can link it to my proprietary software, will this static linking cause any issues to me wrt licensing? Can my software still be close sourced? or do i have to release the compiled objects.

My toolchain configuration is below, from this could someone point to me if glibc is statically or dynamically linked?

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)
nobody
  • 19,814
  • 17
  • 56
  • 77
devgp
  • 1,321
  • 3
  • 17
  • 36
  • If you are interested, I have created a site proposal on area51 for everything related to open source: http://area51.stackexchange.com/proposals/58715/open-source-licensing?referrer=8PFLrZ3ydnhFtbu7jPSDPA2 – Kurt Pattyn Sep 22 '13 at 11:24
  • 4
    I'm voting to close this question as off-topic because **it is about licensing or legal issues**, not programming or software development. [See here](http://meta.stackoverflow.com/a/274964/1402846) for details, and the [help/on-topic] for more. – Kevin Brown-Silva Jun 04 '15 at 23:52

1 Answers1

12

There are many reasons, both legal and technical, to make libc.so dynamically linked.

On the legal side, the LGPL license of GNU libc requires you to permit your users to enhance their libc; so if you sell a proprietary software which is statically linked (a technically bad idea), you need to give the means to your user to relink it to a better version of libc; concretely you'll probably need to also give the *.o object of your software.

On the technical side, dynamically linking libc.so is nearly required by all features taking indirectly advantage of libdl.so or of ld.so -i.e. using dynamic linking-, in particular the NSS related functions (like getpwent and getaddrinfo and many others, see nsswitch.conf(5) & nss(5)). Also, dynamically linking libc is much more efficient (the RAM is nearly shared by all processes using libc.so and the executable size is smaller; and most importantly, upgrading libc.so is easier).

BTW, did your company considered making your Linux software free (as in speech)? It does have many advantages, and many companies are choosing the open source route.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • Thank you so much for your response. I just made some corrections to my question. Only libstdc++ is linked statically. However, i understand your response when i comes to linking libc statically, as you say i should then consider releasing the object / linking dynamically so that users of my software can recompile with a newer libc. Making some portion of my linux software open-source is something that i'm considering(ofcourse apart from the opensource lib which is anyway opensource), but not the entire source, there will be some proprietary code. – devgp Jul 27 '12 at 18:29
  • The LGPL still requires facilitating the upgrade of any LGPL-ed library you link with. – Basile Starynkevitch Jul 27 '12 at 19:02
  • Dynamic linking isn't always the way. When you're write a soft with MinGW, upon being compiled and run under Windows it is have a habit to complain about missing *libc*. If you're write a small technical program that don't need an own directory(i.e. BIOS updater), the preferred choice would be to compile a *libc* statically. – Hi-Angel Aug 28 '14 at 15:01
  • 1
    It's probably worth mentioning in the answer that if there are ever any bugs or security vulnerabilities in libc, software that statically links it will need to be re-linked and re-released by the software vendor. Software that dynamically links it will automatically take advantage of libc updates shipped by the OS vendor. – nobody Oct 27 '14 at 20:15
  • I wonder where builtin libc functions fit into this? I mean gcc replaces `memcpy` with built in code for sizes less than 8192 bytes. That leaves the user no way of upgrading the library. It's effectively like statically liking `memcpy`. – Z boson Oct 28 '14 at 12:53
  • 1
    @Zboson that code isn't actually from glibc so there's no legal issue (gcc has a license exception for when your program contains libgcc code). – user253751 Mar 08 '18 at 04:28