Does using GCC specific builtins qualify as incorporation within a project?

Question

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.

Answer 1

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.

Answer 2

Without additional details, I believe you have answered your own question:

... and when compiled will link GPL licensed code ...

The act of linking in GPL code is binding your project to a GPL project.
I would double check that you understand the licensing of those builtins correctly.

Whether or not the FSF / GNU would attempt to pursue a claim on that basis is a completely different question. I'm leaning towards "not very likely."

I'm revising my answer based upon some additional research. In short, I don't think there's a problem and your code would not be required to be licensed as GPL.

From the FAQ:
Using GNU tools
System Lib #1
System Lib #2
Also see Section 1 of the GCC GPL.

The builtins would qualify as system libraries as they enable significant function for GCC as well as provide an interface implementation for the various C* standards. They're just extensions of the tool.

Most likely, the builtins are released as LGPL, so you'd be exempt due to the linking exclusion. Even if they aren't, you're still exempt based upon the system library exemption.

Answer 3

If by "builtin functions", you mean stuff like strlen() and read(), you're barking up the wrong tree. GCC doesn't supply those, the C library from which you load the standard headers and against which you link your code does. It's that package's license you need to be concerned about.