web-dev-qa-db-ja.com

LGPLでこれを行うことはできますか?

LGPLソフトウェアを使用して商用ソフトウェアを開発する予定です。

クラスでいくつかの関数を使用しているLGPLソフトウェアでは、完全に実装されていません。 LGPLコードを変更して、クラスの前にdllexportを追加し、関数の前に仮想キーワードを追加することで、クラスと実装されていない関数がdllの外部に表示されるようにします。

次に、これらの機能を独自のソフトウェアに実装する予定です。変更されたLGPLコードを配布する準備はできていますが、希望どおりに機能を実装する独自のソフトウェアは配布できません。

これはLGPLの利用規約に違反していますか?

16
user1229892

これは複雑な質問ですが、あなたが提案することは許可されていないと私は信じています。

ライブラリにフックを追加して、ライブラリを簡単にするライブラリをサブクラス化する、つまり、少なくとも、LGPLの精神)をバイパスすることを推奨します。

問題は、独自のコードで [〜#〜] lgpl [〜#〜] ライセンスの対象となるクラスをサブクラス化すると、作業はライブラリではなく、ライブラリを使用する作業つまり、コード派生作業であり、セクション2でカバーされています( LGPL v2.1 )セクション6でカバーされたものではなく( LGPL v2.1 )。つまり、LGPLの対象となります

Stephen Colebourneがjavalobbyについて 良い要約 を提供していると思います。

私はひざまずくの大ファンではありません弁護士に相談提案、しかしこの場合これを続行するつもりならそうする価値があると思います。 Free Software Foundation の法務チームから厄介な手紙を受け取った。

または、 [〜#〜] fsf [〜#〜] に直接問い合わせることもできます。 お問い合わせページ から:

フリーソフトウェアのライセンスと著作権についての質問

弊社の ライセンスFAQライセンスリスト一般的なコピーレフト情報 、および 関連ページ を確認してください。質問が残っている場合は、<[email protected]>にメールを送信してください。

ちなみに、関連する質問 リフレクションとLGPL では、 gbjbaanbLGPL 3.0パースペクティブ で回答します。

26
Mark Booth

標準私は弁護士の免責事項ではありません。

LGPLでは、ライブラリのソースコードを変更して、コードを使用した人に配布する必要があります。それはではありません、ライブラリを使用するコードがオープンソースであり、同じライセンスの下でリリースされている必要があります。

Wikipediaクラス継承 に関するセクションを含む、LGPLのより詳細な、しかし非法的説明については。

13
unholysampler

"LGPLコードを変更したい..."これは、変更されたコードをリリースする必要があることを十分に示しています。次に、その変更されたコードの拡張が派生作業であるかどうかを拡張することは競合の対象であり、そうであればLGPLの対象になります。

あなたがしようとしているように見えるのは、LGPLを回避することです。この場合、これらのテクニックではできません。

それが派生物である場合、プログラムの条件は、「顧客自身の使用のための変更およびそのような変更をデバッグするためのリバースエンジニアリング」を可能にする必要があります。 LGPLプログラムを使用する著作物が派生著作物であるかどうかは、法的な問題です。

しかし、あなたがしようとしていることがLGPLを回避することである場合、 Mark Booth の推奨に従ってFSFに連絡します。

5
user7519

私の推測:(ただしIANAL)オープンソースとしてrelease変更されたライブラリをLGPLコードとしてしてから商用プログラムにドロップします。それはうまくいくでしょう。事実上、ライブラリのオープンソースフォークを手に入れ、フロントエンドを販売することになります。

しかし、他の多くの人が正しく言ったように、FSFに質問してください:これは、興味をそそる病的なシナリオです。それが当てはまるかどうか、あなたと同じくらい不思議に思うかもしれません。 (または、少なくとも、トピックについてFAQエントリを公開するのに十分気になっています)

1
ZJR

https://www.gnu.org/licenses/lgpl-Java.html

Javaアプリケーションを配布する場合、LGPLに準拠するのは簡単です。アプリケーションのライセンスでは、ユーザーがライブラリを変更できるようにし、コードをリバースエンジニアリングしてこれらの変更をデバッグできるようにする必要があります。これは、ソースコードやアプリケーションの内部に関する詳細を提供する必要があることを意味するものではありません。もちろん、ユーザーがライブラリに加える可能性のあるいくつかの変更は、インターフェイスを壊し、ライブラリがアプリケーションで機能しなくなる可能性があります。そのことを心配する必要はありません。ライブラリを変更する人は、ライブラリを機能させる責任があります。

つまり、ライブラリコード自体を変更しない限り、継承に問題はありませんが、変更しても、アプリケーションコードではなく、ライブラリの変更されたコードのみをリリースする必要があります。

1
Nik.B