タグ付けされた質問 「lgpl」

会社がBusyBoxを使用し、Gpl + Lgpl + Mplパッケージを使用しているのを見ました。そして、彼らはそこで実行されている独自のアプリケーションを持っています。彼らのアプリケーションはクローズドソースパッケージです。 デバイスを購入しますが、そのソースはクローズドです。GPLとLGPL + MPLの混合がクローズドソースになるのはなぜですか？ ルールだと思った？または私が間違っているか、この次の情報が間違っていますか？： GPL：アプリケーションで使用する場合は、GPLの下でアプリケーションをリリースする必要があります。Linux CDを販売するように販売できないというわけではありませんが、ソースコードも無料でリリースする必要があります。それはあなたのために働くかもしれませんが、おそらくそうではありません。 LGPL：アプリケーションで使用する場合、クローズドソースのプロプライエタリライセンスアプリケーションを使用できます。ただし、LGPLライブラリを変更する場合は、アプリケーションがクローズドソースのままであっても、LGPLで変更をリリースする必要があります。

11 licensing  gpl  lgpl  mpl 

Monoプロジェクトは、かつてLGPL化されたライブラリーを持っていました。実際mbundle、それを実行するとまだ言います LGPL Monoランタイムを静的にリンクすることには、動的にリンクすることよりも多くのライセンス制限があることに注意してください。参照http://www.mono-project.com/Licensingのライセンスの詳細については。 2016年3月の時点で、彼らはMITの下でそれらを再ライセンスしました。プロジェクトが何年も前のものであり、おそらく多くの外部の貢献者からの貢献があり、それらの貢献はLGPLによる貢献としてのみ提供された場合、どのようにしてライセンスを変更できましたか？彼らは過去12年間、すべての寄稿者から許可を得なければならなかったのではないでしょうか。たぶんそれらの寄稿者は何らかの合意に署名しなければならなかったのでしょうか？

10 licensing  mit-license  lgpl 

私はLGPLライセンスを読んでいて、以前は知らなかった要件を見つけました。 セクション4（Combined Works）は次のように述べています。 次のことも行う場合は、結合作業を伝えることができます。 a）ライブラリがその中で使用されていること、およびライブラリとその使用がこのライセンスの対象であることを、結合作品の各コピーに目立つように通知します。 b）結合された著作物に、GNU GPLとこのライセンスドキュメントのコピーを添付します。 c）... LGPLの下でライセンスされたライブラリにリンクするときに、なぜGPLも伝える必要があるのですか？ディストリビューションに両方のライセンスを含めると、どちらを適用するかについてユーザーが混乱するのではないかと心配しています。私はこれを正しく解釈していますか？もしそうなら、この要件の背後にある理由は何ですか？

10 licensing  open-source  gpl  lgpl 

SOに関するこの質問から、私はそれを読みました： 独自のソースコード+ LGPLソースコード 静的にリンク： どちらもLGPLとしてリリースする必要があります。 または、ユーザーがアプリケーションを別のバージョンのLGPLソースコードに再リンクできるようにするすべてを提供します。この場合、他の要件は動的にリンクされた場合と同じです。 したがって、オブジェクトファイルを提供するだけで、LGPLライブラリを独自のコードアプリケーションに静的にリンクするという点でLGPLを満たすのに十分であるように思えます。実行可能ファイルは静的にリンクされていますが、オブジェクトファイルを提供すると、エンドユーザーはアプリケーションを再コンパイルして、異なるバージョンのライブラリにリンクできます。 これは正しいですか、正しくない場合は、なぜですか？

9 lgpl  static-linking 

LGPL（ここでは説明を簡単にするためにバージョン3を想定しています）はGPLの制限の少ないバージョンです。同様に、AGPLはGPLの制限の多いバージョンですが、LGPLコードを使用できます。追加を行う（または行わない）、GPLまたはAGPLとして再ライセンスする。GPLコードを変更してAGPLとして再ライセンスできますか？

9 licensing  gpl  lgpl 

仕事では、多くの外部依存関係があるJavaアプリケーション（私たちが作成した）のソフトウェアバンドルをデプロイしています。そのほとんどはLGPLであり、BSDライセンスのサードパーティライブラリはJARアーカイブとして配布されています。 現在、Mavenアセンブリプラグインによって作成された単一のJava Fat jarアーカイブとして配布されるソフトウェアのテストクライアントをデプロイしています。 すべての依存関係を抽出する それらを単一のjar-archiveとして再バンドルします すべてのクラスファイルが抽出され、独自のアプリケーションで単一のJARファイルにバンドルされます。同じ名前を持っているため、一部のファイル、主にLICENSE.txtファイルが上書きされることにも気付きました。 これが正しく、LGPLライセンスに準拠しているかどうか疑問に思っています。ソフトウェアを配布するより良い方法は何でしょうか？この特定のパッケージはどのように最適に編成されますか？ ソースコードをソースファイルに直接組み込んだり、バイナリファイルを変更したりすることはありませんでした。ライブラリのソースコードは製品全体に付属しています。（これは、内部で使用されるソフトウェアであり、顧客やその他には展開されていませんが、問題ではないと思います。） PS：Stack Overflowで同じ質問をしたところ、ここで質問するよう提案されました。

8 java  deployment  lgpl