gLibc / Philosophical question

Question

I have been studying the opportunity of using free software pieces to make proprietary softwares for a while and am aware of legal constraints implied by free-liecenses such as GPL and LGPL.

Nevertheless, there remains a whole mystery to me. gLibC is distributed as a LGPL piece of software, which enables to make proprietary softwares by linking. gLibc makes system calls to the kernel. The Kernel is GPL. Thus, by dynamic linking effect, the gLibc should be GPL, not LGPL (by contamination). I know that some kernel calls are specifically not GPL (a very few set of them...

Does someone know why this lib is permitted to be LGPL and is not GPL by contamination?

Regards, Apple92

Answer 1

For philosophical reasons the GNU/FSF guys do not consider a system trap as linking. They avoid a more precise meaning of "derived work" and "linking" (MySQL AB considered a socket connection to their database as linking!) like the devil avoids holy water.

This is because there whole idea of free software can break if this ever is going to court.

Technically it's IMHO total nonsense to see a system call as anything else then a dynamic linkage API call.

Answer 2

Which kernel? I'm not aware of any under strict GPL. Linux is under GPL2 with the additional permission to be used normally by non-GPLed software. The other commonly used kernels are under no version of the GPL.

Moreover, a LGPL piece of software can certainly link to GPLed software, although if the linkage is close enough it may wind up under the GPL in addition. Even if it is usually linked to GPLed software, it retains its own license.

Answer 3

http://www.kernel.org/pub/linux/kernel/COPYING

First sentence. Reasonable question, though.