オープンソース ライブラリを使用する商用アプリケーションの構築を開始しています。さまざまなドキュメントや投稿を調べましたが、まだ問題が発生しています。私が理解していることから、オープンソースの部分を「分離」する必要があります。これを行う 1 つの方法は、「バニラ」リンクを介してオープン ソースと通信するクラスを提供することです。
提案された解決策は、オープン ソース (コマンド ライン ユーティリティ) を変更して、ある種の API を提供することです。次に、API を使用してオープンソース プログラムと通信するラッパー プログラムまたはプロキシ プログラムを開発します。変更したソースとラッパーをオープン ソースとしてリリースしますが、ソースの残りの部分はクローズしたままにします。オープンソースの部分はコードと共に提供され、静的または動的にリンクされたライブラリとして実行されることに注意してください。
これは GPL の下で機能しますか?
いいえ、それが GPL であり、それにリンクすると、コードも GPL になります。LGPL の場合は事情が異なります (LGPL ライセンスのライブラリにリンクされた商用アプリを構築できます) が、ここではそうではないようです。
リモートプロシージャコール（COM）または標準IOについて話す人を信じないでください。何かがあるとすれば、標準のIOは、出力をgrepにパイプし、それを他のアプリケーションにパイプするなどのレガシーな状況に由来します。
代わりに、次のように考えて ください。アプリケーションはGPLコンポーネントから派生したものですか？ かなり賢い一般の人に、アプリケーションがオープンソースライブラリの派生物ではない理由を説明してください。stdioラッパーとCOMインターフェースについては、顔が真っ青になるまで説明できますが、弁護士、裁判官、顧客、またはそれを購入しない人は誰でも説明できます。代わりに、そのGPLライブラリを削除しても、アプリケーションの動作が大幅に変更されないことを示す必要があります。それができない場合は、申し訳ありませんが、あなたは薄い氷の上にいます。
GPLには、人と同じくらい多くの異なる解釈があることに注意してください。
私は弁護士ではありませんが、この件について弁護士と話をしました。これは法律上の助言ではありません。
一部の弁護士は、GPLに対して動的にリンクすることは問題なく、派生した作業を構成しないと信じています。RMSや彼の弁護士などの他の人は、動的リンクはOKではなく、派生した作業を構成すると信じています。ほとんどの人は、静的リンクは派生した作業であると信じています。
この主題については多くの議論があり、この点で派生した作品であるものとそうでないものを定義する決定的な訴訟法はありません。
たとえば、この記事を参照してください