クローズドソースアプリケーションでLGPL / GPLソフトウェアを動的に呼び出すことはできますか？
GNU Lesser General Public License、version 2.1 の下にあるツール（ ffmpeg ）を使用したいのですが、 GNU General Public License（GPL）バージョン2 一部のコンポーネント用。
そうするために、私はそれを私のソフトウェアでそれだけと呼びます：
System.Diagnostics.Process p = new System.Diagnostics.Process();
p.StartInfo = new System.Diagnostics.ProcessStartInfo("lgplSoftware.exe", myParams);
p.Start();
私はそれを変更しません、私はWindows用のソフトウェアのビルドバージョンを使用するだけです。
Wikipedia さんのコメント：
GPLに関連する重要な論争は、非GPLソフトウェアをGPLライブラリに動的にリンクできるかどうかです。 GPLは、GPLに基づくすべての派生コードがGPLに基づく必要があることを明確に要求しています。静的リンクは派生物を生成することが理解されていますが、GPLコードに動的にリンクする実行可能ファイルを派生物と見なすべきかどうかは明確ではありません（弱いコピーレフトを参照）。この問題に関して、フリー/オープンソースソフトウェアコミュニティが分かれています。 FSFは、実行可能ファイルとGPLコードが「相互に関数呼び出しを行い、データ構造を共有する」場合、そのような実行可能ファイルは確かに派生物であると主張し、一部（たとえば、Jerry Epplin）は同意し、一部（たとえば、Linus Torvalds）は、動的リンクは派生作品を作成することができますが、状況に同意しません。
私はこのすべての法的事項に本当に混乱しています。私も自分のプロジェクトをLGPLにしてソースをリリースしたはずですが、これは私次第ではありません。
だから問題は、私が今行っているように使用できますか、それとも弁護士の軍隊によって処刑されますか？
リンク は、コンピュータプログラミングで特定の意味を持ちます。 GPLまたはLGPLのコードをまったくリンクせず、GPLまたはLGPLのバイナリのみを生成します。GPLおよびLGPLはこれを許可します。ユーザーはそのバイナリを作成者の意図する目的で自由に使用でき、ソースを自由にダウンロードしてコンパイルできるため、ユーザーの自由はすべて維持され、GPLまたはLGPLに違反することはありません。 （これが GPL FAQ が「腕の長さでのコミュニケーション」によって話していることです。）これは、LGPLとGPLの精神に違反することさえありません。彼らはプロプライエタリなソフトウェアの存在を許容し、ある時点でプロプライエタリなプログラムが無料のプログラムを生み出すと想定し、逆もまた同様です。 （それ以外の場合は、WindowsでGPL対応のソフトウェアを実行できませんでした。）
GPLは、プロプライエタリなプログラムとGPLで保護されたプログラムが「効果的に単一のプログラムになるような方法で組み合わされていない」ことを要求しています。プログラムが完全にGPL化された実行可能ファイルに依存している場合、スタンドアロンバイナリであってもプログラムなしでは使用できないため、不安定な状況に置かれる可能性があります。 （そして、確かにそれを見つけるためにあなたの弁護士に相談する時がきました。）
また、これについて具体的に尋ねたわけではありませんが、GPLまたはLGPLのソフトウェアをソフトウェアと一緒に配布すると、ライセンスのコピーをインストーラーに含め、ソースも配布する必要があることを覚えておいてください。コード。たとえば、アプリケーションをインストーラーにパッケージ化し、GPLまたはLGPLの実行可能ファイルのコピーをインストーラーに含める場合、LGPLまたはGPLのコードを配布し、ソースコードのコピーを利用可能にする必要があります。 （アプリの配布方法に応じて、オンライン、郵送、CDのいずれか）。上流プロジェクトへのリンクを含めるだけでは不十分です（少なくともGPLのバージョン2では）。正確な詳細については、GPLとLGPLを読んでください。
私が間違っている場合は訂正してください。しかし、あなたが説明している状況は次のようなものだと思います。
- GPLまたはLGPLプログラムがあり、個別の実行可能ファイルとして作成されており、変更は行われていません。
- GPLまたはLGPLプログラムの機能を必要とするクローズドソースアプリケーションを構築しています。
- プログラムでは、フレームワークまたはOS機能を使用して、別の個別の実行可能ファイルを実行します。
- プログラムでその実行可能ファイルの出力を使用しています。
その場合、あなたは実際にはGPLまたはLGPLライセンスのプログラムへのlinkingではありません。したがって、そのプログラムのライセンス条件に拘束されることはありません。これは実際には、このような実行可能ファイルのライセンスの問題を回避するための、複雑であるとしてもかなり一般的な方法です。
ただし、GPLおよびLGPLのspiritに違反しています。
一般に、それは私がGPLの真に厄介であると考える数少ないものの1つです。さらに悪いのは、それがどれほど伝染性であるかです。それでも、それを回避する方法があります。
最初に、データを送信するための独自のインターフェースを定義することから始めます。これは、アプリケーションと、作成する別のライブラリの間で使用されます。 GPLライセンスに該当するため、GPLコードの内容を再利用しないでください。ただし、similar構造を使用しても何も問題はありません。このインターフェースは独自に作成したものであるため、独自のライセンスに該当します。好きなように自由に使用できます。
次に、GPLコードの周りにラッパーライブラリを作成します。これにより、個人用インターフェイスも実装されます。このライブラリはGPLライセンスに該当するため、汚染されます。ただし、インターフェイスを外部に公開することになりますが、インターフェイスを汚染することはできません。それは派生したものではありません。 100％独自のコードであり、同じインターフェイスを使用して別のライブラリに接続できます。
このラッパーライブラリは、独自の適切なコードとGPLコードの間の保護バッファーとして機能します。 GPLコードを直接使用していないため、独自のコードがGPLになることはありません。このインターフェースは、別のソリューションによってGPLコードを変更するためのソリューションとしても機能します。
ライセンス制限を回避するのはトリックですが、インターフェースはあなたのものであり、あなたのものだけなので、GPLはそれによってブロックされます。この方法で使用すると、GPLコードと非GPLコードは2つの異なるプログラムになります。
それでも、ここで法的助言が必要になる場合があることに注意してください。 SOには弁護士はあまりいません。しかし、それはこのGPLライセンスを回避できるトリックです。
これはLGPLソフトウェアで実行できますが、GPLライセンスソフトウェアでは実行できません。
LGPL 2.1セクション6 組み合わせた作品について、クローズドソースプログラムでライブラリを使用する方法を説明しています。 LGPLライセンスプログラムを呼び出すのと同じように呼び出すことができ、動的にリンクすることもできます。
GPLにはそのような例外はありません。プログラムの一部としてGPLプログラム/ライブラリを使用する場合、プログラムの不可欠な部分として認識されるため、GPL互換ライセンスの下ですべてのライセンスを取得する必要があります。 このGPL-FAQエントリ を参照してください。
私は弁護士ではありません。これは法律上の助言にはなりません。それが私たちの背後にあるので、IMHOあなたがリンクしているコードがLGPLである場合、あなたは明確です。技術的にはGPLであれば問題です。
GPLとLGPLの違いは、LGPLコードに対するリンクは共有の必要性を引き起こさないことです。