Loading article…
Mozilla Public License ( MPL ) は、FirefoxやThunderbirdなど、Mozilla Foundation のほとんどのソフトウェアに適用される、無料のオープンソースの弱いコピーレフト ライセンスです。[ 8 ] MPL は Mozilla によって開発および維持されており、[ 9 ]オープンソース開発者とプロプライエタリ開発者の両方の懸念のバランスを取ろうとしています。これは、寛容なソフトウェアBSD スタイルのライセンスとGNU General Public Licenseの中間の立場にあるものとして区別されます。[ 10 ]そのため、MPL ライセンスのコンポーネントが MPL の条件の下でアクセス可能である限り、MPL ライセンスのコードをプロプライエタリなコードベースに統合することができます。
MPLは、AdobeがFlex製品ラインのライセンス供与に使用したり[ 11 ]、The Document FoundationがLibreOffice 4.0（ LGPL 3+でも使用）のライセンス供与に使用したりするなど、他の企業にも使用されています[ 12 ] [ 13 ] 。バージョン1.1は、 Sun MicrosystemsのCommon Development and Distribution Licenseのような派生ライセンスを形成するために、いくつかのプロジェクトによって採用されました[ 14 ]。バージョン1.1はマイナーアップデート[ 15 ]、バージョン2.0はメジャーアップデート[ 16 ]で、よりシンプルにし、他のライセンスとの互換性を向上させるという目標に近づいています[ 17 ]。
MPLでは、ソースコードを作成または変更する「貢献者」から、オプションの補助ディストリビューター（それ自体がライセンシー）を介してライセンシーに権利が移転すると定義されています。著作権と特許のライセンスは寛大で、作品の自由な使用、変更、配布、および「利用」を許可しますが、貢献者の商標に対する権利はライセンシーに付与しません。[ 7 ]ライセンシーがライセンスの条件に従わない場合、これらの権利は終了しますが、違反したライセンシーが遵守に戻ると権利が回復し、貢献者から書面による通知を受けた場合でも、その貢献者のコードに対する権利のみを失うことになります。Apache Licenseと同様の特許報復条項が含まれており、補助ディストリビューターのさらなる受領者を特許トロールから保護します。貢献者は保証と責任を放棄しますが、補助ディストリビューターが自らの名義でそのようなものを提供することを許可します。
ライセンスによって付与される権利と引き換えに、ライセンシーはライセンスされたソースコードの配布に関して一定の責任を負わなければなりません。対象となるソースコードファイルはMPLの下に置かれなければならず、配布者は「受領者の権利を変更または制限しようとしてはならない」。MPLはソースコードファイルをMPLライセンス部分とプロプライエタリ部分の境界として扱います。つまり、特定のソースファイル内のコードのすべてまたはすべてがMPLの下に置かれるかのどちらかです。MPLでカバーされたファイルのみで構成される実行可能ファイルはサブライセンスできますが、ライセンシーは、その中のすべてのソースコードへのアクセスを保証するか、または提供しなければなりません。受領者は、ライセンスされたソースコードを、別の、あるいはプロプライエタリなライセンスの下にある他のファイルと組み合わせることで、あらゆる条件で配布できる「より大きな作品」を形成できますが、ここでもMPLでカバーされたソースファイルは自由に利用できるようにしなければなりません。[ 7 ]これにより、MPLは、派生作品すべてをプロプライエタリとして再ライセンスすることを許可するMITライセンスやBSDライセンスと、派生作品全体をGPLの下でライセンスすることを義務付けるGPLとの間の妥協案となります。 MPLは、派生プロジェクトで独自のモジュールを許可しつつ、コアファイルはオープンソースのままにすることを義務付けることで、企業とオープンソースコミュニティの両方がコアソフトウェアの開発に協力するよう促すように設計されている。[ 18 ]
MPL の対象となるソースファイルが MPL の対象となるという例外は、バージョン 2.0 以降のコードが GNU GPL、GNU Lesser GPL (LGPL)、またはAffero GPL (AGPL) の別のコードファイルと結合される場合に発生します。この場合、プログラム全体は選択された GNU ライセンスの対象となりますが、MPL の対象となるファイルはデュアル ライセンスとなり、受信者は GNU ライセンスまたは MPL のいずれかで配布することを選択できます。[ 4 ] MPL コードの最初の作成者は、ソースファイルに通知を追加することで、この GPL 互換性をオプトアウトすることができます。[ 7 ]
MPL でカバーされるコードは、受け取ったライセンス バージョンまたはそれ以降のバージョンの条件に基づいて配布できることが明示的に認められています。[ 1 ] : 10.2バージョン 1.0 または 1.1 のコードがこのメカニズムによってバージョン 2.0 にアップグレードされた場合、1.x でカバーされるコードには、前述の GPL と互換性がないことを示す通知を付ける必要があります。MPL は、新しいライセンスを作成するために変更することができますが、そのライセンスは Mozilla または Netscape を参照しないものとします。
MPL のバージョン 1.0 は、Netscape Communications Corporationで弁護士として働いていたMitchell Bakerによって 1998 年に作成されました。[ 19 ] Netscape は、独自のNetscape Web ブラウザを開発するためのオープンソース戦略によって、MicrosoftのブラウザであるInternet Explorerとより良く競争できることを期待していました。[ 20 ]ブラウザのコードを対象とするために、同社はNetscape Public License (NPL) として知られるライセンスを作成しました。このライセンスには、オープンに開発されたコードであっても理論的には独自のライセンスとして再ライセンスできる条項が含まれていました。[ 21 ]
しかし同時に、ベイカーはNPLに似た2つ目のライセンスを開発した。それはNetscapeの新しいオープンソースコードベースのプロジェクト名にちなんでMozilla Public Licenseと呼ばれ、当初はNPLでカバーされるコアモジュールを補完するソフトウェアのみを対象としていたが、NPLよりも人気が高まり、最終的にはOpen Source Initiativeの承認を得た。[ 22 ]
1年も経たないうちに、ベイカーとMozilla組織はMPLに変更を加え、マイナーアップデートであるバージョン1.1をリリースした。[ 23 ]この改訂は、組織と個人の両方からのコメントを考慮したオープンなプロセスで行われた。主な目的は、特許に関する条項を明確にし、複数のライセンスを可能にすることであった。この最後の機能は、GPLのようなより厳格なライセンスを好む開発者との協力を促すことを目的としていた。[ 24 ]多くのプロジェクトがこのバージョンから独自のライセンスを派生させただけでなく、その構造、法的正確さ、特許権に関する明示的な条項は、GPL（バージョン3）のような人気のあるライセンスの後の改訂に大きな影響を与えることになった。[ 14 ]
バージョン 1.0 と 1.1 はどちらも GPL と互換性がないため、フリー ソフトウェア財団はバージョン 1.1 の使用を推奨しませんでした。[ 6 ]これらの理由から、Firefox の初期バージョンは、MPL 1.1、GPL 2.0、LGPL 2.1 の複数のライセンスでリリースされました。[ 25 ] Mozilla Application Suite などの古いソフトウェアは、現在も3 つのライセンスの下で提供されています。そのため、10 年以上変更が加えられていなかった MPL のバージョン 2.0 を作成するためのオープン プロセスが 2010 年初頭に開始されました。次の 21 か月で、MPL はライセンスをより明確にして適用しやすくするだけでなく、GPL およびApacheライセンスとの互換性も実現するように変更されました。[ 17 ] [ 26 ]改訂チームは Baker が監督し、Luis VillaがGervase Markham と Harvey Anderson のサポートを受けて主導しました。彼らは、2012年1月3日にバージョン2.0の最終版をリリースする前に、 3つのアルファ版ドラフト、2つのベータ版ドラフト、および2つのリリース候補版を公開して意見を募った。 [ 17 ]
Public License 2.0 (MPL-2.0)
{{cite web}}: CS1 maint: bot: 元の URL の状態が不明です (リンク)このErlangライセンスは、Mozilla Public License、バージョン1.0の派生作品です。