GCC Builtins – Do They Qualify as Project Incorporation?

gccgpllegalopen source

I understand that linking to a program licensed under the GPL requires that you release the source of your program under the GPL as well, while the LGPL does not require this. The terminology of the (L)GPL is very clear about this.

#include "gpl_program.h"

means you'd have to license GPL, because you're linking to GPL licensed code. And

#include "lgpl_program.h"

means you're free to license however you want, so that it doesn't explicitly prohibit linking to LGPL source. Now, my question about what isn't clear is:

[begin question]

GCC is GPL licensed, compiling with GCC, does not constitute "integration" into your program, as the GPL puts it; does using builtin functions (which are specific to GCC) constitute "incorporation" even though you haven't explicitly linked to this GPL licensed code? My intuition tells me that this isn't the intention, but legality isn't always intuitive. I'm not actually worried, but I'm curious if this could be considered the case.

[end question]

[begin aside]

The reason for my equivocation is that GCC builtins like __builtin_clzl() or __builtin_expect() are an API technically and could be implemented in another way. For example, many builtins were replicated by LLVM and the argument could be made that it's not implementation specific to GCC. However, many builtins have no parallel and when compiled will link GPL licensed code in GCC and will not compile on other compilers. If you make the argument here that the API could be replicated by another compiler, couldn't you make that identical claim about any program you link to, so long as you don't distribute that source?

I understand that I'm being a legal snake about this, but it strikes me as odd that the GPL isn't more specific. I don't see this as a reasonable ploy for proprietary software creators to bypass the GPL, as they'd have to bundle the GPL software to make it work, removing their plausible deniability. However, isn't it possible that if builtins don't constitute linking, then open source proponents who oppose the GPL could simply write a BSD/MIT/Apache/Apple licensed product that links to a GPL'd program and claim that they intend to write a non-GPL interface that is identical to the GPL one, preserving their BSD license until it's actually compiled?

[end aside]

Sorry for the aside, I didn't think many people would follow why I care about this if I'm not facing any legal trouble or implications. Don't worry too much about the hypotheticals there, I'm just extrapolating what either answer to my actual question could imply.

Best Answer

Short answer: Any use of GCC for compiling code is, always was and always will be safe.

  1. __builtin_expect()&co. are mostly not functions but syntax extensions. More similar to + operator or for keyword than library function. For example __builtin_expect() generates no instructions at all, it just tells the compiler to order the branches so that the particular case is more efficient than the other (cpu predicts the jump in particular way, fewer jumps on that path, etc.). Even for those "builtins" that do generate code, it's like any other code generated by primitive language construct. It constitutes normal use of the compiler and normal use is never covered by GPL.
  2. However some language constructs, whether defined by C/C++ standard or GCC extensions including any __builtin* and __sync* and such may generate calls to the gcc library (i.e. libgcc.a). This library is covered by GPL, but a special exception is provided that allows linking it with any code and distributing the resulting binary under any license whatsoever.
  3. The same exception applies to GNU stdlibc++ (libstdc++.a/libstdc++.so), so you are safe with standard C++ library as well.
  4. The standard C library (which comes with operating system, not gcc), GNU libc (in case of Linux), is however covered by LGPL, which only allows dynamic linking of code under different license. Since standard C library contains the system call interface that is often updated to take advantage of improvements in newer kernels it is not recommended to always link this one dynamically anyway.
Related Topic