GPLに独自のソフトウェアをGPLライブラリとリンクできるようにする抜け穴がありますか？

仮想のシナリオを調べてみましょう。

X社は、独自のライブラリ（B）と動的にリンクする独自のプログラム（A）を作成します。Y社は、GPLの下でライセンスされた置換ライブラリ（C）を使用するため、AとCの両方に動的にリンクし、Aが使用するAPI呼び出しをCが使用するAPI呼び出しに変換するラッパーライブラリ（D）を作成します。

DはCとともに使用することを目的としており、CのAPI呼び出しを使用するため、Cの派生物であるため、GPL *の条件の下で配布する必要があります。その結果、AとDを組み合わせた作品もGPLの条件の下で配布する必要があります。これは、Y社がAのソースコードを所有していないため不可能です。 、 問題はない。ただし、Y社の行動に関係なく、X社はBがなくてもAを配布することでGPLに違反しません。Dが存在するだけでは、AがCの派生作品（Dを介して） GPLも同様です。

さて、これは抜け穴がある：、Dの独自のバージョンを書いAとは別に、それを配布し、代わりにBのDを使用するようにエンドユーザーに伝えるからX社を止めるものは何もありませんA.を実行するとする場合それは、同社が可能であると思われますラッパーモジュールを使用して独自プログラムをGPLライブラリから隔離し、そのモジュールが個別に配布される限り、GPLに違反することなくGPLライブラリを使用する独自プログラムを設計する。

私の推論は正しいですか？これはGPLの本当の抜け穴ですか？

* DはAの派生物でもありますが、このシナリオの目的のために、X社はDの作成を明示的に許可し、GPLの下でライセンスを許可しています。

IANAL、しかしここにGPLの制限内で許可されるものについての私の意見があります：

• 結合された作品「A-B」を公共で配布する：罰金、任意の所有権のあるライセンスの下で行うことができます

• YによるCのラッパーライブラリDを作成します。これは、AをGPLの下に置く必要があることを意味しません。

• Yによって内部的に結合された製品「A-D-C」を使用します。また、GPLは、その組み合わせが一般に配布されない限り、オープンソースAを必要としません。

• 結合された作品「A-D-C」を公開する：これは、Aがオープンソースであり、GPLの下に置かれることを要求します（XまたはYがこの組み合わせを配布したかどうか、さらにYがやりたい場合もちろん、XからAの配布ライセンスが必要になります）

興味深い質問は、D＆CをGPLのオープンソースとして個別に配布し、A＆B（またはBなしのA）を独自のライセンスで配布し、エンドユーザーが自分でBをD＆Cに置き換えることはできますか？

ここで、Aをlibs D＆Cに依存させる「AB」の最終変更は、配布後にエンドユーザーによって行われます。したがって、最終的な変更はエンドユーザーのみが内部で行うと主張することができます。そして、これは確かにGPLに違反することなく可能であるようです-そして、あなたが得るものは、Aが専有ライセンスの下にある「AC＆D」とGPLの下にあるC＆Dの組み合わせです。

もちろん、弁護士や裁判官はそれについて異なる意見を持つかもしれません。最終的な回答を得るには、誰かがそれを試し、2番目の人が彼を訴えるまで待つ必要があると思います。

ほとんどのシステムでは、最初から「A」を設計せずにこのような星座を作成するのは難しいので、BまたはCのいずれかとシームレスに動作します。この場合、A Cから何らかの形で派生しました。

編集：これについてしばらく考えると、似たような状況が私の頭に浮かんだ：クローズドソースアプリケーション用のGPLライセンスプラグインを書いて配布する。たとえば、Photoshopを見てみましょう。サードパーティベンダーのGPLプラグインが存在するという理由だけで、誰かがAdobeをオープンソースPhotoshopに強制しようと真剣に試みるとは思わない。ここでは、明確に定義されたインターフェースが存在するため、「ラッパーlib」さえ必要ありません。ただし、PhotoshopがGPLのサードパーティプラグインからその中心的な機能の一部を組み込むと、状況は変わりますか？そのような場合、どこで線を引くかを決めるのは本当に難しくなるかもしれません。その時点で、クローズドソース製品はGPL libに「基づいた」作品です。

EDIT2：デュアルライセンスライブラリが利用可能です。非商用利用にはGPLライセンス、商用利用にはプロプライエタリライセンスがありますたとえば、このような。そのため、「抜け穴」とは、そのようなライブラリに基づいて製品を開発し（商用バージョンを使用するため、GPLは製品に適用されません）、製品をライブラリなしでクローズドソースとして公開し、ユーザーは自分でGPL版を入手してインストールします。そのような場合、libのベンダーはライセンス違反であなたをうまく訴える可能性が高いと思います（もちろん、libの料金を支払わない場合）。手間をかける価値はありますか？おそらくない。特に私がリンクした例では、価格は製品を販売する頻度に依存せず、開発中にライブラリを使用している開発者の数だけに依存するため、ライブラリも購入する必要があります。

最後に、これらの法的リスクのため、クローズドソース製品内でオープンソースライブラリを使用する場合、可能であればGPLライブラリを回避し、この「抜け穴」を利用しようとはしません。リンク例外のあるLGPLまたはGPLの方がはるかに安全です。または、あらゆる種類の非ウイルスOSライセンスです。

実用的な例は、エンドユーザーが自分でインストールする必要があるLinux専用のグラフィックドライバーです。重要なのは、プロプライエタリドライバーの作成者にとって、エンドユーザーが結合された作業を配布する場合、ドライバーの作成者ではなく、エンドユーザー（おそらく履行できない）に法的義務が生じることです。

別の答えは、「プログラムはライブラリに依存しているため、依然として派生物である」と主張していますが、ライブラリが存在しないためにプログラムが実際に機能しない場合は、派生物ではありません。

しかし、最終的に、「抜け穴」に依存している場合は、そもそもあなたのアプローチが正しいアプローチではない可能性があることを考慮する必要があります。

リンクは、GPLによる派生物を定義します。この特定の状況は、LGPLが処理するように設計されたものです：ライブラリをGPLとしてリリースするが、適用されるライセンスの明示的な制限としてリンクを定義する場合、またはGPLコードに対してリンクするが独自のリンクを必要とする場合作業は非GPLライセンス自体の下でリリースされます。

エンドユーザーがリンクを行う場合（GPLライブラリにリンクする可能性のある非GPLソースから独自のコードを構築する場合）、エンドユーザーは最終製品が何であれGPLバージョンを効果的に作成していません。彼はプロジェクトの所有者ではないため、プロジェクトの非GPL部分のライセンスを変更することは許可されていません。これにより、通常、エンドユーザーによるいかなる形式の配布も禁止されますが、使用は禁止されません。

ただし、プロジェクトをソースからビルドする必要があり、その方法でのみ配布する場合は、リンクされたライブラリがどのライセンスに基づいているかは関係ありません。これは完全に非GPL開発者の手に委ねられます。つまり、独自のライセンス条件でこれを指定しない限り、libcに対してIBMコンパイラーでビルドされたglibc VSに対して、ソースのみのディストリビューションがgccでビルドされることをどのようにして知ることができますか？これはすぐに、公正使用や法的強制力のない法的条件の禁止にぶつかります（最近では、ファンタジーが法律に書かれていないことはほとんどありません）。

私は弁護士ではありませんが、プログラムが図書館に依存しているため、あなたが正しいとは言えない限り、それはまだ派生的な仕事です。sequalが派生的な仕事であるのと同じ方法。少なくとも、ライブラリで定義されているAPIに基づいています。