GCC固有のビルトインを使用することは、プロジェクトへの組み込みと見なされますか？
GPLの下でライセンスされたプログラムにリンクするには、GPLの下でプログラムのソースをリリースすることも必要ですが、LGPLはこれを必要としないことを理解しています。 （L）GPLの用語はこれについて非常に明確です。
_#include "gpl_program.h"
_gPLライセンスコードにリンクしているため、GPLのライセンスを取得する必要があることを意味します。そして
_#include "lgpl_program.h"
_lGPLソースへのリンクを明示的に禁止しないように、自由にライセンスを取得できることを意味します。さて、何がはっきりしていないのかという私の質問は：
【質問開始】
GCCはGPLライセンスであり、GCCでコンパイルされますが、GPLがプログラムに組み込んだため、プログラムへの「統合」を構成することはありません。GCCに固有の組み込み関数を使用することは、「組み込み」を構成していません。このGPLライセンスコードに明示的にリンクされていますか？私の直感は、これが意図ではないことを教えてくれますが、合法性は必ずしも直感的ではありません。実際には心配していませんが、これがケースと見なされるかどうか知りたいと思います。 =
[質問を終了]
[さようなら]
私の呼びかけの理由は、__builtin_clzl()または__builtin_expect()のようなGCC組み込みがAPI 技術的におよびcouldが別の方法で実装されていることです。たとえば、多くのビルトインはLLVMによって複製され、GCCに固有の実装ではないという議論がなされる可能性があります。ただし、多くのビルトインには並列処理がなく、コンパイルするとGCCのGPLライセンスコードをリンクし、他のコンパイラーではコンパイルできません。ここで、API couldが別のコンパイラによって複製されるという主張をした場合、そのソースを配布しない限り、リンクするプログラムについて同じ主張をすることはできませんか？
私はこれについて合法的なヘビであることを理解していますが、GPLがより具体的ではないことは奇妙に思えます。独占的なソフトウェア作成者がGPLをバイパスして機能させるためには、GPLソフトウェアをバンドルしてもっともらしい否認性を排除する必要があるため、これを合理的な策とは考えていません。ただし、ビルトインがリンクを構成しない場合、GPLに反対するオープンソース支持者は、GPLのプログラムにリンクするBSD/MIT/Apache/Appleライセンス製品を単に作成し、彼らが意図していると主張することはできません。 GPLと同じ非GPLインターフェースを作成して、実際にコンパイルされるまでBSDライセンスを保持するには？
[さよなら]
余談申し訳ありませんが、法的な問題や影響に直面していないのに、私がこれを気にする理由は、多くの人が理解するとは思いませんでした。そこでの仮説についてはあまり心配しないでください。実際の質問に対する答えのどちらが意味するかを推定しているだけです。
短い答え：コードのコンパイルにGCCを使用することは、常に、かつて、そしていつでも安全です。
__builtin_expect()＆co。ほとんどが関数ではなく、構文拡張です。ライブラリ関数よりも、+演算子またはforキーワードに似ています。たとえば、__builtin_expect()は命令をまったく生成せず、特定のケースが他のケースよりも効率的になるように分岐を順序付けるようコンパイラーに指示するだけです（cpuは特定の方法でジャンプを予測し、そのパスでのジャンプを少なくします、等。）。コードを生成する「ビルトイン」であっても、プリミティブ言語構造によって生成される他のコードと同じです。これはコンパイラの通常の使用を構成し、通常の使用はGPLの対象にはなりません。- ただし、C/C++標準で定義されているか、
__builtin*および__sync*などを含むGCC拡張機能で定義されているかに関係なく、一部の言語構造はgccライブラリ（つまり、libgcc.a）への呼び出しを生成する場合があります。このライブラリはGPLでカバーされていますが、特別な例外が提供されており、任意のコードとリンクして、任意のライセンスの下で結果のバイナリを配布できます。 - 同じ例外がGNU stdlibc ++（
libstdc++.a/libstdc++.so）にも適用されるため、標準のC++ライブラリでも安全です。 - 標準Cライブラリ（オペレーティングシステムに付属not gcc）、GNU libc（Linuxの場合））はLGPLでカバーされていますが、これは- 動的異なるライセンスでのコードのリンク標準Cライブラリには、新しいカーネルの改善を活用するために頻繁に更新されるシステムコールインターフェイスが含まれているため、これを常に動的にリンクすることはお勧めしません。
追加の詳細なしで、私はあなたがあなた自身の質問に答えたと信じています：
...そしてコンパイルするとGPLライセンスコードがリンクされます...
GPLコードでリンクすることは、プロジェクトをGPLプロジェクトにバインドすることです。
これらのビルトインのライセンスを正しく理解していることを再確認します。
FSF/GNUがその根拠に基づいて申し立てを試みようとするかどうかは、まったく別の問題です。私は「あまりない」に傾倒しています。
追加の調査に基づいて、回答を修正しています。要するに、私は問題はないと思います。あなたのコードはGPLとしてライセンスされる必要はありません。
FAQから：
GNU tools を使用する
システムライブラリ＃1
システムライブラリ＃2
また、GCC GPLのセクション1を参照してください。
ビルトインは、GCCの重要な機能を有効にするだけでなく、さまざまなC *標準のインターフェース実装を提供するため、システムライブラリとしての資格があります。それらはツールの単なる拡張機能です。
ほとんどの場合、ビルトインはLGPLとしてリリースされているため、リンクの除外により除外されます。そうでない場合でも、システムライブラリの免除に基づいて免除されます。
「組み込み関数」とは、strlen()やread()のようなものを意味する場合、間違ったツリーを起動しています。 GCCはそれらを提供しません。標準ヘッダーをロードし、コードをリンクするCライブラリが提供します。心配する必要があるのはthatパッケージのライセンスです。