ライブラリをプロセス外に移動してGPL違反を回避する
GPLでライセンスされているライブラリがあると仮定します。クローズドソースのプロジェクトで使いたいです。私は以下を行います：
- ソケットをリッスンし、メッセージを解析してGPLライブラリを呼び出す、そのGPLライブラリの周りに小さなラッパーアプリケーションを作成します。その後、結果を返します。
- ソースをリリースする（GPLに準拠するため）
- メインアプリケーションでこのラッパーのクライアントを作成し、ソースを解放しません。
これは静的/動的リンクと比較して大きなオーバーヘッドを追加することを知っていますが、理論的な方法に興味があります。
法的に、大丈夫だと思います（ただし、私は弁護士ではありません-弁護士に相談して法的助言を求めてください）。
口頭で、それはかなり非難できます。 GPLが気に入らない場合、「適切な」解決策はGPLライブラリを使用しないことです。
編集：明確にするために、動的リンクが許可されているかどうかに関するGPLの法的立場が何であれ、LGPLはライブラリの場合に動的リンクを許可することを目的として特別に作成されました。したがって、LGPLよりもGPLを選択することで、ライブラリの作成者が動的リンクを許可しないように明示的にしていることは明らかです。 technicalを使用することは、作者のlegal制限を回避することを意味します私の意見では、彼のコードの明確な意図は非難できるものです。
記録のために、私は個人的にはGPLのファンではありません（MITまたはBSDなどのより寛容なライセンスを好みます）。しかし、私は他の仕事を尊重することの大ファンです開発者、そして彼らがあなたのライブラリをクローズドソースのソフトウェアとリンクさせたくないのなら、それは特権的です。
GPLでカバーされているソフトウェアを独自のシステムに組み込みたいのですが、これは可能ですか？ を参照してください。
問題は、ラッパーアプリケーションを独自に使用することですか？ GPLであるプログラムのコマンドラインバージョンを作成した場合、別のライセンスでGUIをリリースできます。たとえば、クローズされたソースであるgccのIDEを作成するか、diffに基づく視覚的なdiffツールを使用できます。
ただし、ラップアップしたライブラリがプログラムで使用される以外に使用されず、プログラムがこのライブラリなしでは使用できない場合、それは派生物であり、GPLでリリースする必要があります。
IANALでも大丈夫だと思います。GPL3の関連セクションはセクション5の最後にあります。
対象となる作品と他の独立した作品とのコンパイル。これらは、対象となる作品の本質的な拡張ではなく、ストレージまたはディストリビューションのボリューム内またはボリューム上で、より大きなプログラムを形成するなど、組み合わせられません。媒体は、編集物とその結果の著作権が、個人の作品が許可する範囲を超えて編集物のユーザーのアクセスまたは法的権利を制限するために使用されない場合、「集合体」と呼ばれます。対象作品を集合体に含めても、このライセンスは集合体の他の部分には適用されません。
これはおそらくあなたの「クライアント」が何をするかに正確に依存するでしょう、mouvicielの答えはおそらくそれを安全に行う方法についての良いガイダンスです
アプリがライブラリの拡張ではなくライブラリの拡張であると思われる場合は、おそらく正しいでしょう（これを知るための適切な場所にいる必要があります）。その場合は、作者に連絡して、別のライセンス
this は、適切に行われたと仮定すると、これがGPLによって明示的に許可されているという私の立場を裏付けるように思われます。
IMO、合法的には大丈夫です。 （IANAL）問題の道徳的な側面を改善するために、「FooBarを合法的にMyClosedAppで利用可能にするFooBarラッパー」とは呼ばず、サーバーと呼びます。 「ネット上でFooBarを実行できる」素敵な小さなオープンソースプログラムにします。 SourceForgeに置くか、Webサイトをプロジェクトページと説明などで専用します。次に、「MyClosedApp」に「FooBarサーバー」を使用させる。
私が理解している限り、GPLライブラリがなくてもソフトウェアを動作させることができる限り、ソフトウェアをクローズドソースのままにすることができます。 GPLライブラリをプラグインとして見ないでください。プラグインがないとソフトウェアが役に立たなくなります。
- オープンソースの代替案を見つけようとしてください。ない場合は、GPLの代替案を探してください。
- GPLv3とAffero句 であるかどうかを確認します。そうである場合、何もする必要はありません。
- それがGPLv2であれば、あなたが提案したとおりに行うことができます。
多少物議を醸すオプションもあります。ほとんどの議会では、動的リンクは「派生した作業」の境界となるはずです。この背後にあるロジックは、動的にリンクしている間、プログラムにヘッダーファイルを含めるだけです。多くの法律では、ヘッダーファイルはAPI定義と見なされ、著作権で保護されていないことが明示的に除外されています。一方、動的リンクでは、GPLライブラリとの実際のリンクはエンドユーザーのシステムで行われます。しかし、私が言ったように、それについて多くの論争があるので、ストールマンはこれに対して強くFUDしています。
アダム・ブラウンがGPLライブラリを使用し、「サーバー」として機能するプログラムを作成することは、それに関連するすべてのものにすべてのソースコードをリリースした場合でも合法でしょうか。彼はクライアント側で書いたのですか？私はそれがそうではないと考える根拠をまったく見ていません。
チャールズドーバーがアダムブラウンの「サーバー」を見つけ、それと通信するためのクローズドソースプログラムを作成することを決定した場合、GPLは彼の行動を何らかの方法で制限しますか？彼がGPLされたソフトウェアを使用する唯一の方法は、彼がAdam Brownから受け取ったバイナリとしてのものになるためです。アダムのバイナリを配布した場合、ソースへのリンクも含める必要がありますが、GPL内の他の何もチャールズのコードに影響を与えることはありません。
GPLライセンスのサーバーを作成し、独自のクローズドソースの目的でサーバーを使用する1人について、サーバーを作成する際に真面目な努力をしたとしても、法的な問題はないと思います。提供されたGPLコードを同じ方法で使用したい他の人に役立ちます。特に、公開されているインターフェースのドキュメントは、有能なプログラマーがオリジナルと同じようにクライアントプログラムに受け入れられるサーバーのコードを記述し、クライアントプログラムを使用するのに十分なものでなければなりません。著者のアプリケーションと同じ方法でサーバー。