LGPLはこれを許可していますか？

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

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

その後、これらの機能を独自のソフトウェアに実装する予定です。修正されたLGPLコードを配布する準備はできていますが、必要な機能を実装する独自のソフトウェアは配布しません。

LGPLの利用規約に違反していますか？

これは複雑な質問ですが、あなたが提案したことは許されないと思います。

ライブラリにサブクラスを追加しやすくするために、少なくともライブラリにフックを追加することをお勧めします。LGPL の精神をバイパスする。

問題は、自分のコードでLGPLライセンスの対象となるクラスをサブクラス化すると、あなたの作品はライブラリを使用する作品ではなく、ライブラリに基づいた作品になり、コードが派生物であることを意味しますセクション6（LGPL v2.1）でカバーされているものではなく、セクション2（LGPL v2.1）でカバーされている作業。すなわち、LGPLの対象になります！

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

私は膝ジャークの大ファンではない、あなたの弁護士に話の提案が、この場合には、私はあなたがこのを続行することを計画している場合、それはそうすることも価値があるだろうと思いますが、そうでなければ、から厄介な手紙を取得される可能性がありますフリーソフトウェア財団法務チーム。

または、FSFに直接質問することもできます。連絡先ページから：

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

ライセンスに関するFAQ、ライセンスリスト、一般的なコピーレフト情報、および関連ページを確認してください。質問が残る場合は、<licensing@gnu.org>にメールしてください。

ちなみに、関連する質問ReflectionとLGPLでは、gbjbaanbがLGPL 3.0の観点で答えています。

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

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

LGPLのより詳細であるが弁護士ではない説明（クラスの継承に関するセクションを含む）については、ウィキペディア。

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

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

それが二次的著作物である場合、プログラムの条件は「顧客自身の使用のための修正およびそのような修正をデバッグするためのリバースエンジニアリング」を考慮しなければなりません。LGPLプログラムを使用する作品が二次的著作物であるかどうかは法的な問題です。

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

私の推測：（しかしIANAL）あなたがすべきリリースオープンソースとしてLGPLのコードのような修飾ライブラリをし、その後、商用プログラムにドロップします。それはうまくいくでしょう。事実上、ライブラリのオープンソースフォークが存在することになり、そのためのフロントエンドを販売することになります。

しかし、他の多くの人が正当に言ったように、FSFに質問してください。該当するかどうかは、あなたと同じくらい不思議に思うかもしれません。（または、少なくともトピックについてのFAQエントリを公開するのに十分なほど気にします）

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

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

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