LGPL v3ライブラリを使用していて、アップグレードしました。これらのアップグレードを使用する前に、公開する必要があることを理解しています。それは大丈夫だ。
自分の商用ライブラリを使用してアップグレードを実行する場合は合法ですか(アップグレードは公開されますが、商用ライブラリは公開されません)。注:通常、質問は反対側です。GPLライブラリを使用したい商用アプリケーションです。
(1)に「はい」の場合、アップグレードされたLGPLライブラリのビルドにいくつかの制限がありますか?商用ライブラリは動的または静的にリンクされますか?
まず、必要なIANALの免責事項。私見LGPLはあなたに公開を強制することはできません動作中コード。そのlibの新しいバージョンを公開し、新しいバグを導入すると仮定しましょう。 noそのバグを修正する義務があります(少なくとも、LGPL自体からではなく、顧客と契約を結んでいる可能性がありますが、それは別の質問です)。
ここで、この「バグ」が、ライブラリ(または追加した機能)がターゲットシステムで商用ライブラリが利用可能な場合にのみ機能するという性質のものであるとさらに仮定しましょう。これは最初の状況に大きな違いはありません。それでも、商用パーツを公開する義務はありません。フォークが不人気になるリスクはありますが、このように違法になることはないと思います。
ただし、LGPLの1つのコアポイントは、エンドユーザーが制限なしで公開しているアプリケーションシステムのLGPLでカバーされている部分を更新できるようにする必要があるということです。 LGPLライブラリのデプロイされたバージョンが、世界に公開していないものに対して静的にリンクされている場合、これはおそらく不可能です。したがって、ライセンス違反を回避したい場合は、変更後も、他の人が商用ライブラリと連携するために「有効」になっている形式でLGPLライブラリをコンパイルできることを確認する必要があります。商用ライブラリのライセンス。
LGPLがあなたが説明したシナリオを決定的に否定または許可しているとは思いません。 LGPLの精神に反しているように聞こえます。
LGPLコードをリファクタリングして、独自の機能をプラグインできるインターフェイスを追加すると、より良い解決策になりませんか?これは、同様の要件を持つ他の人に利益をもたらす可能性があります。
これは、パッチがライブラリのメンテナによって受け入れられた場合にも、あなた自身の利益になります。ライブラリのフォークをライブラリの新しいリビジョンとマージする必要はありません。