licensing - LGPL/GPL ライセンス

Question

LGPL のコンポーネントを使用する商用 Web アプリがあります。このコンポーネントにはプラグイン アーキテクチャがあるため、ライブラリ (LGPL) を使用するこのコンポーネント用のプラグを作成しました。このライブラリは、GPL であるデータ ソースを使用します。

これは、Web アプリのソースを解放する必要があるということですか? それとも、プラグインのソースをリリースする必要があるだけですか?

ご意見やアドバイスをいただきありがとうございます。下手な英語をお許しください。

Answer 1

100% 確実にするには、FAQを読んでから、ソフトウェア ライセンスに詳しい弁護士に相談してください。そうでない弁護士とは話さないでください。安全のためにフリー/オープンソースのものを使用しないように言われるからです。

とにかく、「GPL であるデータ ソース」とはどういう意味ですか? GPL ソース コードはアプリケーションにリンクされていますか?

FAQ には、プラグインと GPL に関するいくつかの質問があります。

GPL の及ぶプラグインをロードするように設計された不自由なプログラムをリリースすることはできますか?

プログラムがプラグインを呼び出す方法によって異なります。たとえば、プログラムが単純な fork と exec のみを使用してプラグインを呼び出して通信する場合、プラグインは別個のプログラムであるため、プラグインのライセンスはメイン プログラムに関する要件を作成しません。

プログラムがプラグインを動的にリンクし、それらが相互に関数呼び出しを行い、データ構造を共有する場合、それらは単一のプログラムを形成すると考えられます。これは、メイン プログラムとプラグインの両方の拡張として扱われる必要があります。GPL の対象となるプラグインを使用するには、メイン プログラムが GPL または GPL と互換性のあるフリー ソフトウェア ライセンスに基づいてリリースされている必要があります。プラグイン。

プログラムがプラグインを動的にリンクしているが、それらの間の通信がプラグインの「メイン」関数をいくつかのオプションで呼び出し、それが戻るのを待つことに限定されている場合、それは境界的なケースです。

共有メモリを使用して複雑なデータ構造と通信することは、動的リンクとほとんど同じです。

他の人が指摘しているように、配布されていない Web アプリは、プレーンな GPL (Affero GPL ではありませんか?) の下では私的使用と見なされるようです。

ある企業が、GPL で保護されたプログラムの修正版を Web サイトで実行しています。GPL は、修正したソースをリリースしなければならないと言っていますか?

GPL は、誰でも変更したバージョンを作成し、それを他人に配布することなく使用することを許可しています。この会社がやっていることは、その特殊なケースです。したがって、会社は変更されたソースをリリースする必要はありません。

変更を公開することなく、自由に変更を加えて個人的に使用できることが重要です。ただし、プログラムをサーバー マシンに置いて、一般の人が対話できるようにすることは、「私的な」使用にはなりません。そのため、その特別な場合にソース コードのリリースを要求することは正当です。これに対処したい開発者は、ネットワーク サーバー用に設計されたプログラムに GNU Affero GPL を使用することをお勧めします。

Answer 2

これは、Web アプリのソースを解放する必要があるということですか?

いいえ*

または、プラグインのソースをリリースする必要があるだけですか?

アプリケーションを配布する場合は、その LGPL 部分のソース コードも配布する必要があります。

また、アプリケーションを受け取った人なら誰でも変更できるようにする必要があります。これは、コンパイルされたアプリケーションにとって重要です。必要なオブジェクト ファイルを含める必要があります。これにより、アプリを変更されたバージョンの LGPL コードに再リンクできるようになります。または、動的リンクを使用します。コードの LGPL 部分を変更して、アプリと再結合できるようにする必要があるという考えです。

以下は、私の言葉による LGPL の要件の一部です (私は弁護士ではありません)。

• LGPL コードと他のコードとの間には、ある種の明確な分離が必要です。特に、受信者が LGPL コードを変更したり、ライブラリの変更されたバージョンまたは新しいバージョンなどの他のコードに完全に置き換えたりすることが可能でなければなりません。したがって、コンパイルされたプログラムの場合、LGPL コードは動的にリンクされ (別の DLL または共有ファイルのように)、同様のライブラリに簡単に置き換えられ、相互運用可能である必要があります。または、静的にリンクされている場合は、代替ライブラリで再コンパイルできるように、最低限必要なソース ファイルおよび/またはオブジェクト ファイルを提供する必要があります。非 LGPL 部分には、非常に単純なヘッダー ファイルを除いて、LGPL コードのどの部分も含まれていない場合があります。
• コードのどの部分が LGPL でカバーされているかを明確に指摘する必要があります。これには、元の著作権表示と LGPL のテキスト (ベースとなる GPL を含む) が含まれます。
• 結合されたソフトウェアが実行中に著作権表示を表示する場合、LGPL の対象となる部分の著作権表示も、LGPL および GPL へのリンクと共にここに表示する必要があります。
• 場合によっては、結合されたアプリケーションで LGPLd コードの修正バージョンを使用する方法を詳述したインストール情報を提供する必要があります。

これらはいくつかの制限に過ぎませんでしたが、LGPL は、GPL のような他のライセンスにはない多くの自由も提供します。他の誰かの LGPL ライセンス コードを含む結合された作品を配布する場合:

• アプリケーションの残りの部分 (つまり、非 LGPL 部分) のソース コードをリリースする必要はありません。これに対する唯一の例外は、上記のとおりです。すべてが静的にリンクされている場合は、LGPL コードの代替バージョンまたは修正バージョンと再リンクできるように、十分なコード (および/またはオブジェクト ファイル) を提供する必要があります。動的にリンクし、通常の API を介して対話している場合は、それについて心配する必要はありません。
• アプリケーションの残りの部分を GPL の下でリリースする必要はありません。配布する際に規則に従うことを条件に、より制限の厳しいプロプライエタリ ライセンスを含め、任意のライセンスを使用できます。
• コピー防止または DRM ソフトウェアを実装している場合にコードの使用を禁止する GPL バージョン 3 とは異なり、コピー防止または DRM を含むアプリケーションで LGPL バージョン 3 ライセンス コードを使用できます。

最近、LGPL ライセンスの分析を書きました。詳細については、こちらを参照してください。

また、 LGPLの実際のテキストをお読みください。長すぎません。

*使用しているライブラリには GPL データ ソースがあるとおっしゃいました。おそらくこれは、この GPL データを実際に配布するのではなく、それを使用する LGPL ライブラリだけを配布することを意味します。

Answer 3

私は弁護士ではありませんが、プログラムを配布しない限り (Web アプリとして使用できるようにすることは配布ではありません)、ソースを公開する必要はありません。

Answer 4

Web アプリとは、サーバー上でソフトウェアを実行するだけで、ユーザーに配布しないことを意味する場合は、単純なはずです。配布なし、ソースを提供する必要はありません。

(GPL3では違うかもしれません)