Some time ago mozilla.org announced its intent to seek relicensing of Mozilla code under a new licensing scheme that would address perceived incompatibilities of the Mozilla Public License (MPL) with the GNU General Public License (GPL) and GNU Lesser General Public License (LGPL).
We are now implementing Mozilla relicensing using an MPL/GPL/LGPL triple license. This FAQ addresses various questions that might arise specifically about this relicensing effort. For additional information about the new Mozilla licensing scheme, see the mozilla.org License Policy.
IMPORTANT: Note that this document is for your information only and is not intended as legal advice. If you wish to develop and distribute software based on Mozilla code, especially software intended for commercial sale or distribution, and you need or want legal advice regarding your rights and obligations with regard to your use of Mozilla code, then you should consult an attorney with expertise in software licensing.
Primarily to address concerns about whether the Mozilla licensing scheme is "compatible" with the GPL and LGPL.
After the NPL and MPL were created, the Free Software Foundation stated that the NPL and MPL were "incompatible" with the GPL. "Incompatibility" in this context means that (in the opinion of the FSF) developers who combined code licensed under the NPL or MPL with code licensed under the GPL and distributed the resulting work could not do such distribution without violating the terms of the GPL. Given that the LGPL contains similar language to the GPL, if the MPL were in fact incompatible in this way with the GPL, it would arguably be incompatible with the LGPL as well.
(The LGPL allows code released under LGPL terms to be combined in certain specified ways with code released under non-LGPL terms, as for example when releasing an application using a library consisting of code released under the LGPL. However the relevant LGPL provisions do not address all possible ways in which code released under the MPL and code released under the LGPL could be combined to form a larger work. In particular, when linking Mozilla source files directly into a library released under the LGPL, e.g., to extend the functionality of that library, the effect of the LGPL terms, and any potential license incompatibilities that might arise, appear to be similar to those associated with the GPL.)
It is unclear whether a developer could be successfully sued for copyright infringement on grounds related to these perceived license incompatibilities. However, to eliminate possible uncertainties concerning this question, and to address the concerns of developers who wished to use Mozilla code in applications whose code was otherwise licensed under the GPL or LGPL, we decided to seek relicensing of the Mozilla code to address the perceived license incompatibilities for both the GPL and the LGPL.
The new standard licensing scheme is an MPL/GPL/LGPL triple license; it should be used for all new Mozilla source files distributed through mozilla.org, and existing files will be changed to it after obtaining the necessary permissions.
The MPL/GPL/LGPL triple license is an extension and variant of the dual license schemes which have been used in the past with Mozilla code, including NSPR, NSS, PSM, and the JavaScript engine. The principal differences are that we are using the LGPL as an alternate license in the triple license scheme, in addition to the GPL.
If a piece of code is dual- or triple-licensed, that means that someone (the licensee) who modifies and/or distributes it can choose which of the available sets of license terms they are operating under.
mozilla.org has produced pre-prepared license boilerplate for inserting into new source files, and also an example of how to fill in the blank fields.
(In this connection, it has come to our attention that many developers creating new Mozilla source files simply cut and paste a license header from another file with which they are familiar; in doing this developers have sometimes improperly licensed new files under the wrong license(s). When and if you add new Mozilla source files to the mozilla.org-hosted repository, please verify that the appropriate license notice is present.)
We will seek to relicense all source code which is included in the Mozilla source code distributions distributed through mozilla.org and is used to create the Mozilla binary distributions distributed through mozilla.org. We will not necessarily relicense all source code available from the mozilla.org CVS repository.
Our primary goal is to ensure that the source code needed to build Mozilla binary distributions is available under a suitable license (or licenses). Thus we will focus on relicensing source code which is included in Mozilla source code distributions released through mozilla.org. (An example of such a distribution is the source tarball for the 1.5 milestone.)
In particular, all of the following Mozilla source directories
(under the mozilla top-level directory) contain
some source files which we will seek to relicense where necessary:
accessible build calendar caps config content db dbm directory docshell dom editor embedding expat extensions gc gfx gfx2 htmlparser 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
(Note that not all files in these directories will necessarily be relicensed; see the question below.)
At this time we will not seek to relicense other source code which is distributed through mozilla.org but is not included in current versions of Mozilla itself. This includes source code for Bugzilla, Bonsai, Tinderbox, Grendel, ElectricalFire, Rhino and "Mozilla Classic" (i.e., the original Netscape Communicator source code released in 1998); this source code will remain under its existing license(s) for now.
Many Mozilla source files previously released under the NPL (along with some source files released under an NPL/GPL dual license). Since the creation of the Mozilla Foundation, mozilla.org has inherited Netscape's right under Section V.3 of the NPL ("Alternative Licensing") to relicense NPLed code under a license of its choice. It is choosing to exercise that right to relicense such code under the MPL/LGPL/GPL triple license that the entire codebase is moving towards, thereby eliminating NPLed code from the tree. In addition, the whole of the 'SpiderMonkey' C JavaScript engine (mozilla/js/src), and the Netscape Directory SDK for C (mozilla/directory/c-sdk) have been relicensed.
Any source file in the Mozilla codebase that is not excluded, and that does not have an MPL tri-license header :-).
We have sought and obtained permission to relicense from almost everyone who contributed code to Mozilla up until the date of the new licensing policy on September 19th 2001. (After that date, contribution of code was contingent on giving permission to relicense, if the code was not immediately checked into a tri-licensed file.) Once we have obtained responses from all the individuals, companies and organisations concerned, we will relicense those files for which we have received permission from all copyright holders.Yes, for certain contributed source files that are under other licenses (i.e., neither the NPL, MPL, nor NPL- or MPL-based dual or triple licenses) that are already compatible with the GPL and LGPL.
Some existing Mozilla source files are licensed under licenses based on the (modified) BSD license, the MIT license, or similar licenses; examples of such source files include the JPEG library code. We do not see any reason to seek relicensing of code under such licenses, since the terms of the licenses in question are already compatible with all of the MPL, GPL, and LGPL, and also allow inclusion of the code into proprietary software (in accordance with the intent of the Mozilla licensing arrangements).
Mozilla source directories (under the mozilla top-level
directory) containing code under such other licenses
include (but are not necessarily limited to) the following:
dbm expat gc/boehm jpeg modules/libimg/png modules/zlib xpcom/typelib/xpidl/ other-licenses/
Except for makefiles added as part of the Mozilla build procedures (which will be licensed using the new licensing scheme) all files in these directories should remain under their original licenses.
The purpose of the "other-licenses" directory is as follows. A Mozilla developer may wish to use an external library from an established project to extend Mozilla, e.g. libart for SVG. That developer may wish mozilla.org to host such pre-existing code to satisfy that build prerequisite, so avoiding requiring developers and users to satisfy that prerequisite on their own systems.
In this case, mozilla.org may accept such code under e.g. the LGPL only, where that code forms a library that may be used with other non-LGPL code as described in the LGPL, but requires such code to be stored the "other-licenses" directory. mozilla.org must approve any such checkin before it happens.
Any such files created by Netscape employees will be assumed to be under the NPL and thus relicensed automatically, while for other files the contributor(s) will be contacted to request permission for relicensing.
Many Mozilla source files do not have an explicit license notice (or an explicit copyright notice, for that matter). Relicensing for such files will be done as follows:
If the file in question was originally created by a Netscape developer, then we will assume that the intended license was the NPL (or possibly an NPL/GPL dual license, depending on the source directory in which the file is located), and the file will be considered to be automatically relicensed under an MPL/GPL/LGPL triple license.
If the file in question was not created by a Netscape employee, then we will assume that the intended license was not the NPL (or an NPL/GPL dual license), and we will contact the contributor(s) for permission to relicense the file.
Trivial, empty, very short or auto-generated files may be left without a license.
Because by granting permission for their code to be licensed under the NPL non-Netscape contributors already have implicitly given such permission.
When contributors originally contributed code under the NPL (e.g., as a patch to an existing source file licensed under the NPL) they knew (or could have easily discovered by reading various information sources) that the NPL granted special rights to Netscape (and now the Mozilla Foundation) to relicense their contributed code to third parties under other licenses. By choosing to contribute their code anyway, contributors implicitly gave permission for their code to be relicensed in this manner. Because this permission was already (implicitly) granted for any arbitrary relicensing, in the interests of saving time and effort we did not seek to gain permission for relicensing such code under an MPL/GPL/LGPL triple license.
We believe that doing this is arguably fair to contributors, since the new licensing scheme grants rights comparable to those granted under the previous license.
Because granting such permission would arguably be consistent with your having granted permission previously to license your code under the MPL (or MPL/GPL), and because by doing so you will make the Mozilla code useful to more people, which may result in others improving Mozilla to make it more useful to you.
Relicensing also helps win Mozilla code wider distribution, which has beneficial effects on the web's uptake of web standards, and is conducive to the long life and health of the project.
The licensing schemes used for Mozilla code have always had two major features: They have required that people make source code available for modifications to Mozilla code, and they have allowed combining Mozilla code with proprietary code to create and distribute proprietary products. Anyone contributing code to the Mozilla project under the "standard" licenses (i.e., licenses using the NPL or MPL in some form) has in effect consented to their code being distributed under these general terms.
The new Mozilla license scheme (i.e., the MPL/GPL/LGPL triple license) is consistent with the prior schemes: It too requires that people make source code available for modifications to Mozilla code (this is required whether licensees use the code under MPL, GPL, or LGPL terms), and it too allows Mozilla code to be used in proprietary programs (this is allowed by the MPL, and also allowed by the LGPL in certain cases). So in this respect the new licensing scheme is comparable to the prior schemes for which you have already granted permission to use your contributed code, and granting permission to use the MPL/GPL/LGPL triple license for your code would thus be consistent with your prior grant of permission.
By permitting your code to be relicensed, you will also help make the Mozilla code useful to a larger community of users and developers. As a result there may be more improvements made to Mozilla and more Mozilla-based applications created, improvements and new applications which may be of future benefit to you.
Send an email to relicensing@mozilla.org.
We will be creating lists of (non-Netscape) contributors who have contributed code to Mozilla files under the MPL or the MPL/GPL dual license, and asking those contributors to grant permission to relicense their code under the MPL/GPL/LGPL triple license. If you have contributed such code and you wish to go ahead and grant blanket permission to have all your code be relicensed in this way, please send an email message to relicensing@mozilla.org, and state that you are granting permission to relicense all of your contributed code under the MPL/GPL/LGPL triple license.
We will continue to include such code in the Mozilla source code distribution, until and unless we can find another contributor willing to contribute substitute code under the MPL/GPL/LGPL triple license.
As previously discussed, in cases where Mozilla source files are currently distributed under the MPL (or a dual license based on the MPL), if those files contain contributed code not copyright by Netscape then we must seek and obtain the permission of the copyright holders for that code in order to change the licensing. In the meantime those files will continue to be distributed through mozilla.org and can continue to be used under their existing licenses.
Our goal is eventually to have all Mozilla source files distributed through mozilla.org relicensed under the MPL/GPL/LGPL triple license (or other suitable licenses, as previously described). It is possible that there may be Mozilla source files containing contributed code for which the copyright holders refuse to grant permission for relicensing under the MPL/GPL/LGPL triple license. In those cases we will investigate whether the situation can be resolved by someone writing new code to replace the code which cannot be relicensed. (This may require writing a complete new source file, or simply rewriting one or more portions of an existing file.)
If such files remain under their current licenses, then there are two possible outcomes: If one or more of the files in question are currently licensed under the MPL (only), then code in those files may be used by developers creating and distributing Mozilla-based products under the MPL or proprietary licenses, but may not be used by developers creating and distributing software under the LGPL or GPL. If one or more of the files in question are currently licensed under the MPL/GPL dual license, then code in those files may be used by developers creating and distributing Mozilla-based products under the MPL, the GPL, or proprietary licenses, but may not be used by developers creating and distributing software under the LGPL.
Because an MPL/GPL dual license would not allow developers to use Mozilla code in a library distributed under the LGPL.
Some people would like to be able to include Mozilla code in programs where the other code is licensed under the GPL, and then distribute the resulting derived work under GPL terms and conditions (as required by the GPL). Other people would like to be able to include Mozilla code in libraries and other works where the other code is licensed under the LGPL, and then distribute the resulting derived works under LGPL terms and conditions.
Our problem then became, how could Mozilla licensing be arranged in order to make both scenarios possible? After considering public comments we concluded that the previously proposed MPL/GPL dual licensing scheme would not be sufficient. If a person were to combine such dual-licensed Mozilla code with their own code (where that code was licensed under the LGPL) and use the MPL licensing option offered for the Mozilla code, they would arguably encounter the same license incompatibility issues as when combining code under the MPL with code under the GPL. On the other hand, if they were to combine such Mozilla code with their own code and use the GPL licensing option offered for the Mozilla code under an MPL/GPL dual license, then they would have to distribute the resulting work under GPL terms, not LGPL terms.
Since the people in question presumably chose to use the LGPL (and not the GPL) for some reason important to them, it would be preferable to arrange the Mozilla licensing scheme so that they could include Mozilla code and still use the LGPL for the resulting works. While there are several potential ways in which this could be done, we believe that the most straightforward approach is to use an MPL/GPL/LGPL triple license; this will allow the Mozilla code to be used in software distributed under LGPL terms and conditions (as a consequence of the LGPL part of the triple license) and at the same time allow the Mozilla code to also be used in software distributed under GPL terms and conditions (as a consequence of the GPL part of the triple license).
The goals of the Mozilla project are different than those of the FSF. We believe that using the LGPL in the new triple license provides advantages to those developers committed to (or locked into) use of the LGPL, while preserving freedoms important to software users and those developers using the GPL for their own software.
The goals of the Free Software Foundation are to promote the creation of free software and to discourage the creation of proprietary (non-free) software. Thus the FSF now discourages the use of the LGPL (which allows free software libraries to be included in proprietary software) and encourages the licensing of all software under the GPL, so that any derivative works of that software will also be licensed under those same GPL terms. However the intent of the Mozilla licensing arrangements has been and will continue to be to allow Mozilla code to be combined with other (non-Mozilla code) to create "larger works" which could (if desired) be distributed under different license terms than those used for the Mozilla code itself.
Thus, for example, it has always been true, and will continue to be true, that Mozilla code distributed through mozilla.org can be combined with other code to create larger works which can be distributed under proprietary license terms. The original intent behind the changes to the Mozilla licensing scheme was to allow Mozilla code to be combined with other code to create larger works which could be distributed under GPL terms. We believe that any new Mozilla licensing scheme should also allow Mozilla code to be combined with other code to create larger works which can be distributed under LGPL terms. We cannot justify allowing such larger works to be distributed under either proprietary or GPL terms while at the same time preventing such larger works from being distributed under LGPL terms.
There would be no problem if in fact Mozilla code under the MPL or NPL could already be combined with code under the LGPL and the resulting larger work distributed under LGPL terms. If that were the case then we would not have to make any special provision for the LGPL in the new Mozilla scheme. However based on our reading of the LGPL we believe that if the MPL is incompatible with the GPL (as the FSF claims) then it is incompatible with the LGPL as well. Hence we concluded that the new Mozilla licensing scheme must accomodate the LGPL as well as the GPL.
Note that in terms of the freedoms granted to users the MPL/GPL/LGPL triple license scheme is comparable to the MPL/GPL dual license scheme originally considered and then rejected. Like the original MPL/GPL proposal, the proposed MPL/GPL/LGPL triple license scheme allows licensees, if they desire, to create nonproprietary derivative works licensed solely under the GPL (for example, to prevent the use of such works in conjunction with proprietary or otherwise non-free software). The MPL/GPL/LGPL license also allows licensees, if they desire, to create nonproprietary derivative works licensed solely under the LGPL.
Note that although licensees would thus have the freedom to create GPL-only (or LGPL-only) versions of the Mozilla code base, mozilla.org requests that licensees using the Mozilla code with other code under the LGPL or GPL retain the MPL/GPL/LGPL triple license language, and allow use of their versions of the Mozilla code under MPL terms as well as under GPL or LGPL terms. Similarly, mozilla.org requests that licensees using the Mozilla code with code under the MPL (or other licenses other than the GPL or LGPL) also retain the original MPL/GPL/LGPL triple license language, and allow use of their versions of the Mozilla code under GPL or LGPL terms as well as under the MPL.
We are requesting this because we believe that the Mozilla code base should be a common resource available to everyone wishing to use it, and we want to encourage people to add to that common shared code base for the benefit of all. To promote this goal, we will generally not accept new source files into the mozilla.org-hosted Mozilla source code repository unless they are licensed under the MPL/GPL/LGPL triple licensing scheme.
Using an MPL/LGPL dual license would have caused unnecessary inconvenience for people wishing to distribute Mozilla code under GPL terms, by requiring them in some cases to change the license notices on Mozilla source files. An MPL/GPL/LGPL triple license reduces the potential inconvenience.
One possible licensing scheme would have been to use a dual license allowing use of the Mozilla code under the terms and conditions of either the MPL or LGPL; in other words, the GPL would not have been included explicitly as an alternative license, but use under GPL terms would have been possible as specified by the LGPL. However after considering the question we concluded that this approach would cause unnecessary inconvenience for people wishing to distribute Mozilla code under GPL terms.
For example, consider a Mozilla source file licensed under an MPL/LGPL dual license; this dual license permits use of the code under either MPL terms or LGPL terms. Now suppose that a developer wishes to create an application in which routines in the Mozilla source file will be calling routines in a separate source file licensed under the GPL. Such an application would have to be distributed as a whole under GPL terms, so the developer needs permission to distribute the Mozilla code under GPL terms as part of that overall application.
Under an MPL/LGPL dual license the developer in question would not have explicit permission to distribute the code under GPL terms; the explicit permission would extend only to distribution of the code under LGPL terms. Therefore the developer would have to elect to use the LGPL part of the dual license, and then take advantage of any provisions in the LGPL that permit (re)distribution under GPL terms.
There are two ways in which the LGPL permits distribution under GPL terms. One approach is to take advantage of Section 6 of the LGPL, which allows a "Library" distributed under LGPL terms to be (re)distributed under non-LGPL terms as part of a work combining all or part of the "Library" with a "work that uses the Library," if the license terms allow modification of the overall work and meet related criteria. Since the terms of the GPL meet the criteria in question, this provision would allow a library consisting of Mozilla code under the hypothetical MPL/LGPL dual license to be distributed in conjunction with an application consisting of code licensed under the GPL; the dual license would permit the Mozilla code to be distributed under LGPL terms, and Section 6 of the LGPL would permit distribution of the entire work under GPL terms.
But this is not the case in our example, because the Mozilla code is not being used as a "Library" as that term is defined by the LGPL; instead the routines in the Mozilla source file are calling routines in the source file licensed under the GPL (as opposed to being called by those routines). Thus the developer in our example cannot take advantage of Section 6 of the LGPL, but must use another LGPL provision allowing distribution under the GPL, namely Section 3. Section 3 of the LGPL explicitly permits code distributed under the LGPL to be (re)distributed under the terms of the GPL instead. However in order to do this the developer must actually alter the license notice in the Mozilla source file to replace it with a GPL license notice.
The terms of the hypothetical MPL/LGPL dual license permit this alteration, but it would be inconvenient for the developer in our example to do this, especially if the Mozilla code in question consisted not of a single source file but rather of tens, hundreds, or even thousands of source files. And this inconvenience is unnecessary: If the Mozilla source file had been under a license explicitly permitting use of the code under GPL terms then no license notices would need to be altered.
Therefore we took the approach of using an MPL/GPL/LGPL triple license (combined with an NPL/GPL/LGPL triple license for existing code under the NPL). This license scheme explicitly provides for use under GPL terms (as well as under MPL and LGPL terms), without having to change the license notice as described above.
Modifying the MPL itself would have taken more time and effort, and the Mozilla project (like other projects) was already making use of a multiple license scheme without apparent problems.
Rather than using a triple license, another possible approach would have been to create a new version of the MPL containing language that would explicitly address the GPL (and LGPL) compatibility issue. (The FSF had previously suggested such an approach as one way to address perceived incompatibilities between the MPL and GPL.) However after considering the question we concluded that modifying the MPL would be more time consuming and potentially error prone.
Changing the MPL would also potentially affect developers who have adopted the MPL for use with their own code, independently of the Mozilla project. If those developers did not like the new MPL changes then they would have to explicitly use an older version of the MPL, or create their own MPL-based license. (Or, to prevent their having to do this, we would have to make the new provisions in the MPL optional, with developers specifying whether they wanted to include them or not.) Finally, changing the MPL would have required re-submitting it to the Open Source Initiative for certification in connection with the Open Source Definition, another potentially time-consuming process.
We therefore concluded that a better approach would simply be to use a triple license. This is a natural extension of the dual license approach that has previously been used with Mozilla code and is also being used by other projects, without apparent problems; it involves the use of licenses (the MPL version 1.1, the GPL version 2, and the LGPL version 2.1) that are already familar to open source and free software developers, avoiding the need to introduce yet another new and different license.
Because historically Mozilla code has always been released under some form of copyleft licensing, and we wish to continue to use copyleft provisions to promote sharing of modifications to Mozilla code.
One of the motivations behind the original creation of the NPL and MPL was to promote sharing of modifications amongst all parties using Mozilla code. Using the BSD license, the MIT license, or similar non-copyleft licenses was considered at that time, and ultimately rejected in favor of the NPL/MPL copyleft mechanisms; to quote from the original Netscape Public License FAQ,
The BSD license, in Netscape's opinion, does not go far enough to ensure that developers will return their modifications to the Communicator source code to the community. The company feels that this is important to ensure long term viability of the source development effort.
We believe that this goal is still worth promoting. Thus we have decided to retain the use of copyleft provisions; of the three license options available for Mozilla code under the new MPL/GPL/LGPL triple license, all have copyleft features (of varying strength) that require modifications to Mozilla code to be distributed when distributing products using that code.
Not at all; developers creating and distributing proprietary software incorporating Mozilla code will be able to continue to use that code under MPL terms and conditions, exactly as they have been doing all along.
The MPL was originally designed to allow source files distributed under MPL terms to be combined with source files under other licenses, and the resulting work to be distributed under a non-MPL license. (This right is contingent on the requirements of the MPL being fulfilled. For example, when distributing the resulting work to users, the distributor must also make available to users the source code for that portion of the code created from the source files distributed under the MPL.)
This feature of the MPL has allowed developers to distribute proprietary products incorporating Mozilla code. (Netscape 7 is one example of such a product.) Under the MPL/GPL/LGPL triple license scheme developers may continue to create and distribute Mozilla-based proprietary products, by taking advantage of the option to use the Mozilla code under the MPL terms and complying with the various requirements of the MPL for those portions of the proprietary products based on Mozilla code.
(In theory developers could also distribute Mozilla-based proprietary products using the Mozilla code under LGPL terms, if the Mozilla code were in the form of a library and the developers complied with the relevant requirements of the LGPL.)
If and when the new licensing scheme is fully implemented, developers creating libraries and related software distributed under the LGPL will be able to use any Mozilla code in that software under LGPL terms and conditions.
If and when all Mozilla source files are relicensed under the MPL/GPL/LGPL triple license (or other compatible licenses), then developers may create and distribute Mozilla-based libraries and related software under the LGPL by taking advantage of the option to use the Mozilla source files under LGPL terms, and complying with the various requirements of the LGPL for those portions of the software based on code from the Mozilla source files.
Under the MPL/GPL/LGPL triple license developers may also extract portions of Mozilla code and use them in existing source files already under the LGPL, without needing to change the existing LGPL license notice in those source files. (This is possible because the triple license boilerplate language permits deleting the MPL portion of the notice and using just an LGPL notice.)
Note that even before all Mozilla source files are relicensed under the MPL/GPL/LGPL triple license, developers distributing libraries under the LGPL may use any Mozilla source files already relicensed under the MPL/GPL/LGPL triple license.
If and when the new licensing scheme is fully implemented, developers creating software distributed under the GPL will be able to use any Mozilla code in that software under GPL terms and conditions.
If and when all Mozilla source files are relicensed under the MPL/GPL/LGPL triple license (or other compatible licenses), then developers may create and distribute Mozilla-based software under the GPL by taking advantage of the option to use the Mozilla source files under GPL terms. This allows developers to distribute the entire work under GPL terms and at the same time comply with the GPL requirements for those portions of the software based on code from the Mozilla source files.
Under the MPL/GPL/LGPL triple license developers may also extract portions of Mozilla code and use them in existing source files already under the GPL, without needing to change the existing GPL license notice in those source files. (This is possible because the triple license boilerplate language permits deleting the MPL portion of the notice and substituting the notice associated with the GPL.)
Note that if you wish to distribute portions of the Mozilla code under GPL terms you may be able to do so before the entire relicensing project has been completed. Since the relicensing will occur in stages, be sure to check the licenses for the particular files you want to use, as those files may have already been relicensed under an MPL/GPL/LGPL triple license, or under the MPL/GPL dual licenses used in the past.