LGPLライセンスライブラリを使用する場合、正確に何をする必要がありますか？
LGPLの基本的な要件はLGPLライセンスライブラリと独自の製品を分離する十分です。これにより、ユーザーはソフトウェアに同梱されているライブラリではなく、独自のバージョンのライブラリを提供できます（たとえば、バグが修正されています）。これを行うには、2つのオプションがあります。
- lGPLコードを共有ライブラリーとして使用します（ユーザーがライブラリーのバイナリーを出荷するライブラリーにコピーするだけです）、または
- プロジェクト全体のソースコードを提供します（ユーザーがライブラリのソースをコピーしてすべてを再コンパイルできるようにするため）。
ただし、必須ではありますが、単に分離するだけでは不十分です。ライブラリをバージョンで置き換えるための文書化された方法をユーザーに提供する必要があります（つまり、ファームウェアをアップロードする方法、またはPython LGPL C++ライブラリのラッパー）を再コンパイルする方法）。
2番目の注目すべき節は属性の要件です。これは 役立つはず は、ライブラリの元の開発者の名前を宣伝するためのものであり、すばらしいソフトウェアは他の誰かによって開発された可能性があることを示しています。 「About」ウィンドウの関連セクションまたはREADMEファイル（ライセンスがApacheの場合、これはNOTICEファイルになります）に、LGPL作業の名前をリストする必要があります使いました。
私は弁護士ではありません。これは法律上の助言ではありません。私も配管工ではないことに注意してください。これは衛生上のアドバイスではありません。
LGPLライブラリを静的にリンクする場合は、ライブラリのソースと、アプリケーションのソースコードまたはオブジェクトコードのいずれかを提供する必要があります。
LGPLライブラリーを動的にリンクしている場合は、ライブラリーなしでアプリケーションを単独で配布し、どこからダウンロードするか、どのように組み込むかをユーザーに伝えて使用することができます。または、ライブラリバイナリとそのソースのコピーをアプリケーションに含めることができます。
これはそれをかなりよく説明しています： http://answers.google.com/answers/threadview/id/439136.html （OPにリンクされた質問の回答からとったものです）
IANAS
IANALですが、私の理解では、LGPLのポイントは、GPLやAGPLのように、コードに応じてコードに「感染」しないということです。したがって、LGPLコードを依存関係として持つことができ、何もする必要はありません。
そうは言っても、LGPLコードwithをアプリケーションで変更/変更/配布する場合は、そのコードを公開する必要があります。