The 1998 Mozilla license. Its source duty attaches to the files you modified, not to every MPL file you ship, and it has no GPL bridge.
On this page
What it does
MPL-1.1 is the predecessor that MPL-2.0 was written to replace, and the two draw the source line differently. Under section 3.2 of MPL-1.1, the duty to make source available attaches to any Modification you create or contribute to. For covered files you ship untouched, section 3.6 asks for a notice that their source is available under the MPL, and where to find it. MPL-2.0 section 3.2 widened that duty to all Covered Software you distribute in executable form, modified or not. Copyleft here means the license requires that source to stay under the MPL, while your own separate files stay yours. MPL-1.1 also carries no bridge to the GPL, which is why so much Mozilla-era code shipped under a tri-license header naming MPL, GPL and LGPL together.
Details
You will meet MPL-1.1 in legacy corners: older Java and .NET libraries, and code that predates the 2012 relicensing wave. The practical duty is narrower than under MPL-2.0. If you patched a covered file, the source of that patch has to be available to everyone who got your executable. Section 3.2 keeps it reachable for twelve months after it first became available, or six months after you publish a later version of that change. If you shipped the files untouched, you owe the section 3.6 notice and a pointer to the source, not a hosting duty of your own. The part that bites is compatibility. If your product also contains GPL code, an MPL-1.1 file is a real problem unless the package is explicitly multi-licensed, so read the file headers rather than the package metadata.
Pros
- You can link the library from closed code in the way the license describes.
- File-level reciprocity is easier to isolate than GPL-style whole-work copyleft.
Cons
- Vendoring or statically linking can pull more of your tree into the covered set than a dynamic link would.
- The source-offer duty is real the moment you distribute binaries that include modified covered files.
What it allows and requires
Choose a category to see the full grant in one scannable list. Permissions show what the license allows, limits show what it withholds, and obligations show the conditions your release process must satisfy.
Permissions
Commercial use
You may ship the code inside a paid product. The license does not restrict commercial use.
Modify
You may change the code, including keeping those changes private, unless a later obligation says otherwise.
Distribute
You may give copies to others. Distribution is what usually turns notice and source duties into real work.
Private use
Use inside your company, including internal forks, does not by itself trigger distribution duties.
Patent use
These licenses typically include a patent grant covering the licensed files. Read the grant before relying on it in a high-stakes deal.
Limits
Hold liable
The authors disclaim warranty. Recipients cannot hold them liable for damages arising from the software, except where law forbids that disclaimer.
Use trademark
The license is not a trademark license. Names, logos and product marks stay with their owners unless a separate grant says otherwise.
Open your product
File- or library-scoped copyleft does not, on its face, force you to open your entire application. Reciprocity stays on the covered files.
Combine with GPL
MPL-1.1 has no GPL compatibility bridge. An MPL-1.1 file next to GPL code is a real problem unless the package is explicitly multi-licensed.
Obligations
Include copyright
Keep copyright notices on the covered files you distribute.
Include license
Keep the license text with the covered files, and say that those files are under this license.
Disclose source
If you created or contributed to a Modification, that change's source has to be available to everyone who got your executable, for the period section 3.2 sets.
Include notice
For covered files you ship untouched, include a notice that their source is available under the MPL, and where to find it.
What MPL-1.1 requires when you ship
When you distribute a binary that includes MPL-1.1 code, notice still travels with the copy, and the corresponding source has to be available under the same license. Internal use without a copy leaving the company is a different situation. The list below is the shipping work: what a recipient of that binary can demand, and what you record so a buyer can see it.
You are meeting section 3.2 when everyone who received your executable can get the source of every covered file you modified, and that source stays reachable for the twelve months the clause sets.
You have handled untouched covered files when your executable carries the section 3.6 notice: that their source is available under the MPL, and how and where to get it.
You have handled the GPL question when you have read the actual file headers and know whether the package is plain MPL-1.1 or a tri-license.
You keep notices in order when every covered file you pass on still carries its MPL-1.1 header and the license text ships with the distribution.
The duties named in MPL-1.1
Notice still travels with the copy. On top of that, MPL-1.1 names a source duty. These are the conditions in the text. The how-to above is when they become real work.
Include copyright
Keep copyright notices on the covered files you distribute.
Include license
Keep the license text with the covered files, and say that those files are under this license.
Disclose source
If you created or contributed to a Modification, that change's source has to be available to everyone who got your executable, for the period section 3.2 sets.
Include notice
For covered files you ship untouched, include a notice that their source is available under the MPL, and where to find it.
Things to be aware of
- Teams treat MPL-1.1 and MPL-2.0 as interchangeable. They are not: 1.1 scopes the source duty to your Modifications and has no GPL bridge, so a mixed build depends on the tri-license header.
- The source archive is taken offline a month after the release. Section 3.2 asks for twelve months from when the source first became available, or six after a later version of that change, so keep it up or point at a permanent upstream tag.
- An old dependency is assumed dead and skipped in review. Legacy MPL-1.1 code still ships inside your binary, so it belongs in the inventory like anything else.
What the Mozilla Public License 1.1 does not do
Search results often flatten Mozilla Public License 1.1 into a slogan. These are the usual misreads. MPL-1.1 is a grant with conditions, not a permission to skip the paperwork below.
- Mozilla Public License 1.1 does not force you to open your whole application. The reciprocal duty stays on the covered files.
- It is not "permissive with extra paperwork." Change a covered file and ship it, and that file's source has to be available under the same license.
How MPL-1.1 differs from nearby licenses
These licenses are often confused with MPL-1.1, but their release duties differ. Each row summarizes what the license requires when you ship. Open the linked page for the full checklist.
- MPL-1.1
- The 1998 Mozilla license. Its source duty attaches to the files you modified, not to every MPL file you ship, and it has no GPL bridge.
- MPL-2.0
- File-scoped copyleft. The MPL files stay open when you ship a binary, modified or not. Your own separate files stay yours.
- CDDL-1.0
- Sun's file-scoped copyleft. It is the reason ZFS ships outside the Linux kernel: CDDL code does not combine with the GPL.
Common questions about Mozilla Public License 1.1
Answers to common questions about what Mozilla Public License 1.1 requires, when its duties apply, and what evidence belongs with a release.
What is the Mozilla Public License 1.1?
MPL-1.1 is the predecessor that MPL-2.0 was written to replace, and the two draw the source line differently. Under section 3.2 of MPL-1.1, the duty to make source available attaches to any Modification you create or contribute to. For covered files you ship untouched, section 3.6 asks for a notice that their source is available under the MPL, and where to find it. MPL-2.0 section 3.2 widened that duty to all Covered Software you distribute in executable form, modified or not. Copyleft here means the license requires that source to stay under the MPL, while your own separate files stay yours. MPL-1.1 also carries no bridge to the GPL, which is why so much Mozilla-era code shipped under a tri-license header naming MPL, GPL and LGPL together.
What does MPL-1.1 require when you ship a product?
You are meeting section 3.2 when everyone who received your executable can get the source of every covered file you modified, and that source stays reachable for the twelve months the clause sets. You have handled untouched covered files when your executable carries the section 3.6 notice: that their source is available under the MPL, and how and where to get it. You have handled the GPL question when you have read the actual file headers and know whether the package is plain MPL-1.1 or a tri-license. You keep notices in order when every covered file you pass on still carries its MPL-1.1 header and the license text ships with the distribution.
Does hosting a product that uses MPL-1.1 trigger extra duties?
Hosting alone usually does not trigger the source duty for MPL-1.1. Shipping a binary, a container, or an on-prem build does. Notice still travels with any copy you hand over.
Can I keep my application closed if I use MPL-1.1?
MPL-1.1 is library-scoped copyleft. Your application can stay closed if recipients can replace the library with their own build. Static linking makes that expensive. The library itself still ships with corresponding source and notices. Confirm the linking story on the component, then record it.
What is corresponding source for MPL-1.1?
Corresponding source is the source a recipient needs to build and run the same binary, including scripts and interface files the license names. Hosting a repository URL can be an offer. The offer has to match what you actually shipped. SourceTrust records that a person on your team confirmed the offer. It does not publish your source and does not host a mirror.
How is MPL-1.1 different from Mozilla Public License 2.0?
MPL-1.1 asks this: The 1998 Mozilla license. Its source duty attaches to the files you modified, not to every MPL file you ship, and it has no GPL bridge. Mozilla Public License 2.0 asks this: File-scoped copyleft. The MPL files stay open when you ship a binary, modified or not. Your own separate files stay yours. Open the Mozilla Public License 2.0 page for what that license requires when you ship. Do not treat the SPDX ids as interchangeable because the short names look similar.
Where do I record MPL-1.1 for a buyer?
MPL-1.1 has a catalog row of its own, marked copyleft, so a source offer item appears on the project checklist in the Distributed binary and Mixed contexts. A SaaS-only project sees nothing. The fetcher compares the text it finds in the package against the declared id. A tri-licensed file often lands as a mismatch rather than a confirmed match, because the header is not the plain MPL-1.1 text. That result waits for you to accept or correct it.
Where do I record MPL-1.1 for a buyer?
MPL-1.1 has a catalog row of its own, marked copyleft, so a source offer item appears on the project checklist in the Distributed binary and Mixed contexts. A SaaS-only project sees nothing.
The fetcher compares the text it finds in the package against the declared id. A tri-licensed file often lands as a mismatch rather than a confirmed match, because the header is not the plain MPL-1.1 text.
That result waits for you to accept or correct it. Read /docs/reviewing-component for that flow.
See also
The hub is the pillar for this cluster. Sibling licenses are the other spokes. Product FAQ links explain how SourceTrust records the duty, not the license text itself.
Practical guidance for procurement review, not legal advice. Confirm high-stakes use with counsel.