ライブラリをプロセス外に移動してGPL違反を回避する

GPLの下でライセンスされているライブラリがあると仮定します。使用したいのはクローズドソースプロジェクトです。私は次のことをします：

1. ソケットをリッスンするGPLライブラリの周りに小さなラッパーアプリケーションを作成し、メッセージを解析してGPLライブラリを呼び出します。その後、結果を返します。
2. ソースをリリース（GPLに準拠）
3. メインアプリケーションでこのラッパーのクライアントを作成し、ソースをリリースしないでください。

これにより、静的/動的リンクに比べて大きなオーバーヘッドが追加されることは知っていますが、理論的な方法に興味があります。

法的に、私はそれがOKだと言うでしょう（しかし、私は弁護士ではありません-法律相談のために弁護士に相談してください）。

道徳的に、それはかなり非難です。GPLが気に入らない場合、「適切な」解決策はGPLライブラリを使用しないことです。

編集：ダイナミックリンクが許可されるかどうかに関するGPLの法的地位を明確にするために、LGPLは、ライブラリの場合にダイナミックリンクを許可することを目的として作成されました。したがって、LGPLよりもGPLを選択することにより、ライブラリの作成者が動的リンクを許可しないように明示的に行っていたことは明らかです。私の意見では、著者のコードに対する明示的な意図を表現する法的制限を回避するために技術的な手段を使用することは、非難できることです。

記録のために、私は個人的にGPLのファンではありません（MITやBSDなどのより寛容なライセンスを好みます）。しかし、私は他の開発者の仕事を尊重することの大ファンであり、彼らがあなたのライブラリをクローズドソースのソフトウェアとリンクさせたくないのであれば、それは特権です。

IANALでも大丈夫だと思います。GPL3の関連セクションはセクション5の最後にあります。

他の独立した作品とのカバーされた作品の編集。それらは本質的にはカバーされた作品の拡張ではなく、ストレージまたはディストリビューションのボリューム内またはボリューム上でより大きなプログラムを形成するために組み合わされません編集物とその結果の著作権が、個々の作品が許可する範囲を超えて編集物のユーザーのアクセスまたは法的権利を制限するために使用されない場合、媒体は「集合」と呼ばれます。対象作品を集合体に含めることにより、このライセンスが集合体の他の部分に適用されることはありません。

これはおそらく、あなたの「クライアント」が何をするかに正確に依存するでしょう。

あなたのアプリがそれと集約されたものではなくライブラリの拡張だと思うなら、おそらく正しいでしょう（あなたはこれを知るのに良い場所にいるべきです）その場合、あなたの最善の策は著者に連絡して取得しようとすることです別のライセンス

これは、適切に行われたと仮定して、これがGPLによって明示的に許可されているという私の見解を裏付けるように思われます。

独自のシステムにGPLでカバーされたソフトウェアを組み込みたいを参照してください。これはできますか？

問題は、ラッパーアプリケーションはそれ自体で使用できるのかということです。GPLであるプログラムのコマンドラインバージョンを作成した場合は、別のライセンスでGUIをリリースできます。たとえば、クローズドソースであるgccのIDEや、diffに基づく視覚的なdiffツールを作成できます。

ただし、ライブラリをラップしてプログラムで使用する以外の用途がなく、プログラムがこのライブラリなしでは使用できない場合、派生した作品であり、GPLの下でリリースする必要があります。

IMO、合法的には大丈夫です。（IANAL）問題の道徳面を改善するために、「FooBarをMyClosedAppで合法的に利用できるようにするFooBarラッパー」とは呼ばず、サーバーと呼びます。「ネット上でFooBarを実行できる」素敵な小さなオープンソースプログラムにします。SourceForgeに置くか、プロジェクトページと手順などを備えたWebサイトを専用にします。次に、「MyClosedApp」が「FooBarサーバー」を使用するようにします。

私が理解している限り、GPLライブラリなしで動作できる限り、ソフトウェアをクローズドソースのままにしておくことができます。GPLライブラリは、プラグインがなくてもソフトウェアが役に立たないプラグインと見なされます。

1. オープンソースの代替手段を見つけようとします。ない場合は、GPLのものを探します。
2. GPLv3がAffero句であるかどうかを確認します。そうでない場合は、何もする必要はありません。
3. GPLv2の場合は、提案どおりに行うことができます。

議論の余地のあるオプションもあります。ほとんどの議会では、動的リンクは「派生著作物」の境界となるはずです。この背後にあるロジックは、動的にリンクしている間は、ヘッダーファイルをプログラムに含めるだけです。多くの法律では、ヘッダーファイルはAPI定義と見なされ、著作権の対象から明示的に除外されています。一方、動的リンクでは、GPLライブラリとの実際のリンクはエンドユーザーのシステムで行われます。しかし、私が言ったように、それについて多くの論争があります、ストールマンはこれに対して強くFUDしています。

Adam BrownがGPLライブラリを使用し、「サーバー」として機能するプログラムを作成することは合法でしょうか。関連するすべてのソースコードをすべてリリースしましたが、彼がリリースした唯一のクライアントコードは非常に脆弱です。彼はクライアント側を書いたのですか？私はそれがそうではないと考える根拠は全くありません。

チャールズドーバーがアダムブラウンの「サーバー」を見つけ、それと通信するためのクローズドソースプログラムを作成することにした場合、GPLは彼の行動を何らかの形で制約しますか？彼がGPLのソフトウェアを使用するのは彼がAdam Brownから受け取ったバイナリとしてのみだからです。Adamのバイナリを配布した場合、ソースへのリンクも含める必要がありますが、GPLの他のコードはCharlesのコードに影響しません。

GPLライセンスのサーバーを作成し、そのサーバーを自分のクローズドソースの目的に使用する1人については、サーバーを作成する際に彼がそれを行うための真正な努力をしたとしても法的問題はないと思います。提供されたGPLコードを同じ方法で使用したい人にとっては便利です。特に、公開されているインターフェイスのドキュメントは、有能なプログラマーが、クライアントプログラムで受け入れられるサーバーのコードを、オリジナルと同じように記述し、クライアントプログラムを使用して、作成者のアプリケーションと同じ方法でサーバー。