問題タブ [lgpl]

クローズドソースでプロジェクトXを使用しているとします。LGPLであるコンポーネントYを参照/リンクし、コンポーネントYに変更を加えます

1）変更されたコンポーネントYのソースを含むProjectXバイナリをリリースします

また

2）コンポーネントYの変更を（元の作成者に）上流に戻し、コンポーネントYのソースなしでプロジェクトXバイナリをリリースします。

これらのシナリオのいずれかがLGPLに準拠していますか？

プラグインをサポートするアプリケーションに取り組んでいます。アプリケーションに LGPL を適用できるのか、それとも LGPL はライブラリのみに適用できるのか疑問に思っています。

要点は、アプリケーションをおおまかに GPL にしたいということですが、これはアプリケーションがロードするプラグインやスクリプトには適用されないということです。ただし、GPL はプラグインを派生作品と見なすため、純粋な GPL はこの場合には適していません。

現在、私は MPL について考えていますが、それはライセンスがカリフォルニア州の管轄下にあることを明確に述べており、ヨーロッパ人にとってはこれは実際には受け入れられません.

脆弱なコピーを残したい場合、アプリケーションのライセンスに関してより賢明な選択は何でしょうか。LGPL の代わりに適用すべき GPL の標準的な例外はありますか? また、LGPL はアプリケーションにどのように適用されますか? ライセンスはライブラリについて述べていますが、それをアプリケーションに適用したい場合、私にとってはやや混乱します。

MySQL ++はLGPLを通じてライセンスされています。つまり、ソースコードがGPLでないことを心配することなく、動的にリンクされた実行可能ファイルをリリースできます。ただし、MySQL ++は、GPLされたlibmysqlclient {_r}。{a、so}（http://tangentsoft.net/mysql++/#linkerrors）に対してリンクします。
ご覧のとおり、MySQL ++は、技術的には、GPLされたlibmysqlclient {_r}。{a、so}に対する単なる「ラッパー」です（非常によく実装されたラッパーですが、誤解しないでください）。 libmysqlclient {_r}。{a、so}？

この場合、MySQL ++がLGPLされる目的は無意味です。これは、MySQL ++に対して動的にリンクする実行可能ファイルは、libmysqlclient {_r}。{a、so}に対してもリンクする必要があるためです。私はどこが間違っていますか？

lgplライセンスのJavaScriptライブラリを使用している場合、それを使用しているクローズドソースのWebアプリをリリースする必要がありますか？

ライブラリのソースを変更しない限り、変更する必要はないように感じます。

商用のクローズドソース環境でlgpljavascriptwysiwygを使用したいと思います。

クローズドソースのWebアプリは配布されることはなく（配布の定義がWebサイトにどのように適用されるかによって異なります）、エンドユーザーはそれにアクセスすることしかできません。

gplとlgplは、Webに適用されるため、非常に混乱します。

また、「配布」とは何であるかについても混乱しています。

プロジェクトで libavcodec を使用することを検討しています。LGPL ライセンスに基づいていることは知っていますが、ライセンスについてはよくわかりません。

私のプロジェクトはオープン ソース プロジェクトではなく、libavcodec のコードを変更していません。libavcodec を使用するにはリンク メソッドしか使用できません。

これらの条件で、私は質問したいと思います: 私のプロジェクトで libavcodec を使用できますか?

ありがとう。

Qt/Mfc Migration Frameworkを使用して、一部の UI コードを MFC から Qt に変換し始めています。Qt 移行コードを別のライブラリに絶対に保持する必要があるのか​​ 、それとも私のプロジェクトに含めることができるのか疑問に思っています。そのためには、少し変更する必要があります (たとえば、#include "stdafx.h" を追加し、他のインクルード パスを変更します)。移行フレームワークにも使用される Qt LGPL 例外は次のとおりです。

Nokia Qt LGPL 例外バージョン 1.0

GNU Lesser General Public License バージョン 2.1 の特別な例外として、「ライブラリを使用する作品」のオブジェクト コード形式は、ライブラリの一部であるヘッダー ファイルからの素材を組み込むことができます。(i) ライブラリの合計サイズの 5% を超えないこと。(ii) 数値パラメーター、データ構造レイアウト、アクセサー、マクロ、インライン関数、およびテンプレートに限定されます。

ライセンスをトリガーしますか、それともまだ緑色ですか?

LGPL は、私のコードに依存するプログラムがそれを認めることを保証しますか? Zed のブログで、その趣旨の何かを読みました。(リンク、「二度と無視されたくない」セクション)。本当ですか？

プラグインをサポートするプログラムを作成していて、LGPLでライセンスされているアセンブリ（.net）への参照を持つプラグインを1つ作成したとしましょう。プロジェクト全体をオープンソースにし、LGPLで作成する必要がありますか？

iPhoneアプリケーションでLGPLライセンスの下でアイコンを使用したいのですが。アプリの要件に合わせて、これらのアイコン（サイズ、色、またはより高度な編集）を変更したいと思います。

変更されたバージョンがライセンスを継承することを理解しています。ただし、アプリをiPhoneに埋め込むと、画像やライセンスファイルを共有するのが難しくなります。

私の質問は：

• 著者の功績を認めますか？はいの場合どこ？「概要」画面？

• GNU LGPLテキストのコピーをどこに置きますか？

• 変更したバージョンをコミュニティで利用できるようにするにはどうすればよいですか（LGPLライセンスの下で）？ウィキメディアコモンズに公開しても大丈夫ですか？

前もって感謝します。

商用アプリケーションの 1 つで Snowball ステミング ソリューションを使用することを計画しています。Snow ball ステマー用の Java コードを生成するユーティリティもあります。どうやらデフォルトのコードは最適化されておらず、MG4J ( http://mg4j.dsi.unimi.it/ ) が大幅に改善されていることがわかり、それをアプリケーションで使用したいと考えています。

1. 商用アプリケーションで LGPL ライブラリを使用できますか
2. また、アプリケーションにjar全体を含める余裕がないため、ライブラリのステマー部分のみが必要だったので、jarファイルのストライプダウンバージョンを作成する必要があります。それをしてもいいですか。
3. また、コードにもいくつかの変更を加えるつもりです。

その意味について誰かが導くことができますか。