LGPLプロジェクトに基づいてプログラムを作成しましたが、ソースコードを公開することはできません

LGPLは、MIT、BSD、Apacheのような寛容なライセンスだと思いました。しかし、今日は、LGPL（ライブラリなど）へのリンクのみがクローズドソースコードから許可されていることを読みました。

LGPLプログラムに基づいた雇用主向けのプログラムを作成しましたが、かなりの修正が加えられています。もちろん、その変更されたソースコードをそこに置くことは許可されていません。同時に、私はそれを配布する必要があります（そうですか？）。

だから私はこれに回避策があるのだろうかと思うので、私はこのクローズドソースを維持することができます（ソースを公開できるといいのですが）-提案はありますか？

私のアイデア：オリジナルのLGPLアプリのほとんどの機能を外部ライブラリに入れて、最初からコア実行可能ファイルを記述できますが、変更していないすべての機能についてはライブラリを参照できますか？

現在、すべてが.jarファイルにあります（Java / Swingです）。あなたが私の考えが法的に/技術的に実行可能であると思うなら-私が書いたものとオリジナルが何であるかを分離するのにどれだけの労力がかかるでしょうか？私はJavaに精通していません。

まず第一に、ここ（インターネットなど）で法的助言を行うことは良い考えではありません。

第二に、これは弁護士ではなく私だけの話です。LGPLのプログラムを採用して雇用主向けに修正する前に、そのことを考えておく必要があります。

ライセンスが気に入らなかったからといって無視できるものであったとしても、ライセンスを今持っていても意味がありませんか？

あなたおよび/またはあなたの雇用主があなたの修正を加えたソースコードを公開したくない場合は、そのLGPLコードの使用をやめ、それを取り除く必要があります。

繰り返しますが、それは私が話しているだけです。

本物の弁護士からアドバイスを受けてください。

DLLにコードを追加してライセンスを回避することについてのあなたの質問に答えて、私はそれが次のように機能すると思います。

元のプログラムを変更して、外部ライブラリの関数を呼び出せるようにします。ニーズ、ライブラリ、関数名などに固有のコードを作成せずに、そうする必要があります。

ライセンス要件に従って、これらの変更を公開します。

次に、独自の独自コードを使用して独自の外部ライブラリを作成し、そのプログラムに変更を加えて、そのプログラムをロードして実行するように依頼します。

LGPLライセンスの完全な範囲を知らないので、それがあなたのライブラリを公開する必要を避けるのに十分であるかどうかはわかりませんが、そうするでしょう。

しかし、再び...

弁護士からアドバイスを受ける

LGPLまたは同等のライセンス（少なくともプロジェクトで使用するのに十分なもの）の下で公開されているほとんどのオープンソースライブラリは、オープン/クローズド原則http://en.wikipedia.org/wiki/Open/closed_principleを使用して構築されています。

アプリケーションをLGPLライブラリにリンクし、すべての拡張機能が閉じたアプリケーションコードに含まれるように、コードをリファクタリングできる必要があります。

同じ免責事項：IANAL。

これまで誰も言及していないことは、コードを分離しても、LGPLパーツにソースコードを配布するか、少なくともダウンロード可能な場所に関する情報を提供する必要があるということです。

それを回避する唯一の方法は、そもそもそれらを配布しないことです。

ライセンスを回避しようとするのは良いことではないと理解するために弁護士が必要だとは思わない。常識で十分です。

代わりに、LGPLプログラムの元の作成者に連絡して、別の独自のライセンスを要求/購入することができます。

他の唯一の選択肢は、ソースをリリースするか、完全に書き換えることです。

IANAL、TINLAなど

LGPLは、MIT、BSD、Apacheのような寛容なライセンスだと思いました。しかし、今日は、LGPL（ライブラリなど）へのリンクのみがクローズドソースコードから許可されていることを読みました。

はい、LGPLでは、作品のコピーを受け取る人にソースコードを提供するか、ソフトウェアの受信者がLGPLの作品のバージョンを新しいものに置き換えることができる形式で作品を配布する必要があります。バージョン。いずれの場合も、作品のLGPL部分に対するすべての変更は、作品のすべての受信者が利用できる必要があります。

LGPLプログラムに基づいた雇用主向けのプログラムを作成しましたが、かなりの修正が加えられています。もちろん、その変更されたソースコードをそこに置くことは許可されていません。同時に、私はそれを配布する必要があります（そうですか？）。

正しい。ライセンスでは、ソフトウェアのすべての受信者にソースコードへのアクセスを許可することが義務付けられています。

私のアイデア：オリジナルのLGPLアプリのほとんどの機能を外部ライブラリに入れて、最初からコア実行可能ファイルを記述できますが、変更していないすべての機能についてはライブラリを参照できますか？

これは派生作品を構成する可能性があり、プログラムをライブラリにストリップダウンするすべてのビルドスクリプトを配布する必要があります。

現在、すべてが.jarファイルにあります（Java / Swingです）。あなたが私の考えが法的に/技術的に実行可能であると思うなら-私が書いたものとオリジナルが何であるかを分離するのにどれだけの労力がかかるでしょうか？私はJavaに精通していません。

「静的」リンクと「動的」リンクを構成するものが明確でないため、JavaはLGPLに多数の新しい問題を追加します。GPLに対するLGPLの例外はその概念に依存しているため、LGPLはほとんどの場合GPLと実際に同等です。提起される質問に答えるには、会社の法務チームに相談する必要があります。

私のアドバイスは、社外の誰かがプログラムにアクセスできるようになったら、それを廃棄してやり直すことです。ライセンスの要件を満たせない場合、配布することは一切許可されません。

プログラムはのみ使用可能になります場合は内の会社、あなたは唯一の会社の従業員へのソースを利用できるようにする必要があります。既存の会社のソース管理に追加することをお勧めします。これは、社外の誰もアクセスできない限り、LGPLの要件を満たします。

アダプタパターンを使用できますが、元のコードには触れないでください。また、LGPLを使用すると、クラスを継承し、独自のプロジェクトのクラスの機能をオーバーライドできます。

これが私の理解です、IANAL。

使用しているコードをカバーするLGPLバージョンのテキストを確認してください。その要件は、LGPLでコード化されたコードは、通常は共有ライブラリ/ jarファイルを使用して、スワップアウト可能である必要があることだと思います。使用するコードをLGPLでライブラリに分離できる場合は、LGPLの下でそれをリリースできますが、好きなライセンスでアプリケーションをリリースできます。

ライセンスを回避することはできません。抜け穴を見つけたとしても、それはまだ非倫理的です（ただし、それは一部の人々にとっては別の質問です）。あなたができることは、そのソフトウェアの作者に連絡し、状況を説明し、別のライセンスを要求することです。彼が価格に対して特別なライセンスを提供してくれるなら、問題のコンポーネントを使用せずにソフトウェアを書き換えるコストと比較できます。そして、単に安いものを使用してください。