4

この質問がされている場合は、お詫び申し上げます。

小さな python ライブラリのバグを修正しました。この特定のライブラリは GPL の下でライセンスされていますが、その開発は終了して放棄されたようです (パッチを添付したトラッカーでの活動は非常に少ない)。

このライブラリを使用する Python アプリケーションを開発しています。ライブラリのパッチを適用したバージョンと一緒に配布する適切な方法は何ですか?

4

3 に答える 3

5

ライブラリが放棄されているかどうかにかかわらず、それを使用する場合は、コード (パッチを適用したライブラリとアプリケーションの両方) も GPL の下で配布する必要があります。

于 2009-08-12T13:26:09.210 に答える
1

パッチが適用されたライブラリは確かにGPLであり、おそらくアプリケーションもGPLです。それでよければ、問題はありません。アプリケーションで別のライセンスを使用したい場合は、「派生作業」がGPLの意味をどのように理解したいかによって異なります。

あなたのアプリケーションがライブラリにあまり依存しておらず(あなたはそれが小さなライブラリだと言った)、あなたが同じように使うことができる(またはアプリケーションのユーザーが使うことができる)同じことをしている他の(非GPL)ライブラリがある場合、それから...まあ... GPLの下でアプリのライセンスを取得する必要はないかもしれません。これは主に、そのライブラリから実際に派生していないことが議論の余地があるためです。しかし、それは本当に緩い定義です。

ライブラリがLGPLの場合、希望する方法でアプリのライセンスを取得できますが、パッチが適用されたライブラリはLGPLの下にあります。また、ライブラリの元の作成者はLGPLではなくGPLを選択したため、ライブラリを使用するアプリもGPLの下にあることを望んでいたと考えられます。これは、前の段落の見解に対する通常の反論です。

もちろん、元のライブラリの作成者に、より寛容なライセンス(LGPLなど)を使用してライブラリにライセンスを付与するかどうかを尋ねることもできます。

于 2009-08-12T13:40:06.183 に答える
1

Anon からの返信に同意します。コード (パッチを適用したライブラリとアプリケーションの両方) も GPL の下で配布する必要があります。

ここで GPL v2.0 要件を検索できます。

https://enterprise.dejacode.com/license_library/Demo/gpl-2.0/#license-requirements

それが役に立てば幸い。

于 2014-05-01T23:13:40.323 に答える