クローズドソースアプリケーションからGPLライブラリにリンクできますか？

さて、誰もが重複した質問について叫ぶ前に、はい、私はすでにこのようないくつかの質問をここで見ました。しかし、誰も質問に答えません。

ライブラリを変更せずにGPL対応のライブラリにリンクする場合、ソースコードをリリースする必要がありますか？

この質問によると、答えはイエスです！

しかし、この答えは私にとって満足のいくものではありません。答えは基本的に、コードをオープンソースにすることなく、GPLコードを使用することはできません。

しかし、前のことが当てはまる場合、個人や組織がLinuxでプロプライエタリなソフトウェアをリリースすることは不可能であることを示しています。間違っているに違いありません。単に、アプリケーションが何か便利なことをしたり、ファイルを開いたり、コンソールに書き込んだり、TCP接続を作成したりするには、アプリケーションlibcがGPLでリンクされている必要があります。

だから私の質問は次のとおりです：サイト上の以前のすべての回答がそうであるように、GPLが別のGPLプログラムにリンクするプログラムはGPLでなければならないと述べている場合、独自のアプリケーションを作成/リリース/販売する方法は可能ですか？ Linuxで実行されるものは何ですか？上で説明したように、そのアプリケーションはLinux上で実行するためだけにGPLコードに好まれる必要があります。

より実用的な例では、非GPLアプリケーションでGPLが適用された共有ライブラリにリンクすると言いますが、それは非GPLアプリケーションを強制的にGPLに変換しますか？より具体的には、GPLライブラリを変更せずに使用し、そのライブラリを.soまたはとして配布.dllすると、アプリケーションがオープンソースである必要がありますか？

GPL libにリンクする場合、派生作品を作成し、コードはGPLである必要があります-これは、L GPLコードとは異なり、異なるライセンスコードの動的リンクを明確に許可します。libcを含むシステムライブラリはすべてLGPLです。

また、Linuxカーネルヘッダーとlibgcc（コンパイラによって暗黙的に呼び出されるライブラリ）には特別な例外があります。

一般的なケースでは、GPLライブラリにリンクしてコードを配布し、コードをGPLとしてリリースすることはできないという点で正しいです。

ただし、システムライブラリの例外があります。これは、Linuxライブラリに対してリンクし、非GPLライセンスで製品をリリースする方法です。

別の例外は、2つのライセンスが相互に互換性がある場合です。詳細については、FSF 互換ライセンスページをご覧ください。

最後に、GPL化されたライブラリの作成者は、非営利または趣味での使用など、特定の例外を作成できます。

残念ながら、ハードで高速なルールを作成するには潜在力が多すぎます。あなたの質問に詳細がなければ、あなたの答えは「たぶんできませんが、たぶんできる」でしょう。

簡単な答えは、誰も本当に知らないということです。（この議論はLGPLではなくGPLについてです。）

GPLには「派生著作物」について曖昧な言葉があり、さまざまな人々がさまざまな方法で解釈しています。コンセンサスは、静的リンクに違反しているようですが、システム割り込み（Linuxカーネルなど）を介した呼び出しには違反していません。後者は、主にOracleのような企業がLinuxで出荷されており、訴えられていないという事実に基づいています。ライセンスでは明確ではありません。

動的リンクは不明であり、おそらく70/30は違反していると言っています。パイプまたはリモートプロシージャコール、おそらく30/70を使用してプログラムを呼び出しても、これは本質的に同じことですが、違反しません。COM経由の呼び出し、またはJava Jarの使用は完全に不明確です。

基本的に、疑問があり、弁護士が好きでない場合は、GPLから離れてください。