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.
On this page
What it does
EPL-1.0 is the license Clojure, JUnit 4, one arm of Jetty 9's dual license and a large slice of the Eclipse 4.x era shipped under, and it is still all over Maven Central. Reciprocity attaches to each Contribution, meaning the licensed code plus the changes you make to it stay available under EPL. A separate module you wrote and distribute alongside the Program is not covered. Section 3 is the working clause: when you distribute the Program in object code form, you state that source is available and tell recipients how to get it. Section 4 adds the commercial catch that EPL-2.0 later kept.
Details
The reason to keep this license apart from EPL-2.0 is one sentence: EPL-1.0 does not work with the GPL. Both the Free Software Foundation and the Eclipse Foundation say so, and EPL-2.0's Secondary Licenses mechanism exists to fix exactly that. A Java build that mixes an EPL-1.0 artifact into GPL-licensed code therefore has a problem no build flag solves, while the same mix with EPL-2.0 may be fine if the project designated GPL. Version pinning decides which of the two you are in, so read the artifact's own license header rather than the project's website.
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-1.0 requires when you ship
When you distribute a binary that includes EPL-1.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 when your object code release states that source is available and gives recipients a way to get it.
You have handled your own changes when the Contributions you made to EPL-1.0 code are released under EPL-1.0 with their notices intact.
You keep your own module outside the license when it is separate work distributed alongside the Program rather than a change inside it.
You have answered the GPL question when you have confirmed that no GPL-licensed code in the same product is combined with this artifact.
You are clear on the commercial clause when whoever sells warranty or support knows that section 4 puts the defense of other contributors on the seller.
The duties named in EPL-1.0
Notice still travels with the copy. On top of that, EPL-1.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
- Teams read EPL-1.0 and EPL-2.0 as the same license. Only 2.0 has the Secondary Licenses bridge to the GPL, and only when the project designates it.
- A dependency upgrade quietly moves an artifact from EPL-1.0 to EPL-2.0 or the other way. Re-check the license on every version bump, not once per project.
- EPL is handled as file-scoped like the MPL. It scopes by Contribution and by the Program you distribute, which is wider, so map it against your build output.
- A dual EPL-1.0 or LGPL-2.1 package such as Logback is recorded under one arm at random. Pick the arm you actually rely on and write down why.
What the Eclipse Public License 1.0 does not do
Search results often flatten Eclipse Public License 1.0 into a slogan. These are the usual misreads. EPL-1.0 is a grant with conditions, not a permission to skip the paperwork below.
- Eclipse Public License 1.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-1.0 differs from nearby licenses
These licenses are often confused with EPL-1.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-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.
- EPL-2.0
- Eclipse-family copyleft scoped to each Contribution. It reaches GPL compatibility only when the project designates a Secondary License.
- 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.
- 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 1.0
Answers to common questions about what Eclipse Public License 1.0 requires, when its duties apply, and what evidence belongs with a release.
What is the Eclipse Public License 1.0?
EPL-1.0 is the license Clojure, JUnit 4, one arm of Jetty 9's dual license and a large slice of the Eclipse 4.x era shipped under, and it is still all over Maven Central. Reciprocity attaches to each Contribution, meaning the licensed code plus the changes you make to it stay available under EPL. A separate module you wrote and distribute alongside the Program is not covered. Section 3 is the working clause: when you distribute the Program in object code form, you state that source is available and tell recipients how to get it. Section 4 adds the commercial catch that EPL-2.0 later kept.
What does EPL-1.0 require when you ship a product?
You are meeting section 3 when your object code release states that source is available and gives recipients a way to get it. You have handled your own changes when the Contributions you made to EPL-1.0 code are released under EPL-1.0 with their notices intact. You keep your own module outside the license when it is separate work distributed alongside the Program rather than a change inside it. You have answered the GPL question when you have confirmed that no GPL-licensed code in the same product is combined with this artifact. You are clear on the commercial clause when whoever sells warranty or support knows that section 4 puts the defense of other contributors on the seller.
Does hosting a product that uses EPL-1.0 trigger extra duties?
Hosting alone usually does not trigger the source duty for EPL-1.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-1.0?
EPL-1.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-1.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-1.0 different from Eclipse Public License 2.0?
EPL-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. Eclipse Public License 2.0 asks this: Eclipse-family copyleft scoped to each Contribution. It reaches GPL compatibility only when the project designates a Secondary License. Open the Eclipse 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 EPL-1.0 for a buyer?
EPL-1.0 has its own catalog row, marked copyleft, so a source offer item lands on the project checklist in the Distributed binary and Mixed contexts. A hosted service sees nothing. When a package declares a plain OR over at most three licenses, such as EPL-1.0 or LGPL-2.1, SourceTrust lets you elect one arm and records which one you picked. It does not judge whether EPL-1.0 and another license in your build fit together.
Where do I record EPL-1.0 for a buyer?
EPL-1.0 has its own catalog row, marked copyleft, so a source offer item lands on the project checklist in the Distributed binary and Mixed contexts. A hosted service sees nothing.
When a package declares a plain OR over at most three licenses, such as EPL-1.0 or LGPL-2.1, SourceTrust lets you elect one arm and records which one you picked. It does not judge whether EPL-1.0 and another license in your build fit together.
Read /docs/reviewing-component for the election and accept 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.