私はで書かれたソフトウェアライブラリ解除したいクラスベースのオブジェクト指向プログラミング言語で（Java）のWebベースのソースコードホスティングサービス事業のフォークをすることができ、メインプロジェクトにマージプル経由（GitHubのをリクエスト）。私はウェブで調査し、ソフトウェアのライセンス方法について多くのことを考えました。（IANALの観点から）次の仮定は正しいですか？

• LGPLとMPLはどちらも、他のソフトウェアプロジェクト内で使用されているLGPL / MPLライセンスソフトウェアの変更の共有を促進します。変更されたライブラリのユーザーにライブラリの別のフォークをホストするように要求する代わりに、元のライブラリへの貢献を促進することができます（たとえばプル要求を介して）。

• 主な違いは、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のいずれかが、「このソフトウェアへのすべての貢献が私たちの財産になる」という条項を制定するのと同じくらいおかしなことをすることはほとんどありませんが、組織は、好ましくない新しいライセンスバージョンをリリースします。

これは、「修正された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"のクローズドソースのままにして、プロジェクトに新しい機能を追加できます。

メインファイルをコミュニティに戻すと、「新しい機能を追加した」という情報が得られますが、この新しい機能をオープンに組み込むことはできません。新しい機能が密接にある場合、迷惑になることがあります。 -ライブラリが解決しようとしている問題に関連しています。

明らかに、それはエッジケースであり、誰かがそれを望んでいる可能性は非常に低いですが、MPLv2を使用する際に注意しなければならないリスクです。

LGPLは、このような動作を禁止するように書かれています。見る：

• https://www.javalobby.org//java/forums/t15903.html#91819035
• LGPLはこれを許可していますか？

元のLGPLライセンスを引用します。

「ライブラリに基づく作業」と「ライブラリを使用する作業」の違いに注意してください。前者にはライブラリから派生したコードが含まれていますが、後者を実行するにはライブラリと組み合わせる必要があります。

コピーレフトは「ライブラリに基づいた作品」にのみ適用されます。さて、実際の「図書館に基づいた作品」とは何ですか？解釈の余地があります。これは良いことだけでなく、ライセンスに従うことがより複雑になり、そのため怖いことを意味します。単にあなたのライブラリを使用しない人がいる可能性があります。

この意味で、LGPLはMPLよりも制限的ですが、プロジェクトの整合性をより保護します。

MPLにより、プロプライエタリな世界のユーザーがライブラリを修正して使用しやすくなりますが、修正を共有する必要があります

MPLの利点は、ユーザーがライブラリでバグを見つけた場合、すべてのコードを提供する必要はなく、修正のみを提供することなく、ファイル内でバグを直接修正できることです。実際には、クライアントに作品を配布するとき、彼は修正を含むプロジェクトの分岐へのリンクを提供するだけでよく、彼は良いです。

LGPLを使用すると、事態はさらに複雑になります。誰かがあなたのプロジェクトをフォークし、バグを修正し、それを自分のプロプライエタリソフトウェアに静的に埋め込む場合、LGPLの下で「ライブラリに基づいた作業」をユーザーに配布する必要があります。特にライブラリが静的に埋め込まれている場合、これはかなりあいまいな概念です...これに関しては、元のLGPLに「静的」例外のようなものが存在しない最初の理由だと思います。「ライブラリに基づいた作業」の識別を簡単にします。これは、独自のソフトウェアで呼び出す動的ライブラリです。

結果として、MPLを使用すると、プロプライエタリベンダーがLGPLよりもライブラリを使用して修正を送信しやすくなります。

同時に、ほとんどの場合、プロプライエタリベンダーは、複雑なライブラリに飛び込むためのリソースも時間もないため、ほとんどの場合、自分で修正することはできません。むしろ、GitHubリポジトリで問題を開くか、メーリングリストで電子メールを送信して修正を待ちます。

この点で、LGPLはこの種の動作をさらに強化しています。しかし、強制は本当に必要ですか？

結論

LGPLとMPLの選択は難しい質問であり、ソフトウェアライセンスの場合と同様に、目標に依存します。両方のライセンスは非常に似ていますが、同時に非常に異なります。彼らは非常に異なる目標と哲学のために設計されました。

LGPLは、Free Software Foundationによって作成され、プロプライエタリな世界でフリーソフトウェアライブラリを広く使用できるようになりましたが、フリーソフトウェアを促進し、プロプライエタリソフトウェアと戦うという考えを常に念頭に置いています。それはすべて、彼らのイデオロギーに対する戦略の一部です。参照：https : //www.gnu.org/licenses/why-not-lgpl.html

MPLは、Mozillaによって設計された実用的なライセンスであり、元のライブラリにある種の共有を強制すると同時に、独自のソフトウェアやアドオン（Mozilla自体を含む）を作成することを人々に奨励しています。 LGPLですが、それでも有害と見なされます。

本質的に、MPLv2は多くの人に許容ライセンスと見なされていますが、静的例外を含むLGPLv3はこの方法で呼ばれることはほとんどありません。

編集

重要なことについて言及するのを忘れました。LGPLv3（静的例外の有無にかかわらず）はtivoizationを禁止します。あなたはそれが「詳細」であると考えるかもしれませんが、実際にはあなたの目標次第ではありません。ユーザーの自由を気にしていますか？その後、それは詳細ではありません。ライブラリをAppleのデバイスで使用できるようになりますか？VLCは使用されることをより重視しているため、そのような制限を含まないLGPLv2を使用することにしました。同様に、これがLinuxがGPLv2を使用し続ける理由の1つです。また、MPLv2は、FSFイデオロギーではなく、より「実用的な」オープンソースの哲学を念頭に置いて作成されたライセンスであるため、明らかに制限はありません。

私が見逃したこのような他の「マイナーな」ものがあるかもしれません。