What this license is
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.
Why it matters for your product
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.
You are meeting the terms when
- 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.
Where teams get it wrong
- 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.
How SourceTrust handles this license
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 Reviewing a component for the election and accept flow.
Related guides
- Source code offer (copyleft)
- Eclipse Public License 2.0
- Common Development and Distribution License 1.0
- GNU GPL v2.0 or later