オプションで、クローズドソースアプリケーションでシステムAPIを介してGPLライブラリを使用する
次の状況を考慮してください。
クローズドソースアプリケーションを作成し、それをAと呼びましょう。AはシステムAPI（つまり、OSによって提供される）に依存します。システムAPIは、さまざまなバックエンドを使用するように構成できます。各バックエンドは単純な文字列値によって識別され、この識別子を介して選択されます。 API自体は、GPLのような要件に拘束されません。
現在、特定のバックエンド（B）が推奨されますが、GPLライセンスです。アプリケーションはそれなしで実行され、パフォーマンスの低下やその他の欠点があるだけで、他のバックエンドが利用可能になります。
次のいずれかが許可されていますか？
- 識別子をBにハードコーディングする
- 利用可能なバックエンドを自動的に選択しますが、利用可能な場合はBを優先します
- ユーザーにバックエンドを選択させる（そしてBを強く提案する）
また、AとBを一緒に出荷するか、Aだけを出荷して、Bをインストールするとアプリケーションのパフォーマンスが向上することをユーザーに提案するかによっても異なりますか？
私は一般的に3つのオプションはすべてOKだと思います。特定の文字列をシステムAPIに渡すと、派生作業（IMHO）の対象となることはほとんどありませんが、BのFAQは基本的にどのようにBの関数を呼び出すかは関係ありませんが、どのように使用してもプログラムは派生作業になります上記の3つの場合でも問題はありませんか？
追伸：Aをクローズドソースにするのは私の決断ではないので、GPLを行うことはできません。追伸2：システムAPIとBの名前は省略して、質問をより一般的なものにしていますが、違いが見られる場合は追加できます。
編集：別の観点から：ユーザー（プログラマーではなく）はいつ派生作品を作成しますか？ 3番目のケースでは、ユーザーがAとBをインストールし、Bをアクティブに選択したため、派生作品を作成することは明らかです。これは、コメントのMSaltersの主張と一致します。 2番目のケースは、少なくとも作業がBに依存しないことを明らかにしているので、これも問題ない可能性があります。
おそらく、GPLのspiritで、作者に連絡するのが最も多いでしょう。しかし、FAQエントリがGPLの実際のテキストと一致しているかどうかはわかりません。
TL; DR：FSFはプロセスとプログラムを区別せず、結果のプロセスにのみ適用されるプログラムの制限を示唆しています。
GPLは基本的に著作権を介して機能します。特に、それは配布ライセンス（使用をカバーしていません）であり、GPLの下に置かれた作品に限定されています。
ここで問題の1つは、作業がGPLに該当し始める時期と、それがどうなるかです。 FSFは正しいと思います。プラグインBをロードすると、プロセスはGPLに該当します。
あなたのプロセス。あなたのプログラムではありません。 2つを組み合わせたメモリ内のプロセス、つまり派生した作業のみです。組み合わせが行われる前は、法的な意味で派生した作業は存在しませんでした。したがって、GPLはプログラムの条件を指示することはできません。法的根拠はありません。
もちろん、プログラムとプラグインBを1つのプロセスで組み合わせて作成した派生作品を使用することもできます。 GPLは明示的に使用を許可します。このプロセスをVMで実行し、VMのクローンを作成した場合、このVMイメージの配布は禁止されます。これらのまれなことはカバーされています。しかし、通常、プロセスはコピーされないので、著作権の下での彼らの法的保護はかなり無意味です。
ライブラリBがプレーンGPLライセンス（LGPLまたはクラスパスまたはリンク例外のあるGPLのようなバリアントではない）を使用している場合、BのFAQは、フリーソフトウェアファウンデーションがこれまでのところ正しいです（GPLライセンスを起草した人）そのGPLコードがプログラムの他の部分と同じプロセスで実行される場合、そのプログラムはGPLコードの一部から派生した作業であると見なします。
FSFのスタンスを明確にするには、FAQから次の回答を参照してください。
ライブラリが（LGPLではなく）GPLの下でリリースされた場合、それを使用するソフトウェアはGPLまたはGPL互換ライセンスの下にある必要があるということですか？（ ＃IfLibraryIsGPL ）
はい。実際に実行されるソフトウェアにはライブラリが含まれているためです。
GPLには、対象となる作業で静的にリンクされたモジュールと動的にリンクされたモジュールに対して異なる要件がありますか？（ ＃GPLStaticVsDynamic ）
いいえ。GPLでカバーされた作業を他のモジュールと静的または動的にリンクすると、GPLでカバーされた作業に基づいて結合作業が行われます。したがって、GNU General Public Licenseの契約条件は組み合わせ全体をカバーします。関連項目 GPLソフトウェアでGPL互換ライブラリを使用するとどのような法的問題が発生しますか？ ==
フリーでないプログラムのプラグインを作成するときにGPLを適用できますか？（ ＃GPLPluginsInNF ）
プログラムがforkとexecを使用してプラグインを呼び出す場合、プラグインは個別のプログラムであるため、メインプログラムのライセンスではそれらの要件はありません。したがって、プラグインにGPLを使用でき、特別な要件はありません。
プログラムがプラグインを動的にリンクし、プラグインが相互に関数呼び出しを行い、データ構造を共有する場合、それらは単一のプログラムを形成すると考えられ、メインプログラムとプラグインの両方の拡張として扱う必要があります。これは、GPLでカバーされたプラグインとフリーでないメインプログラムの組み合わせがGPLに違反することを意味します。ただし、プラグインのライセンスに例外を追加し、プラグインを無料ではないメインプログラムにリンクする許可を与えることで、その法的な問題を解決できます。
質問 私は非フリーライブラリを使用するフリーソフトウェアを書いています も参照してください。
ライブラリBが非GPLAPIを実装しているという事実は違いを生むかもしれませんが、（最後のFAQ上記で引用）を参照）はFSFによって異なるとは見なされていないようです。
クローズドソースプログラムでライブラリBを使用することはできますが、この2つの組み合わせを配布することは許可されていません。プログラムが汎用（非GPL）APIで動作するように記述されており、ライブラリBがなくても正常に動作する場合は、ライブラリなしでプログラムを正常に配布できます。ユーザーは、ライブラリBを個別にダウンロードして、と組み合わせて使用することもできます。あなたの申請。
大きな問題は、ライブラリBの派生物と見なされることなく、ソースコードまたはドキュメントでライブラリBを積極的に参照できるかどうかです。これは法的な質問であり、回答する専門知識がありません。そのためには弁護士に相談する必要があります。
ライブラリBについて言及しなければ、少なくともGPLライセンスのAPIの実装に気付いていなかった可能性のある防御策はありますが、それが法廷でどこまで到達するかを教えてくれるのは弁護士だけです。