java - lgplライブラリが変更されたことをマークする方法

Question

コードでLGPLライブラリを使用しています。必要に応じて、ライブラリのコードを変更する必要があります。

変更されたコードが含まれていることをjarファイルにマークするにはどうすればよいですか？jarファイルにtxtファイルがありますか？その場合、txtファイルに何を書き込みますか？

jarの変更バージョンを配布することをライセンス契約に含めますが、私の質問はjar自体にマークを付けることです。

Answer 1

簡単な答え: 問題を回避する

バグを修正した場合、または機能を追加した場合は、パッチを介して元の作成者に提出してみませんか? 彼らがそれを受け入れた場合、ライブラリの次のバージョンには修正が含まれ、変更されたライブラリの出荷について心配する必要はありません! ライブラリへの変更/改善を共有することはライセンスの本質であり、提出された改善を待っている間、ライブラリのわずかに変更されたバージョンを一時的に使用することは、かなり一般的な方法です (ベンダーブランチに関するものを参照してください)。開発コミュニティの一員になるということは、ライブラリの「修正された」バージョンを出荷するのではなく、共通の利益のために元のライブラリの改善に積極的に貢献することを意味します。

長い答え: LGPL バージョン 3.0

LGPL 自体のバージョン 3.0 から:

2. 変更されたバージョンの伝達。

ライブラリのコピーを変更し、その変更において、ファシリティが、そのファシリティを使用するアプリケーションによって提供される関数またはデータを参照する場合 (ファシリティが呼び出されたときに渡される引数として以外)、ユーザーは、次のことができます。変更されたバージョンのコピーを伝える:

• a) このライセンスの下で、アプリケーションが機能またはデータを提供しない場合でも、機能が引き続き動作し、その目的の意味のある部分を実行することを保証するために誠意を持って努力することを条件として、または
• b) GNU GPL の下で、そのコピーに適用されるこのライセンスの追加の許可はありません。

残りのライセンス テキストに準拠している限り、必ずしも jar 自体をテキスト ファイルなどで「マーク」する必要はありません。コンパイル上の理由から、extraneon の提案に従い、わずかに異なる jar 名を使用できます。ベンダー ブランチなどを使用して、変更と元のライブラリの違いを維持できます。ここで、プロジェクトを「フォーク」して、独自の派生作品を作成しています。ここでの本質は、ソースに対する変更と改善を世界と共有することです。

長い答え: LGPL バージョン 2.1

LGPL 自体のバージョン 2.1 から:

2. ライブラリまたはその一部のコピーを変更して、ライブラリに基づいた作品を作成し、上記の第 1 項の条件に基づいてそのような変更または作品をコピーおよび配布することができます。 :

   • a) 修正された著作物は、それ自体がソフトウェア ライブラリでなければなりません。
   • b) 変更したファイルには、ファイルを変更したことと変更日を示す目立つ通知を表示する必要があります。
   • c) あなたは、このライセンスの条件に基づいて、すべての第三者に無償で作品全体をライセンスする必要があります。
   • d) 変更されたライブラリ内の機能が、その機能が呼び出されたときに渡される引数として以外に、その機能を使用するアプリケーション プログラムによって提供される関数またはデータのテーブルを参照する場合、ユーザーは誠実な努力をしなければなりません。アプリケーションがそのような関数またはテーブルを提供しない場合でも、機能は引き続き動作し、その目的の意味のある部分を実行することを保証します。(たとえば、平方根を計算するためのライブラリ内の関数には、アプリケーションとは無関係に完全に明確に定義された目的があります。したがって、サブセクション 2d では、この関数で使用されるアプリケーション提供の関数またはテーブルはオプションでなければなりません。アプリケーションがそれを提供しない場合でも、平方根関数は平方根を計算する必要があります)。

本質的には、あなたはこう言わなければなりません: ライブラリ 'foo' はライブラリ 'bar' の修正版です。目立つ通知は、通常、LGPL ライセンス コメント ブロック内の変更されたソース ファイルの先頭でも実行されます。繰り返しますが、ライブラリをフォークしています。

Answer 2

jar に別の名前を付けます。内部のクラスは同じ名前を持つため、それに依存するコードはそれを見つけるのに問題はありません (新しい jar がクラスパスにある場合)。

もちろん、マニフェスト ファイルに何らかの情報を追加し、おそらく jar 自体に変更ログ ファイルを追加して、変更を文書化することは常に賢明です。