LGPLはMIT、BSD、Apacheのように寛容なライセンスだと思いました。しかし、今日読んだところ、クローズドソースコードから許可されているのはlinking to LGPL(libraries etc)-それ以外はコピーレフトです-したがって、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プログラムに基づいた雇用主向けのプログラムを作成しましたが、大幅に変更されています。もちろん、その変更されたソースコードを公開することはできません。同時に、配布する場合、私はしなければなりません(そうですか?)。
正しい。ライセンスでは、ソフトウェアのすべての受信者にソースコードへのアクセス権を付与することが義務付けられています。
私のアイデア:元のLGPLアプリのほとんどの関数を外部ライブラリに入れ、コア実行可能ファイルを最初から作成し、ライブラリに戻って、変更していないすべての関数を参照することはできますか?
これは派生物を構成する可能性があり、プログラムをライブラリーに分解するすべてのビルドスクリプトを配布する必要があります。
現在、すべてが.jarファイルに含まれています(Java/Swingです)。私のアイデアが合法的/技術的に実現可能であると思われる場合-私が書いたものと元のものが何であるかを分離するのにどれだけの努力が必要でしょうか?私が一番ではないJavaに詳しい。
「静的」および「動的」リンクの構成要素が明確でないため、JavaはLGPLに多くの新しい問題を追加します。 GPLに対するLGPLの例外はその概念に依存しているため、LGPLはほとんどの場合、実際にはGPLと同等です。発生する質問に回答するには、会社の法務チームに相談する必要があります。
私のアドバイスは、社外の誰かがプログラムにアクセスできるようになると、それをスクラップして最初からやり直しますライセンスの要件を満たせない場合、配布することはまったく許可されません。 。
プログラムが社内でのみ利用できる場合は、会社の従業員だけがソースを利用できるようにする必要があります。既存の会社のソース管理に追加することをお勧めします。これは、社外の誰もアクセスできない限り、LGPLの要件を満たします。
アダプターパターンを使用でき、元のコードには触れないでください。また、LGPLを使用すると、クラスを継承し、独自のプロジェクトのクラスの機能をオーバーライドできます。
これが私の理解です、IANAL。
使用しているコードをカバーするLGPLバージョンのテキストを確認してください。 LGPLで作成されたコードは、通常は共有ライブラリ/ jarファイルを使用して、スワップアウト可能である必要があると私は考えています。 LGPLで使用するコードをライブラリに分離できる場合は、そのコードをLGPLでリリースし、アプリケーションを好きなライセンスでリリースできます。
ライセンスを回避することはできません。抜け穴を見つけたとしても、それは非倫理的です(それは一部の人にとっては別の質問ですが)。あなたができることは、そのソフトウェアの作者に連絡し、状況を説明し、別のライセンスを要求することです。彼が価格で特別なライセンスを提供する用意がある場合は、これを問題のコンポーネントを使用せずにソフトウェアを書き換えるコストと比較できます。そして、より安いものを使ってください。