回答:
プログラムがGPLの影響を受けることなく、独自のプログラムからGPL化されたプログラムを使用できますが、プログラムがGPLの条項に従うことなく、GPL化されたコードを独自のプログラムにリンクすることはできません。
既存のコマンドラインプログラムのGUIラッパーを記述した質問で提供されている例では、GPLのプログラムを実行する別のプログラムであれば、GUIはGPLの条件に拘束されません。別個のプロセスであり、既存のインターフェースを介してのみ通信します-たとえば、コマンドラインおよび/またはstdin / stdoutを介して。
GPL FAQからのいくつかの関連ビット：
2つの別々のプログラムと、2つの部分を持つ1つのプログラムの間の境界線はどこですか？これは法的問題であり、最終的に裁判官が決定します。適切な基準は、通信のメカニズム（exec、パイプ、rpc、共有アドレス空間内の関数呼び出しなど）と通信のセマンティクス（交換される情報の種類）の両方に依存すると考えています。
モジュールが同じ実行可能ファイルに含まれている場合、それらは1つのプログラムに確実に結合されます。モジュールが共有アドレス空間でリンクされて実行されるように設計されている場合、それはほぼ確実にそれらを1つのプログラムに結合することを意味します。
対照的に、パイプ、ソケット、およびコマンドライン引数は、2つの別々のプログラム間で通常使用される通信メカニズムです。そのため、通信に使用される場合、モジュールは通常別個のプログラムです。しかし、コミュニケーションのセマンティクスが十分に親密であり、複雑な内部データ構造を交換している場合、それも、2つの部分を組み合わせてより大きなプログラムと見なすための基礎となります。
GPLでカバーされたプラグインをロードするように設計されたフリーでないプログラムをリリースできますか？
プログラムがプラグインを呼び出す方法に依存します。たとえば、プログラムが単純なforkとexecのみを使用してプラグインを呼び出して通信する場合、プラグインは別個のプログラムであるため、プラグインのライセンスはメインプログラムに関する要件を作成しません。
プログラムがプラグインを動的にリンクし、それらが相互に関数呼び出しを行い、データ構造を共有する場合、それらはメインプログラムとプラグインの両方の拡張として扱われなければならない単一のプログラムを形成すると考えます。GPLで保護されたプラグインを使用するには、GPLまたはGPL互換のフリーソフトウェアライセンスの下でメインプログラムをリリースする必要があります。また、メインプログラムを使用するために配布する場合、GPLの条件に従う必要がありますプラグイン。
プログラムがプラグインを動的にリンクするが、それらの間の通信が、いくつかのオプションでプラグインの「メイン」機能を呼び出し、それが戻るのを待つことに制限されている場合、それは境界線の場合です。
GPLは、基礎となるコマンドラインプログラムに完全に適用されることに注意してください-配布する場合（ユーザーに別のソースから入手させるのではなく）、ユーザーにGPLのコピーを提供する責任があります。コマンドラインプログラムがGPLの下にあること（GUIラッパーがそうでなくても）を明確にし、要求に応じてコマンドラインプログラムのソースコードを利用できるようにします。もう一度GPL FAQから：
GPLで保護されたソフトウェアを、ユーザーが部分的に所有権があると知っているシステムの「一部」と呼ぶソフトウェアを配布した場合、ユーザーはGPLで保護されたソフトウェアに関する権利を確信できない可能性があります。しかし、もし彼らが受け取ったものが無料のプログラムと別のプログラムであると知っていれば、彼らの権利は明確になるでしょう。
標準免責事項：私は弁護士ではありません。弁護士であったとしても、あなたの弁護士ではありません。明確な回答が必要な場合は、管轄区域での実務の認可を受けている適切な法律専門家に相談してください。
それはあなたのプログラムがGPLプログラムをどれだけ正確に「使用しているか」に依存します。GPL FAQにはかなり長い説明がありますが、それでもまだ解釈の余地がたくさんあります。
GPLで保護されたソフトウェアを独自のシステムに組み込むことはできません。（...）ただし、多くの場合、GPLで保護されたソフトウェアを独自のシステムと一緒に配布できます。これを有効に行うには、無料プログラムと非無料プログラムが独立したプログラムで通信し、それらが効果的に単一のプログラムになるような方法で結合されていないことを確認する必要があります。（...） 2つのプログラムが1つのプログラムの2つの部分になるように結合されている場合、それらを2つの別個のプログラムとして扱うことはできません。したがって、GPLはすべてをカバーする必要があります。コンパイラーとカーネル、またはエディターとシェルのように、2つのプログラムが十分に分離されたままであれば、それらを2つの別個のプログラムとして扱うことができますが、適切に行う必要があります。問題は、フォームの1つにすぎません：自分が何をしているかをどのように説明するか。なぜこれが重要なのでしょうか？コレクション内のGPLで保護されたソフトウェアの無料ステータスをユーザーが明確に理解できるようにするためです。
主にコマンドラインGPLプログラムを呼び出すために存在するGUIの例では、2つは明らかに1つのプログラムを形成するため、GPLの下でコードをリリースする必要があると思います。
いや
GPLコードは、他のGPLコードでのみ使用できます。
ウィキペディアのGPL記事の最初の行を引用：
GPLは一般使用向けの最初のコピーレフトライセンスです。つまり、派生著作物は同じライセンス条件でのみ配布できます。
それに加えて、GPLは長さが数ページあり、いくつかのバージョンが存在します。
警告、先に個人的な暴言！
個人的には、GPLライセンスは非常に制限的でウイルスに似ているため、嫌いです。彼らはそれを「無料」と呼んでいますが、実際はまったく逆であり、GPLコードは他のGPLコード以外では使用できません。したがって、現在のプロジェクトがオープンソースであるかどうかに関係なく、他のプロジェクトをGPLに強制したり、ライブラリ全体を書き換える必要があります。たとえば、freeBSDのような巨大なオープンソースプロジェクトがありました。ライセンスは互換性がないため、数十万行のlinuxコードを書き直さざるを得ませんでした。 GPLと互換性がありません。
「何でもやりたい」という意味で本当に「無料」のライセンスが必要な場合は、BSDまたはMITライセンスをお勧めします...実際、他のほとんどのライセンスは問題ありません。GPLのみが本当に問題となるのは、それがいかに制限的であり、他の人にそれを強制するかだからです。最後に、非常に複雑です。
ああ、それは片道チケットでもあります。GPLはほとんどのライセンスからライセンスされたコード/ライブラリを使用できますが、これらのライブラリ/コードはGPLコードを順番に使用できません。