Eclipse-family copyleft scoped to each Contribution. It reaches GPL compatibility only when the project designates a Secondary License.
On this page
What it does
EPL-2.0 is the license behind the Eclipse IDE, Jakarta EE artifacts and JUnit 5, and one arm of Jetty's EPL-2.0 or Apache-2.0 dual license. Its reciprocity attaches to each Contribution and to the Program you distribute in object form. Reciprocity here means the covered code has to stay available under the same license, which is a slightly wider net than the MPL's per-file scope. A separate module you wrote and distribute alongside the Program stays yours. Two clauses decide most real cases. Section 3.1 makes the source of the Program available to whoever receives the object code. Section 4 makes you defend the other contributors if you sell warranty or support and someone sues over it.
Details
The compatibility line is where this license gets misquoted. EPL-2.0 can be combined with GPL code, but only through the Secondary Licenses mechanism, and that mechanism designates the GNU General Public License version 2.0 or any later version. The designation is made by the project in its own notice file. You cannot elect it yourself for someone else's package, so check the project's notice before planning a mix. The other surprise is commercial: if you resell an Eclipse-based tool with a support contract, section 4 puts the defense of the other contributors on you.
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.
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
Modifications to covered files that you distribute have to be available in source form under this license.
Same license
Reciprocity stays on the covered modules. How far a 'module' reaches is the usual counsel question.
What EPL-2.0 requires when you ship
When you distribute a binary that includes EPL-2.0 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.1 when everyone who receives the Program in object form can get its source and is told where to get it.
You keep your own module outside the reciprocity when it is genuinely separate work distributed alongside the Program, not a change inside it.
You have handled your own Contributions when the changes you made to EPL code go back out under EPL-2.0 with their notices intact.
You have read the compatibility question correctly when you have opened the project's notice file and seen whether it designates a Secondary License.
You are clear on the commercial clause when the people selling support know that section 4 makes the seller defend the other contributors.
The duties named in EPL-2.0
Notice still travels with the copy. On top of that, EPL-2.0 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
Modifications to covered files that you distribute have to be available in source form under this license.
Same license
Reciprocity stays on the covered modules. How far a 'module' reaches is the usual counsel question.
Things to be aware of
- People repeat that EPL-2.0 is GPL-compatible full stop. It is compatible only where the project designates a Secondary License, and that designation covers GPL version 2.0 or any later version, GPLv3 included.
- EPL is described as file-level like the MPL. It scopes by Contribution and by the Program you ship, so map the boundary against your build output.
- A reseller signs a support agreement without reading section 4. Price that duty to defend into the deal, or keep support separate from the EPL artifacts you ship.
What the Eclipse Public License 2.0 does not do
Search results often flatten Eclipse Public License 2.0 into a slogan. These are the usual misreads. EPL-2.0 is a grant with conditions, not a permission to skip the paperwork below.
- Eclipse Public License 2.0 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 EPL-2.0 differs from nearby licenses
These licenses are often confused with EPL-2.0, but their release duties differ. Each row summarizes what the license requires when you ship. Open the linked page for the full checklist.
- EPL-2.0
- Eclipse-family copyleft scoped to each Contribution. It reaches GPL compatibility only when the project designates a Secondary License.
- EPL-1.0
- The older Eclipse license. Same Contribution-scoped duty as EPL-2.0, but with no GPL bridge, so mixing with GPL code is a real problem.
- 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.
- GPL-2.0-or-later
- GPL-2.0 asks for source when you hand someone a binary. Running it on your own servers triggers nothing. The trigger is shipping a copy, not merely using it.
Common questions about Eclipse Public License 2.0
Answers to common questions about what Eclipse Public License 2.0 requires, when its duties apply, and what evidence belongs with a release.
What is the Eclipse Public License 2.0?
EPL-2.0 is the license behind the Eclipse IDE, Jakarta EE artifacts and JUnit 5, and one arm of Jetty's EPL-2.0 or Apache-2.0 dual license. Its reciprocity attaches to each Contribution and to the Program you distribute in object form. Reciprocity here means the covered code has to stay available under the same license, which is a slightly wider net than the MPL's per-file scope. A separate module you wrote and distribute alongside the Program stays yours. Two clauses decide most real cases. Section 3.1 makes the source of the Program available to whoever receives the object code. Section 4 makes you defend the other contributors if you sell warranty or support and someone sues over it.
What does EPL-2.0 require when you ship a product?
You are meeting section 3.1 when everyone who receives the Program in object form can get its source and is told where to get it. You keep your own module outside the reciprocity when it is genuinely separate work distributed alongside the Program, not a change inside it. You have handled your own Contributions when the changes you made to EPL code go back out under EPL-2.0 with their notices intact. You have read the compatibility question correctly when you have opened the project's notice file and seen whether it designates a Secondary License. You are clear on the commercial clause when the people selling support know that section 4 makes the seller defend the other contributors.
Does hosting a product that uses EPL-2.0 trigger extra duties?
Hosting alone usually does not trigger the source duty for EPL-2.0. 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 EPL-2.0?
EPL-2.0 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 EPL-2.0?
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 EPL-2.0 different from Eclipse Public License 1.0?
EPL-2.0 asks this: Eclipse-family copyleft scoped to each Contribution. It reaches GPL compatibility only when the project designates a Secondary License. Eclipse Public License 1.0 asks this: The older Eclipse license. Same Contribution-scoped duty as EPL-2.0, but with no GPL bridge, so mixing with GPL code is a real problem. Open the Eclipse Public License 1.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 EPL-2.0 for a buyer?
EPL-2.0 has a catalog row marked copyleft, so a source offer item appears on the project checklist in the Distributed binary and Mixed contexts, and not for a hosted service. The item waits for a person, and publishing is blocked until someone confirms it. SourceTrust does not tell you whether an EPL artifact and a GPL artifact in the same build fit together; that is a reading of two license texts, not a lookup. What it does carry is the stored text into every export file.
Where do I record EPL-2.0 for a buyer?
EPL-2.0 has a catalog row marked copyleft, so a source offer item appears on the project checklist in the Distributed binary and Mixed contexts, and not for a hosted service. The item waits for a person, and publishing is blocked until someone confirms it.
SourceTrust does not tell you whether an EPL artifact and a GPL artifact in the same build fit together; that is a reading of two license texts, not a lookup. What it does carry is the stored text into every export file.
Read /docs/export-sbom for the formats.
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.