特定のアプリケーションを考慮して設計されていないGPLとプラグインのインターフェース
私は法的助言を求めていません、または必要としませんが、興味深いけれども実験が私の頭に浮かびました。
次の状況を想像してみてください（具体的な例について本当に考えることはできず、実際の兆候が存在するかどうか確信がありません）：いくつかの寛容なライセンスまたはLGPLでライセンスされた無料の（リブレ）API Aがあります。非フリーアプリケーションBは、Hostプラグインの順にこのAPIを実装していますが、同じことを行う他のフリーソフトウェアもあります。さらに、api Aの下でプラグインとして機能するプラグインCがあります。これは、GPLの下にあるライブラリDにリンクしているため、CもGPLの下にあります。 Aを使用するプラグインは、dlopenのようなメカニズムを介してホストにロードされ、ホストプラグイン通信に複雑なデータ構造を使用します。 BもCも、Aが正しく機能するために必要なファイル（Aの構造定義を含むヘッダーや、Aの作成者が作成したAのヘルパー関数を含む動的ライブラリなど）を配布していませんが、そのようなものが存在する場合があります。
ここで、一部のユーザーが、アプリケーションAとプラグインCを自分のマシンにインストールし、API Aが正しく機能するために必要なものをインストールします。次に、彼はCをBにロードし、ソフトウェアではないBを使用して知的財産を作成します。
ある時点でGPL違反が発生しましたか？その場合、誰がGPLに違反しましたか？その理由は？
- Cの作者は、CをフリーでないホストBで使用できるようにすることにより、Dのライセンスに違反していますか？彼らはGPLを与えることができないため、これは可能性です（ http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF または http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface ）Dのライセンス条件によります。
- Bの作者は、CをBにロードできるようにすることにより、CおよびDのライセンスに違反していますか？ http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins がAがフリーモジュールと非フリーモジュール間の通信に使用するメカニズムを許可しないため、これは可能性があります。
- Aの作者。APIはGPLされたソフトウェアとnon-freeソフトウェアの間の通信に使用される可能性があるため（この場合は使用されました）。これは非常に馬鹿げているでしょう。
- ユーザーは、BをCにロードした瞬間にCの派生作品を作成したため、配布していないため不可能だと思います。しかし、状況の変化は、BがCをプラグインとしてロードするようにするBの構成ファイルをリリースすることを決定するのでしょうか？
- Aは「システムライブラリ」としてカウントされ、BとCの両方が直接ではなく、Aとのみ直接対話するため、誰もいない。正気の世界では、これは起こります...
Aの具体的な例としては、ある種のオーディオ（LADSPAなど）または画像処理APIがあります。しかし、私はそのようなインターフェースを見つけることができませんでした（つまり、フリーソフトウェアであり、汎用的で、商用ツールによっても実装されています）。現実の例も非常にわかりやすいかもしれません。
あなたの説明を考えると、私はAとBは質問には無関係であると思います。重要なのはCとDであり、問題はGPLが動的リンクを許可するかどうかに帰着します。誰かがGPLに違反している可能性がある場合、GPLに準拠していない場合はCです。
少し調べてみたところ、 Wikipedia GPL記事 に問題の良い要約があることがわかりました。答えは：異議ありです。この記事によると、3つの既存の立場：
動的リンクと静的リンクの両方に違反しています1 GPL。これはGPL（Free Software Foundation）の作成者の立場であり、この理由でLGPLを作成しました（違反なしに動的リンクを許可するため）。
静的リンクは違反していますが、GPLは動的リンクについて明確ではありません：GPLは派生物と見なされるものについて明確な指示を提供していないため、わかりにくいです作業。
リンクは関係ありません：GPLはソースコードレベルにのみ適用されます。私の意見では、ソフトウェアにリンクしてその機能にアクセスすることは、GUIのボタンを押して同じことを行うのと同じであるため、これは最も健全なオプションです。
FSFはGPLでの意図は両方を許可しないことであると述べているので、どちらかを行う方が賢明だと思います
言葉遣いが明確ではない場合でも、GPLにリンクする場合は、その意図を尊重し、GPLを自分の作品で使用
またはGPLソフトウェアから離れて
皮肉なことに、GPLは思っているほど自由/自由ではありません。その理由はわかっていますが、私の考えは、GPLを考えずにソフトウェアに適用しないことです。あなたが自由で寛容なライセンスを探しているなら、MITまたはBSDライセンスはあなたの意図をよりよく表すかもしれません。
1：「違反する」と言うとき、リンクの「消費者」がGPLに準拠していない場合に違反することを意味します。
GPLは誰にも違反していません。 GPL違反は、コードが「分散」されている場合にのみ発生します、ie、1つから転送されます別のパーティー。この例で変更された唯一のコードは、B、C、およびDでした。Cの作成者は、CがGPLに基づいて配布されるというDの要件を満たしました。 Bの作成者はCまたはDを配布せず、ユーザーがCおよびDと組み合わせてハイブリッドシステムを作成したという事実について責任を負いません。ユーザーがそのハイブリッドシステムを他のユーザーに配布しない限り、ユーザーはCまたはDのGPL条項に違反していません。
実際の例：
Motif APIとは、Motif（独自仕様）、OpenMotif（Open Group Public License）、LessTif（LGPL）のさまざまな実装です。ライブラリはドロップイン置換であり、OpenMotifを使用してコードを動的にコンパイルし、それをLessTifで実行したり、その逆を行うことができます。
独自のLinuxドライバー—ほとんどの場合、ライセンスの問題を回避するために、独自のコードをロードするシン（L）GPLラッパーがあります。ラッパーの一意の目的は、例 Nvidiaのバイナリドライバー のように分離である可能性があります。または、分離は、たとえば NDISwrapper の場合のように、単なる副作用である可能性があります。
これは、非gplコードがgplコードを使用できるようにする抜け穴だと思います。私が知っているvlcアクティブxコンポーネントの1つの例。 VLCはgplです。 VLC activexコンポーネントもGPLです。 activexコンポーネントを読み込むことができるすべてのWindowsアプリは、ヘッダーやコードを共有せずにvlc activexコンポーネントを読み込むことができます。当てはまる最後の箇条書きだと思います。