私が個人的に行っていることは、私が使用するライブラリが再配布を明示的に禁止していないことを確認することです。もしそうなら、あなたは運が悪いです。ただし、BSD も LGPL もそうではないので、問題ないはずです。まともなオープンソース ライセンスが思い浮かびません。
それらを再パッケージ化して配布することによってライセンスの条件に違反していないことに満足したら、他の面でそれらを尊重することを確認する必要があります. 99.99% のオープン ソース ライセンスでは、次の手順で十分であることがわかりました。
license.txt
JAR ファイルのルートにファイルを作成します (これを に入れる人もいますMETA-INF
が、私はこれに関する規則や規則を知らず、好みの問題だと思います)。
- インポートするすべての外部ライブラリと、それらが で配布されるライセンスをリストします
license.txt
。
- に適用されるすべてのライセンスの完全なテキストを記述します
license.txt
。
- 理想的には、各ライブラリの Web サイト、ダウンロード ページ、ライセンス ページへのリンクがあればリンクします。
これにより、GPL を除いて、主流のライセンスに違反しないようにする必要があります。私は弁護士でもなく、GPL の専門家でもありません。GPL を尊重する方法についてのアドバイスは、完全に間違っている可能性があるため、誤解を招くようなことはしたくありません。
あなたができることは他にもいくつかありますが、それらはプロとしての礼儀の問題です。
- ユーザー向けアプリケーション (Web サービス、UI アプリケーションなど) を作成している場合は、このセクションで使用しているライブラリにリンクしてください
About
。
- ライブラリの管理者に、あなたがそれを使用してパッケージ化していることを知らせてください。一部の作成者は、ツールを使用して人気のあるソフトウェアのリストを管理することを好みます。
大変な作業のように聞こえるかもしれませんが、実際のライブラリを作成して保守するよりもはるかに簡単です。
編集:アプリケーションではなく、ライブラリに取り組んでいることに気付きました。その場合、私の答えは実際には当てはまりません。ライブラリの JAR に依存関係をパッケージ化するのは非常に貧弱な形式です。どちらかといえば、サードパーティの開発者がライブラリを既存のビルド ツールや依存関係管理システム (maven、ant / ivy...) と統合するのがかなり難しくなります。
物事をシンプルに保ちたい場合は、すべての依存関係の JAR を/lib
配布ファイルのフォルダーに含めるだけです。
繰り返しますが、ライブラリの JAR ファイルではなく、ライブラリの JAR ファイルに依存関係をパッケージ化することで、大多数の開発者を遠ざけることができると思います。問題が解決されない場合は、バグ レポートを提出し、代替手段を探すことは間違いありません。