以前問題とされていたのは、Mozilla ライセンスの方針が GPL および LGPL と "互換性" があるかどうかでした。

NPL および MPL が作成されてから、Free Software Foundation 【英文】 は、NPL および MPL は GPL とは "互換性がない" と判断しました。ここでいう "互換性がない" とは、（FSF によると）開発者が NPL または MPL 下のコードを GPL 下のコードと組み合わせてその成果を頒布する場合、GPL で定められた条件に抵触してしまう、ということです。LGPL が GPL と同様の条件を課していることから、実際に MPL が GPL と互換性がない場合、LGPL とも互換性がないことになります。

（LGPL は、LGPL の許でリリースされたソースと非 LGPL 下のコードを、ある特定の方法で組み合わせることを可能にしています。それは例えば、LGPL 下でリリースされたコードのライブラリを使用したアプリケーションをリリースする場合です。ただし、関連する LGPL の条項は、MPL 下のコードと LGPL 下のコードを組み合わせて、より規模の大きな成果を作成する際の、全ての可能性に言及しているわけではありません。特に、Mozilla ソースファイルを、直接 LGPL 下のライブラリと組み合わせる（例：ライブラリ機能の拡張）場合、LGPL 条項の効力、および潜在的なライセンス間の非互換性は、GPL に関連する条項と同様のもののようです。）

開発者が、このようなライセンスの非互換性に基づいて、著作権の侵害を訴えることができるかは不明です。しかし、この問題に関して不明瞭な点を解消するため、そして、代替のライセンスがない場合、コードが GPL または LGPL 下でライセンスされるアプリケーション内で Mozilla コードを利用したいと考える開発者の懸念に応えて、Mozilla コードを再ライセンスして、GPL および LGPL との非互換性の問題を解決したいと考えたのです。

新しい標準的なライセンス・スキームは、MPL/GPL/LGPL トリプルライセンスです。このライセンスは、mozilla.org を通じて配布される全ての新しい Mozilla ソースファイルに使用され、既存のファイルは必要な許可を受け次第、トリプルライセンスに変換される予定です。

MPL/GPL/LGPL トリプルライセンスは、NSPR、NSS、PSM、そして JavaScript エンジンを含めて、過去に Mozilla コードに適用されていたデュアルライセンス・スキームの拡張および改訂版です。主な相違点は、私たちがトリプルライセンス・スキームの中で、GPL に加えて LGPL を代替ライセンスとして利用している点です。

コードの一部分がデュアルまたはトリプルライセンスになっている場合、それは、そのコードを変更または配布する者（実施権者 【訳注：licensee】）が効力をもつ複数のライセンスから組み合わせを選択できるということを意味します。

mozilla.org は、新しいソースファイルへの挿入用に 前もって準備されたライセンス定型文 と、空欄をどのように埋めるのかの記入例 を作成しました。

（これに関連して、新しい Mozilla ソースファイルを作成している多くの開発者が、馴染みのある他のファイルからライセンスヘッダを単にカット・アンド・ペーストしていることに、私たちは気づきました。こういうことをすると、開発者みずからが、新しいファイルに対して間違ったライセンスを用いて、不適切なかたちでライセンス付与をすることになり得ます。mozilla.org がホストするリポジトリに新しい Mozilla ソースファイルを追加する場合は、適切なライセンス告知が付与されているかを必ず確認してください。）

私たちは、mozilla.org を通じて頒布される Mozilla ソースコードディストリビューションに含まれ、また、mozilla.org を通じて頒布される Mozilla バイナリーディストリビューションを作成するのに使用される、全てのソースコードに再ライセンスを付与することを目指しています。私たちは、必ずしも、mozilla.org の CVS リポジトリーから利用できる全てのソースコードを再ライセンスしようとしているのではありません。

私たちの第一の目標は、Mozilla バイナリーディストリビューションをビルドするのに必要なソースコードが、適切な（単体または複数の）ライセンス下に置くことです。そのため、私たちは、mozilla.org を通じてリリースされる、Mozilla ソースコードディストリビューションに含まれるソースコードの再ライセンスに焦点を合わせています。（このようなディストリビューションの例は、1.5 マイルストーンからのソース tarball）

特に、次の（mozilla のトップレベルディレクトリの下にある）全ての Mozilla ソースディレクトリには、必要な時に再ライセンスしようと我々が考えている、ソースファイルが含まれています：

accessible
build
calendar                                                                        
caps
config
content
db
dbm
directory
docshell
dom
editor
embedding
expat
extensions
gc
gfx
gfx2
htmPLarser
include
intl
ipc
jpeg
js
l10n
layout
lib
mailnews
modules
netwerk
nsprpub
plugin
profile
rdf
security
sun-java
themes
tools
uriloader
view
webshell
widget
xpcom
xpfe
xpinstall

（これらのディレクトリにある全てのファイルが、必ずしも再ライセンスされるとは限らないことに注意して下さい。下の質問をご覧下さい。）

現在のところ、mozilla.org を通じて頒布され、しかし、Mozilla 自体の現在のバージョン内には含まれていない、その他のソースコードを再ライセンスすることは目指して いません。これには、 Bugzilla、 Bonsai、 Tinderbox、 Grendel、 ElectricalFire、 Rhino そして "Mozilla Classic"（1998年にリリースされた、オリジナルの Netscape Communicator ソースコード）のソースコードが含まれます。このソースコードは、現在のところ、既存のライセンス下に置かれます。

Mozilla ソースファイルの多くは、過去に NPL 下でリリースされています（中には NPL/GPL デュアルライセンス下でリリースされているソースファイルもあります）。Mozilla Foundation の創設以来、mozilla.org は NPL のセクション V.3 下で定められている Netscape の権利（「代替ライセンス」【訳注：Alternative Licensing】）を受け継ぎ、NPL が付与されたコードをそのコードが指定するライセンスへと再ライセンスしてきました。mozilla.org はこうしたコードを、コードベース全体が移行を目指している MPL/LGPL/GPL トリプルライセンスへと再ライセンスする権利を選択的に行使しています。そのため、NPL が付与されたコードを除去してもいます。さらに、'SpiderMonkey' C JavaScript エンジン全体（mozilla/js/src）、ならびに Netscape Directory SDK for C（mozilla/directory/c-sdk）が既に再ライセンスされています。

除外 されておらず、MPL トリプルライセンスヘッダを持たないすべての Mozilla コードベース内のソースファイル。:-)

私たちは、2001年 9月 19日の新しいライセンスポリシー発表に至るまでの間に Mozilla にコードを貢献したほぼすべての人からから再ライセンスする許可を求め取得してきました。（2001年 9月 19日以降のコードの貢献は、その時点でコードがトリプルライセンスのファイルとしてチェックインされない場合、再ライセンスの許可を与えることが条件となっていました。）関係するすべての個人、企業そして組織から許可を得られ次第、すべての著作権保有者から許可を受けたこれらのファイルを再ライセンスする予定です。

はい。GPL や LGPL と既に互換性をもつその他のライセンス（つまり、NPL、MPL でもなく、また MPL、NPL ベースのデュアルあるいはトリプルライセンスでもないライセンス）下にある、ある特定の提供されたソースファイルは、そうです。

既存の Mozilla ソースファイルの中には、（改変された）BSD License 【英文】、MIT License 【英文】、あるいは同様のライセンス下にあるものがあります。そのようなソースファイルの例としては、JPEG ライブラリコードがあります。私たちには、そのようなライセンス下にあるコードの再ライセンスを目指す理由がありません。なぜなら、問題のライセンス条項は、既に MPL、GPL、LGPL の全てと互換性がありますし、プロプライエタリソフトウェアへのコードの組み込みも、（Mozilla ライセンス協定に基づいて）許可しているからです。

そのような他のライセンス下にあるコードを含む Mozilla ソースディレクトリ（mozilla トップレベルディレクトリの下）には、次のものがあります（ただし、必ずしもこれだけに限りません）：

dbm
expat
gc/boehm
jpeg
modules/libimg/png
modules/zlib
xpcom/typelib/xpidl/
other-licenses/

Mozilla ビルド手続きの一部として追加された makefile を除いて（これらは新しいライセンス・スキームを使用してライセンスされます）、これらディレクトリ内の全てのファイルは、オリジナルのライセンス下におかれたままにしておかなければなりません。

「other-licenses」ディレクトリの目的は、次のようなものです。Mozilla 開発者は、既に存在するプロジェクトからの外部ライブラリを利用して、Mozilla（例：SVG のための libart）を拡張するように求めることができます。当該開発者は、ビルドに必要な条件を満たすために、そうした既存のコードを mozilla.org にホストするように求めることができます。この措置は、開発者やユーザに対して各システム上で必要な条件を求めることを避ける目的です。

この場合、mozilla.org は、例えば LGPL 下のみでそのようなコードを受け入れます。ここでの当該コードは、LGPL で定められるようにその他の非 LGPL コードと共にライブラリを形成しますが、当該コードは「other-licenses」ディレクトリに保存されなければなりません。そのようなチェックインは、事前に mozilla.org からの承認を得なければなりません。

Netscape の社員によって作成されたそのようなファイルは、どれも NPL 下に置かれるものとされ、自動的に再ライセンスされます。一方、その他のファイルに関しては、そのファイルの提供者に連絡を取り、再ライセンスの許可を要請します。

Mozilla ソースファイルの多くは、明示的なライセンス告知（または、この話題に関していえば、明示的な著作権告知）がされていません。そのようなファイルの再ライセンスは、次のように行われます：

問題となるファイルが Netscape の開発者によって作成されたものである場合、私たちは、適用されるライセンスは NPL（ファイルの置かれているソースディレクトリによっては、NPL/GPL デュアルライセンス）だと考え、自動的に MPL/GPL/LGPL トリプルライセンスに再ライセンスされます。

問題となるファイルが Netscape の社員によって作成されたのではない場合、適用されるライセンスは NPL（または NPL/GPL デュアルライセンス）ではないと考え、コードの提供者に連絡を取り、そのファイルの再ライセンスの許可を取ります。

ごく些細な、中身のない、非常に小さい、あるいは自動生成されたファイルは、ライセンスが付与されないままになります。

なぜなら、提供者のコードを NPL 下でライセンスする許可を得ることで、非 Netscape 提供者は、すでに間接的に再ライセンスする許可を与えているからです。

提供者がもともと NPL 下でコードを提供した場合（例えば、既存の NPL 下でライセンスされているソースファイルへのパッチとして提供した場合）、NPL が、Netscape（現在の Mozilla Foundation）に、他のライセンス下で提供されたコードを再ライセンスするという特別な権利を与えていることを、提供者は知っている（または様々な情報源から容易に理解できる）と考えられるからです。いずれにしろ、コードを提供することを選択することで、提供者は、彼らのコードがこのような方法で再ライセンスされることを、間接的に許可しているのです。なぜなら、NPL 下でコードを提供する許可をすることで、MPL/GPL/LGPL トリプルライセンス下で再ライセンスする許可を得るための時間や労力の浪費を防ぐという観点から、既に（間接的に）任意の再ライセンスを認めているからです。

こうすることで、提供者に対して公平でいられると、私たちは信じています。なぜなら、新しいライセンス・スキームは、以前のライセンス下で認められてきたものと同等の権利を保証しているからです。

なぜなら、そのような許可を与えるということは、あなたが MPL（または MPL/GPL）下でコードをライセンスする許可を与えた趣旨と一致するものだからです。またそうすることで、Mozilla コードをより多くの人々に利用してもらうことができ、結果的に Mozilla を他の人が改良することで、あなたにとっても利用しやすいものとなるからです。

再ライセンスはまた、Mozilla コードをより幅広く配布する際の助けとなります。Mozilla コードが幅広く行き渡ることで、ウェブにおけるウェブ標準の採用に良い影響を及ぼし、プロジェクトの長期的な健全性に繋がるのです。

Mozilla コードに使用されているライセンス・スキームは、常に二つの特徴からなっています：ソースコードを Mozilla コードへの変更をしやすくするよう求めていること、そして Mozilla コードを他のプロプライエタリコードと組み合わせて、プロプライエタリ製品を作成し、頒布することを認めていることです。"標準" のライセンス（NPL や MPL を何らかのかたちで使用しているライセンス）下で Mozilla プロジェクトにコードを提供している人は誰でも、結果的に、こうした一般的な条項の許に彼らのコードを頒布することを認めているのです。

新しい Mozilla のライセンス・スキーム（MPL/GPL/LGPL トリプルライセンス）は、それまでの体系との互換性を保っています：新しい Mozilla ライセンス・スキームも、誰もが Mozilla コードへの変更をできるよう、ソースコードを利用可能にするよう求めていますし（これは、MPL、GPL、または LGPL 条項下のコードでライセンスを使用するように求められています）、Mozilla コードをプロプライエタリプログラムに使用することも認めています（これは MPL によって認められており、場合によっては LGPL によっても認められています）。そのため、こうした観点から、新しいライセンス・スキームは、あなたが提供したコードを使用する許可を既に与えているため、先のライセンス・スキームと互換性があるのです。また、あなたのコードに MPL/GPL/LGPL トリプルライセンスを使用する許可を与えることで、先のあなたの許可との互換性を保てるのです。

あなたのコードを再ライセンスする許可をすることで、あなたは、より幅広いユーザーや開発者のコミュニティに、Mozilla コードを利用可能にする手助けをすることにもなるのです。その結果、Mozilla により多くの改善がなされるかもしれませんし、より多くの Mozilla ベースのアプリケーションが作成されるかもしれません。こうした改善や新しいアプリケーションの出現は、将来的には、あなたにも利益をもたらすかもしれません。

relicensing@mozilla.org にメールを送って下さい。

私たちは、MPL または MPL/GPL デュアルライセンス下で Mozilla ファイルにコードを提供した（非 Netscape）提供者のリストを作成しており、彼らのコードを MPL/GPL/LGPL トリプルライセンス下に再ライセンスする許可を要請しています。もしあなたがそのようなコードを提供したことがあり、このような方法で、あなたの全てのコードを再ライセンスしても良いという全面的な許可を与えて下さる場合には、どうぞ relicensing@mozilla.org にメールを送って、あなたが提供したコード全てを MPL/GPL/LGPL トリプルライセンス下で再ライセンスするという許可を宣言して下さい。

私たちは、他の提供者が代わりのコードを MPL/GPL/LGPL トリプルライセンスで提供してくれるまで、そして提供してくれない限り、そのようなコードも Mozilla ソースコードの中に含めます。

前で論じたように、Mozilla ソースファイルが現時点で MPL（または MPL に基づいたデュアルライセンス）で頒布されている場合で、もしそのようなファイルに Netscape によって著作権が保護されていない提供コードが含まれていたとしたら、そのコードの著作権保持者に、ライセンスを変更するための許可を求めなければなりません。その間も、そのようなファイルは mozilla.org を通じて頒布され、既存のライセンス下で使用し続けることができます。

私たちの最終的な目標は、mozilla.org を通じて頒布される全ての Mozilla ソースファイルを、MPL/GPL/LGPL トリプルライセンス下（または、前述 のような、その他の適切なライセンス）に再ライセンスすることです。Mozilla ソースコードには、コードの著作権保持者が MPL/GPL/LGPL トリプルライセンス下に再ライセンスすることを拒否するようなコードが含まれることがあるかもしれません。そのような場合には、私たちは、誰かが新しいコードを書いて、再ライセンスできないコードと置き換えることができるかを、調査します。（この作業によって、全く新しいソースファイルを書かなければならなくなるかもしれませんし、既存のファイルの一部を変更するだけで済むかもしれません。）

そのようなファイルが現在のライセンス下に残っている場合は、二つの結果が考えられます：一つは、問題となるファイルが、現時点で MPL（のみ）下でライセンスされている場合。このような場合、そうしたファイル中のコードは、開発者によって、MPL またはプロプライエタリライセンス下で Mozilla ベースの製品で作成され、頒布されることで使用される可能性があります。ただし、開発者が LGPL または GPL 下でソフトウェアを作成し、頒布することで使用されることはありません。もう一つは、もし問題のファイルが、現時点で MPL/GPL デュアルライセンス下にライセンスされている場合。この場合、そのファイルの中のコードは、MPL、GPL、またはプロプライエタリライセンスの下で、開発者によって Mozilla ベースの製品が作成され頒布される可能性があります。ただし、開発者によって LGPL 下でソフトウェアを作成し頒布するのには使用されることはありません。

なぜなら、MPL/GPL デュアルライセンスでは、開発者が LGPL 下で頒布された Mozilla コードの中のライブラリを使用することができないからです。

ある人たちは、GPL 下でライセンスされた他のコードがあるプログラムの中で、Mozilla コードを含めることができるようにしたいと思い、その派生した成果を GPL 条項および条件下で（GPL で定められたように）頒布したいと考えるかもしれません。また別の人たちは、Mozilla コードをライブラリに組み込みたいと考えたり、別のコードが LGPL 下にある別の成果に組み込みたいと考え、派生した成果を LGPL 条項および条件下で頒布したいと考えるかもしれません。

そこから私たちの問題が発生しました：どちらの可能性をも可能にするためには、どのような Mozilla ライセンスがあるのだろう？　各方面からの意見を参考にして、私達は、以前に提唱した MPL/GPL デュアルライセンス・スキームが、十分ではないという結論に達したのです。もし誰かが、そのようなデュアルライセンスされた Mozilla コードをプロプライエタリコードと組み合わせた場合（そのコードが LGPL 下でライセンスされていた場合）で、Mozilla コードのために MPL ライセンスオプションを使用した場合、MPL 下のコードと GPL 下のコードを組み合わせたときと同様の問題が発生してしまいます。その一方、そのような Mozilla コードをプロプライエタリコードと組み合わせて、MPL/GPL デュアルライセンス下の Mozilla コードのために提供された GPL ライセンスオプションを使用した場合、派生した成果を LGPL 条項の許ではなく、GPL 条項の許で頒布しなければならなくなります。

対象となる人たちが、何らかの理由によって（GPL ではなく）LGPL を使用することにした場合、Mozilla ライセンス・スキームを変更したほうが良いだろうと考えられます。そうすれば、Mozilla コードを組み込むことができ、しかも派生した成果に対しては LGPL を適用することができるからです。こうしたことができる方法は他にもあるとはいえ、MPL/GPL/LGPL トリプルライセンスを使用することが、最も分かりやすいアプローチだと考えたのです。なぜなら、これならば、Mozilla コードを（トリプルライセンスの一部としての LGPL の定めるところとして）LGPL 条項および条件下で頒布することができますし、同時に、Mozilla コードを使用したソフトウェアを（トリプルライセンスの一部としての GPL の定めるところとして）GPL 条項および条件下でも頒布することができるからです。

Mozilla プロジェクトの目標は、FSF の目標とは異なります。私たちは、新しいトリプルライセンスで LGPL を使用することで、LGPL を使用に従う（または固執する）開発者の利益になると信じています。また一方では、ソフトウェアユーザと、自分たちのソフトウェアに GPL を使用する開発者たちにとって重要な、自由を保障することにもなるのです。

Free Software Foundation の目標は、フリーのソフトウェアの作成を奨励することと、（フリーではない）プロプライエタリソフトウェアの作成を阻止することです。そのため、FSF は、（フリーソフトウェアのライブラリをプロプライエタリソフトウェアに組み込むことを可能にしている）LGPL の使用を避けるように勧告していますし、全てのソフトウェアを GPL 下でライセンスするように奨励しています。それによって、あらゆるソフトウェアの派生成果もまた、同じ GPL の条項下にライセンスされるようになるからです。しかし、Mozilla ライセンス・スキームの目指すところは、（もし望めば）Mozilla コードをその他の（非 Mozilla コード）と組み合わせて、Mozilla コードそのものに適用されるライセンス条項とは異なるライセンス条項下で頒布できるような、"より大きな成果" を創り出すことを、可能にすることなのです。

そのため例えば、mozilla.org を通じて頒布される Mozilla コードは、他のコードと組み合わせて、プロプライエタリライセンス条項下で頒布できる、より大きな成果を作成することが現在できますし、将来もできます。Mozilla ライセンス・スキームを変更した際のもともとの意図は、Mozilla コードをその他のコードと組み合わせて、GPL 条項下でも頒布できる、より大きな成果を作成できるようにすることでした。私たちは、あらゆる新しい Mozilla ライセンス・スキームもまた、Mozilla コードと他のコードを組み合わせて、LGPL 条項下で頒布できる、より大きな成果を作成できるようにすることにあります。私たちは、そうして出来上がったより大きな成果が、プロプライエタリライセンス、または GPL 条項下のどちらかで頒布されることを正当化できませんし、同時に、そうしたより大きな成果が LGPL 条項下で頒布されることを阻止することも正当化できません。

実際に MPL または NPL 下にある Mozilla コードが、既に LGPL 下のコードと組み合わされて、その結果できるより大きな成果が LGPL 条項下で頒布される場合は、全く問題ありません。もしそのような事例があれば、私たちは新しい Mozilla 方式の中で LGPL のための特別条項を作る必要はありません。しかし、私たちが LGPL を理解するところでは、もし MPL が（FSF が主張するように）GPL と互換性がないならば、MPL は LGPL とも互換性がないことになってしまいます。そのため私たちは、新しい Mozilla ライセンス・スキームが、GPL と共に LGPL に対応しなければならないという結論に達したのです。

ユーザーに対して認められている自由という点では、MPL/GPL/LGPL トリプルライセンス・スキームは、当初考慮されて後に破棄された、MPL/GPL デュアルライセンス・スキームと互換性があります。もともとの MPL/GPL の案のように、提案された MPL/GPL/LGPL トリプルライセンス・スキームでは、ライセンス取得者が望めば、非プロプライエタリな派生成果を、GPL のみのライセンス下で作成することができます（例えば、そのような成果をプロプライエタリな成果や、またはフリーではないソフトウェアとの組み合わせで使用することを阻止することです）。MPL/GPL/LGPL ライセンスではまた、もしライセンス取得者が望めば、非プロプライエタリな派生成果を、LGPL のみのライセンスで作成することができます。

ライセンス取得者が、 GPL のみ（または LGPL のみ）の Mozilla コードベースのバージョンを作成する自由があるとはいえ、mozilla.org は、LGPL または GPL 下にある他のコードと mozilla コードと共に使用するライセンス取得者が、 MPL/GPL/LGPL トリプルライセンス条文に従うこと、そして GPL または LGPL 条項下と共に、MPL 条項下でライセンス取得者が作成した Mozilla コードの使用を認めることを求めています。同様に mozilla.org は、ライセンス取得者が、Mozilla コードを MPL（または、GPL または LGPL 以外の他のライセンス）下のコードと使用する際、元の MPL/GPL/LGPL トリプルライセンスの条文を保持すること、そして MPL 下と共に GPL または LGPL 条項下でライセンス取得者が作成した Mozilla コードを使用できるようにすることを求めています。

私たちがこうしたことを求めるのは、Mozilla のコードベースが、誰もが利用できる、共有の資源としてあるべきだと信じるからです。そして、人々が全ての人の利益のために、この共有されたコードベースを後押しして欲しいのです。この目標を達成するために、私たちは、新しいソースファイルが MPL/GPL/LGPL トリプルライセンス条項下にない限り、そのファイルを mozilla.org がホストする Mozilla ソースコードリポジトリに受け入れることは基本的にありません。

MPL/LGPL デュアルライセンスを使用することで、GPL 条項の許で Mozilla コードを頒布したいと考えている人々に不必要な不便をかけてしまいます。事例によっては、人々に Mozilla ソースファイル上のライセンス告知の変更を要求することになるからです。MPL/GPL/LGPL トリプルライセンスでは、こうした潜在的な不便さを減らすことができます。

ライセンス・スキームの一つの可能性としては、MPL または LGPL のどちら下の条項と条件のもとに Mozilla コードを認めるという、デュアルライセンスでした。言い換えると、GPL を明示的に代替ライセンスとしては含まず、LGPL によって可能となる GPL 条項の許で使用するというものです。しかし、問題を検討した結果、私たちは、このアプローチが、Mozilla コードを GPL 条項の許で頒布しようとする人々に、不必要な不便を引き起こすことになるという結論に達しました。

例えば、MPL/LGPL デュアルライセンス下にある Mozilla ソースファイルを考えてみましょう。このデュアルライセンスでは、MPL 条項かまたは LGPL 条項の許でコードを使用できるよう許可しています。そして、ある開発者がアプリケーションを開発したいと考えました。そのアプリケーションでは、Mozilla ソースファイル内のルーチンが、GPL 条項下にある別のソースファイル内のルーチンを呼び出します。そのようなアプリケーションは、全体として GPL 条項の許で頒布されなければなりません。そのため、その開発者は、そのアプリケーション全体の一部分としての Mozilla コードを、GPL 条項の許で頒布する許可を得なければなりません。

MPL/LGPL デュアルライセンスの許であれば、その開発者は、そのコードを GPL 条項の許で頒布するための明示的な許可を必要とはしません。明示的な許可が必要な場合は、LGPL 条項の許でコードを頒布する際のみのこととなります。そのため、その開発者は、デュアルライセンスの LGPL 部分を利用しようと考えるでしょうし、GPL 条項の許での（再）頒布を許可している LGPL 内の条項を有効利用することができます。

LGPL が GPL 条項の許で頒布を認めるのは、二つの場合があります。一つは、LGPL の第 6 節を利用するものです。この節は、LGPL 条項下で頒布された "ライブラリ" を、非 LGPL 条項の許で、ライセンス条項が成果全体への変更を認め、必要な条件を満たしている場合には、"ライブラリ" を "ライブラリを使用する成果" の全てまたは一部分として、（再）頒布することを認めています。GPL が問題の条件を満たしていることから、この条項によって、仮定的な MPL/LGPL デュアルライセンスの許、Mozilla コードで構成されるライブラリを、GPL 条項下のコードからなるアプリケーションと共に頒布することができることになります。そのデュアルライセンスによって、Mozilla コードが LGPL 条項の許で頒布できるようになり、LGPL の第 6 節は、GPL 条項の許で成果全体を頒布することを可能にしているのです。

しかしこれは、私たちの例には当てはまりません。なぜなら、Mozilla コードは、LGPL が定義するような "ライブラリ" として利用されているのではないからです。そうではなく、Mozilla ソースファイルの中のルーチンは、GPL 下でライセンスされた、（それらルーチンによって呼び出される側とは反対の）ソースファイル内で呼び出す側のルーチンなのです。そのため、私たちの例の中の開発者は、LGPL の第 6 節を利用できないため、GPL 下で頒布を認めた LGPL の他の条項を使用しなければなりません。それは、第 3 節です。LGPL の第 3 節は、明示的に LGPL 条項下で頒布されたコードを、替わりに GPL の条項下で（再）頒布することを認めています。しかし、これを行うためには、開発者は、Mozilla ソースファイル内のライセンス告知を実際に変更して、GPL ライセンス告知に置き換えなければなりません。

仮定的な MPL/LGPL デュアルライセンスの条項は、この切り替えを認めていますが、私たちの例の中の開発者が切り替えを行うのは不便です。特に問題の Mozilla コードが、単一のソースファイルから成っておらず、何十も、何百も、時には何千ものソースファイルから成り立っている場合には。そしてこの不便さは、不必要なものでもあります。つまり、Mozilla ソースファイルが、GPL 条項下のコードの使用を明示的に認めている場合、ライセンス告知を変える必要は全くなくなるのです。

そのため私たちは、（NPL 下の既存のコードのための NPL/GPL/LGPL トリプルライセンスと組み合わせるかたちで）MPL/GPL/LGPL トリプルライセンスを利用するというアプローチを取ることにしたのです。このライセンス・スキームは、（MPL および LGPL 条項と共に）GPL 条項下で利用するために、明示的に提供されたもので、前述のようにライセンス告知を変更する必要はありません。

MPL そのものを変更するというのは、時間と労力を必要とします。それに Mozilla プロジェクトは（他のプロジェクトと同様）、複合ライセンス・スキームを、深刻な問題もなく既に使用しています。

トリプルライセンスを使用するのではなく、別のアプローチがあるとすれば、明示的に GPL（そして LGPL）との互換性問題を取り扱う条文を含む、MPL の新しい版を作成することでしょう。（FSF は以前、そのようなアプローチを、NPL と GPL との非互換性問題に言及する一つの方法として提案していました。）しかし、この問題を検討した結果、私たちは、MPL を変更することは、時間を浪費し、潜在的に問題を引き起こしやすくなるだろう、という結論に達しました。

MPL を変更することで、Mozilla プロジェクトとは独立した立場から、自分たちのコードを使用するために MPL を採用している開発者にも影響を与える可能性もあります。そのような開発者たちが新しい MPL の変更に納得できない場合、明示的に MPL の古いバージョンを使用せざるを得なくなりますし、彼ら独自の MPL ベースのライセンスを作成せざるを得なくなります。（または、開発者がそうした作業をしなくても良いように、開発者が条文を取り入れるかどうかを指定できるように、MPL 内の条文をオプショナルにしなければなりません。）最後に、MPL を変更することは、Open Source Definition 【英文、日本語版】 との関連から、証明のために Open Source Initiative 【英文】 に変更したライセンスを再提出しなければなりません。これはまた時間の浪費につながります。

そのため私たちは、より良い方法とは、単純にトリプルライセンスを使用することだ、という結論に達しました。このアプローチは、以前 Mozilla コードに使用していたデュアルライセンスアプローチからの自然な形での拡張で、特に深刻な問題もなく他のプロジェクトでも使用されています。既にオープンソースおよびフリーソフトウェア開発者にとって馴染み深いライセンス（MPL version 1.1、GPL version 2、および LGPL version 2.1）を使用することにつながり、他の新しく異なるライセンスの導入が必要なくなります。

歴史的に見て、Mozilla コードは常に何らかのかたちの copyleft ライセンスの許でリリースされてきました。そして私たちは、Mozilla コードへの変更を共有するように働きかける copyleft 条項を使用し続けたいと考えています。

NPL や MPL を作成した背景にある動機の一つは、Mozilla コードを使用する全ての当事者間で、変更の共有を奨励することでした。BSD license 【英文】 や MIT license 【英文】、または同様の非 copyleft ライセンスを使用することを検討したこともありましたが、最終的に NPL/MPL copyleft 機構を採用することにしたのです。オリジナルの Netscape Public License FAQ から引用すると：

Netscape の見解によると、BSD ライセンスでは、開発者が Communicator ソースコードへの彼らの変更を、コミュニティに還元することを、確実なものにはできません。我が社は、ソース開発努力の長期的な有効性を確実にすることが重要だと考えているのです。

私たちは、この目標は推進する価値があると信じます。そのため、私たちは、copyleft 条項の使用をそのまま保持することにしたのです。つまり、新しい MPL/GPL/LGPL トリプルライセンスの許で、Mozilla コードのために三つのライセンスオプションが利用可能となり、全てのライセンスオプションには copyleft の特徴が（異なる長所をもって）備わっており、Mozilla コードを使用した製品を頒布する再に、Mozilla コードが頒布できるように変更することが求められています。

全く影響はありません。Mozilla コードを取り入れてプロプライエタリソフトウェアを作成し頒布している開発者は、MPL 条項および条件の許で、そのまま活動ができます。彼らが今までずっと行ってきた通りのままです。

MPL はもともと、MPL 条項下で頒布されているソースファイルをその他のライセンス下のソースファイルと組み合わせて頒布できるようにし、その結果できる成果を非 MPL ライセンス下で頒布できるように、デザインされています。（この権利は、MPL が満たされるという要求を満たすことが条件となっています。例えば、作成された成果をユーザー向けに頒布する場合、頒布者はまた、MPL または NPL 下で頒布されたソースコードから作成されたコード部分をも、ユーザに対して利用可能にしなければならないのです。）

MPL のこの特徴で、開発者は、Mozilla コードを組み込んだプロプライエタリ製品を頒布できるのです。（Netscape 7 はそのような製品の一例です。）MPL/GPL/LGPL トリプルライセンス・スキームの許では、開発者は、MPL 条項下の Mozilla コードを使用するオプションを行使し、Mozilla コードを基礎にしたプロプライエタリ製品のそうした部分に対しての MPL の様々な要求を満たすことで、Mozilla ベースのプロプライエタリ製品を作成し、頒布し続けることができるのです。

（理論的には、開発者はまた、もしその Mozilla コードがライブラリ形式であり、その開発者が LGPL の関係する要求に準じていれば、Mozilla ベースのプロプライエタリ製品を LGPL 条項の許で頒布することができます。）

新しいライセンス・スキームが完全に実施された場合、LGPL 下で頒布されるライブラリや関連ソフトウェアを作成している開発者は、LGPL 条項および条件で、そのソフトウェアの中であらゆる Mozilla コードを使用することができるようになります。

全ての Mozilla ソースファイルが MPL/GPL/LGPL トリプルライセンス（またはその他の互換性のあるライセンス）下で再ライセンスされた場合、開発者は、Mozilla ソースファイルを LGPL 条項下で使用するオプションを利用することで、また Mozilla ソースファイルからのコードを基礎にしたソフトウェアのそうした部分に対しての LGPL の様々な要求に準じることで、Mozilla ベースのライブラリーや関連するソフトウェアを LGPL 下で頒布することが可能となります。

MPL/GPL/LGPL トリプルライセンスの許では、開発者はまた、既存のソースファイルにある LGPL ライセンス告知を変更することなく、Mozilla コードの一部分を取り出して、既に LGPL 下にある既存のソースファイルの中で使用することもできます。（これが可能なのは、トリプルライセンスの鋳型条文が、告知の MPL 部分を削除し、LGPL 告知の部分のみを使用することを認めているからです。）

全ての Mozilla ソースファイルが MPL/GPL/LGPL トリプルライセンス下に再ライセンスされなくても、LGPL の許でライブラリを頒布している開発者は、MPL/GPL/LGPL トリプルライセンスの許で既に再ライセンスされている、あらゆる Mozilla ソースファイルを使用することができることを覚えておいて下さい。

新しいライセンス体系が完全に実施された場合、GPL の許で頒布されるソフトウェアを作成している開発者は、そのソフトウェアの中で GPL 条項および条件下で、あらゆる Mozilla コードを使用することができます。

全ての Mozilla ソースファイルが MPL/GPL/LGPL トリプルライセンス（またはその他の互換性のあるライセンス）の許で再ライセンスされた場合、開発者は、GPL 条項の許で Mozilla ソースファイルを使用するオプションを利用することで、GPL 下で Mozilla ベースのソフトウェアを作成し、頒布することができます。これにより、開発者は、成果全体を GPL 条項の許で頒布することができるようになり、同時に、Mozilla ソースファイルからのコードに基づいたソフトウェアのそうした部分のための GPL が定める要求に応えることができるのです。

MPL/GPL/LGPL トリプルライセンスの許では、開発者はまた、ソースファイル内の既存の GPL ライセンス告知を変更することなく、Mozilla コードの部分を抜き出し、それらを既存の GPL 下のソースファイルに使用することができます。（これは、トリプルライセンスの鋳型条文が、告知の MPL 部分を削除し、GPL に関連する告知で代用することを認めているために、可能となることです。）

あなたが Mozilla コードの一部を GPL 条項下で頒布したい場合、全体の再ライセンスプロジェクトが完了していなくても、頒布できることを覚えておいて下さい。再ライセンスは段階的に行われるため、あなたが使用したいと思う特定のファイルを確認することを忘れないで下さい。なぜなら、そうしたファイルは、既に MPL/GPL/LGPL トリプルライセンス下にあるかもしれませんし、かつて使われていた MPL/GPL または NPL/GPL デュアルライセンスの許に置かれているかもしれないからです。