Mozilla Public License（MPL 2.0）とLesser GNU General Public License（LGPL 3.0）
クラスベースのオブジェクト指向プログラミング言語（Java）で記述されたソフトウェアライブラリをウェブベースのソースコードホスティングサービスでリリースし、 メインプロジェクトにマージされる（プルリクエストによるGitHub）になるプロジェクト。私はWebで調査し、ソフトウェアのライセンスを取得する方法について多くの考えを与えました。私は次の仮定で正しいですか（ [〜＃〜] ianal [〜＃〜] の観点から）？
LGPLとMPLの両方変更の共有を促進は、他のソフトウェアプロジェクト内で使用されているLGPL/MPLライセンスソフトウェアに適用されます。変更されたライブラリーのユーザーにライブラリーのHost a seperate forkを要求する代わりに、元のライブラリーに（たとえば、プルリクエストを介して）昇格させることができます。
主な違いは、MPL/LGPLライセンスコードをプロジェクトにリンクする方法です。 MPLソースコードファイルは（おそらく）独自のソフトウェアプロジェクト（静的リンク）に直接コピーできますが、LGPLライセンスコードは動的にリンク（おそらく独自のソフトウェアプロジェクトに緩やかにリンクする必要があります）エンドユーザーがライセンスソフトウェアライブラリを別のバージョンのライセンスソフトウェアライブラリに切り替えることができるようにするため）。
動的リンク、つまりLGPLは、静的リンク（つまりMPL）を使用するよりもオープンソースソフトウェアライブラリへの貢献を促進することなく、独自のソフトウェア製品をパッケージ化のための追加の障害に課します。静的リンクを許可する 変更されたLGPL があります。
他に関連する違いはありません（ [〜＃〜] ianal [〜＃〜] の観点から）。
古いライセンスバージョンは、最新のものよりも私のニーズに適していません。
ご覧のように、私の主な要件は、ソフトウェアライブラリの変更であり、これにより、一般の人々がオープンソースを維持するのに役立ち、専用製品でのソフトウェアライブラリの使用に制限を課すことがありません。
関連する用語の範囲として、オープンソースとしてリリースされるオリジナルの作品に関連するソフトウェアライブラリの拡張も必要とするライセンスはありません。 _は任意に小さく/大きくすることができるため、最終的には（ソース全体をリリースせずに）独自の製品で使用できないGPLになります。
変更されたLPGL を使用したくなりますが、その反面、不人気な点に落胆します。上記の点に基づいて、私はMPLを好みます。
質問：上記の記述は正しいですか？要件を考慮してどのライセンスを選択すればよいですか？
解決策：受け入れられた回答での議論の助けを借りて、私は人気、リンクの自由のため、MPLに固執することを選択しました。 公式の変更されていないライセンス。
Mozilla Public License と GNU Lesser General Public License の違いを正確に述べたと思いますが、どちらもニーズにぴったり合うかもしれませんが、スキップしています2つのライセンス間の最も重要な違い：
誰が新しいバージョンを作ることができますか？
MPL（セクション10）とLGPL（セクション14）の両方には、ライセンスに現在のバージョンを新しいバージョンに置き換える権利が含まれており、これらのライセンスに適用できるものに関して実際の制限はありません。 Mozilla FoundationやFree Software Foundationが「このソフトウェアへのすべての貢献が私たちの所有物になる」という条項を制定するような奇妙なことをする可能性は非常に低いですが、その1つが組織は、好ましくない新しいライセンスバージョンをリリースします。
これは、「Modified LGPL」の使用に関する別のポイントを提示します。
変更されたライセンスは同じライセンスではありません！
あなたは自分のライセンス条件を指定するかなり驚くべき能力を持っています、そして本質的に言うことができます "これはGPLに従って配布できますが、私の名前をクレジットに入れて私に支払う必要がありますあなたが生み出す収益の1％ "いつでもそうすることで、他の誰かの作品に基づいて新しいライセンスを作成します。これは、MPLまたはLGPLを使用しておらず、新しい「mucahoライセンス」を使用していることを意味します。
つまり、法廷内でライセンスの解釈を擁護する必要がある場合、元のライセンスの作成者から何の助けも得られない可能性があり、彼らのバージョンが適用されるべきであると主張するために彼らが訴訟を起こす可能性は十分にあります。あなたではありません。
もちろん、どちらもマイナーなポイントです。コードがより大きなプロジェクトに直接組み込まれることを期待しない限り、「ライセンスの人気」でさえ問題ではありません。
個人的には、独自の互換性が必要な場合、または実際のMPLとLGPLに基づいて手動で編集する必要がある別のライセンスのどちらかを選択する場合は、MPLの方が適していると思います。 MPLを使用しない理由がない限り、何の援助もなく法廷にいる可能性のあるものではなく、財団によって裏付けられたものを使用してください。
DougMとAERの答えは公平な点を示しています。 MPLv2と静的例外のあるLGPLv3は、コピーレフトをトリガーするイベントに関しては同じです。ただし、LGPLとMPLの間には、もう1つの非常に重要な違いがないと思います。コピーレフトがトリガーされると、コピーレフトは以下に適用されます。
- mPLの場合：元のライブラリとまったく同じファイルに
- lGPLの場合：「ライブラリを使用する作業」ではなく、「ライブラリに基づく作業」へ。したがって、LGPLはコピーレフトを新しいファイルに拡張できる可能性があります。
エッジケース：MPLを使用すると、ユーザーは改善点を共有できません
MPLはファイルレベルのコピーレフトライセンスです。それは、誰かがそれを（静的または動的に）より大きなプロジェクトに埋め込み、ファイルに変更を加えた場合、この特定のファイルに加えられた変更を解放するだけでよいことを意味します。
コードベースの整合性を開いたままにしておくことに懸念がある場合は、MPLのこのコピーレフト効果では不十分なエッジケースがあります。
たとえば、誰かがプロジェクトのメインファイルの1つを取り、"import my_private_new_file"を追加し、たとえば"my_private_new_file.newAwesomeFeature.run（）"を追加することによってメインメソッドを変更できます。。
そして、このようにして、変更されたメインファイルをリリースし、新機能の実際のロジックを"my_private_new_file"に保持したまま、プロジェクトに新機能を追加できます。
メインファイルをコミュニティに戻すと、「新機能を追加しました」という情報が得られますが、この新機能をオープンに組み込むことはできません...新機能が密接にある場合は、煩わしい場合があります。 -ライブラリが解決しようとしている問題に関連しています。
明らかに、これはEdgeケースであり、誰かがそうすることを望んでいる可能性はほとんどありませんが、MPLv2を使用するときに注意する必要があるリスクです。
LGPLは、そのような行為を禁止するように作成されています。見る：
元のLGPLライセンスを引用します。
「ライブラリに基づく作品」と「ライブラリを利用する作品」の違いに細心の注意を払ってください。前者にはライブラリから派生したコードが含まれていますが、後者は実行するためにライブラリと組み合わせる必要があります。
コピーレフトは「ライブラリに基づく作品」にのみ適用されます。では、実際に「図書館に基づいた作品」とは何でしょうか。それは解釈に余地を残します。これは、ライセンスの遵守がより複雑になり、その結果恐ろしいことになるため、良いことだけではありません。一部の人々は単にあなたのライブラリを使用しない可能性があります。
この意味で、LGPLはMPLよりも制限的ですが、プロジェクトの整合性をより保護します。
MPLを使用すると、プロプライエタリな世界のユーザーがライブラリを修正して使用しやすくなりますが、修正を共有する必要があります。
MPLの利点は、ユーザーがライブラリにバグを見つけた場合、すべてのコードを提供する必要はなく、修正のみを提供することなく、ファイルで直接修正できることです。実際には、彼の仕事をクライアントに配布するとき、彼は修正を含むあなたのプロジェクトのフォークへのリンクを提供することができ、彼は良いです。
LGPLを使用すると、物事はより複雑になります。誰かがプロジェクトをフォークし、バグを修正し、独自のソフトウェアに静的に埋め込む場合、LGPLの下で「ライブラリに基づく作業」をユーザーに配布する必要があります。これは、特にライブラリが静的に埋め込まれている場合、どちらかというと曖昧な概念です...この点で、元のLGPLに「静的な」例外などがないのは、これが元々の理由だったと思います。 「ライブラリに基づく作業」の識別を簡単にします。これは、独自のソフトウェアで呼び出す動的ライブラリです。
その結果、MPLを使用すると、プロプライエタリベンダーがLGPLよりも修正を使用してライブラリに送信することが非常に簡単になります。
同時に、ほとんどの場合、プロプライエタリベンダーには、複雑なライブラリに飛び込むためのリソースや時間がないため、ほとんどの場合、自分で修正することはできません。彼らはむしろGitHubリポジトリで問題をオープンするか、メーリングリストで電子メールを送信して修正を待ちます。
この点で、LGPLはこの種の動作を強化しています。しかし、強制は本当に必要なのでしょうか？
結論
LGPLとMPLのどちらを選択するかは難しい問題であり、通常のソフトウェアライセンスと同様に、目標によって異なります。両方のライセンスは非常に似ていますが、同時に非常に異なります。彼らは非常に異なる目標と哲学のために設計されました。
LGPLは、フリーソフトウェア財団がフリーソフトウェアライブラリをプロプライエタリの世界で広く使用できるようにするために作成されましたが、フリーソフトウェアを宣伝し、プロプライエタリソフトウェアと戦うという考えを常に念頭に置いています。それはすべて彼らのイデオロギーに対する戦略の一部です。参照： https://www.gnu.org/licenses/why-not-lgpl.html
MPLはMozillaによって設計された実用的なライセンスであり、元のライブラリにある種のの共有を強制する一方で、（Mozilla自体を含む）プロプライエタリなソフトウェアとアドオンを作成するように人々に奨励しています。 FSFがLGPLを介して許可するが、それでも有害と見なす慣行。
本質的に、MPLv2は多くの場合は許容ライセンスと見なされますが、静的例外を含むLGPLv3はこのように呼ばれることはほとんどありません。
編集
重要なことを忘れていました。 LGPLv3（静的例外の有無にかかわらず）は、ティボリゼーションを禁止します 。あなたはそれが「詳細」だと思うかもしれませんが、あなたの目標によっては実際にはそうではありません。あなたはユーザーの自由を気にしますか？次に、それは詳細ではありません。ライブラリがAppleのデバイスで使用できることを気にしますか？ VLCは使用されることをより重視するため、 彼らはそのような制限を含まないLGPLv2 を使用することにしました。同様に、それが LinuxがGPLv2 を使い続ける理由の1つです。 MPLv2には、FSFのイデオロギーではなく、より「実用的な」オープンソースの哲学を念頭に置いて作成されたライセンスであるため、アクティベーションの制限もありません。
私が見逃したこのような他の「マイナー」なものがあるかもしれません。