The Eclipse Public License (EPL) is a weak copyleft open source license maintained by the Eclipse Foundation. There are two versions of the EPL — the original EPL-1.0, which was released in 2004, and the EPL-2.0, which was published in 2017.
The EPL-1.0 has been deprecated (and the Eclipse Foundation recommends OSS contributors consider switching to 2.0), so we’ll focus primarily on version 2.0 in this blog. (Assume all references to the Eclipse Public License are about the EPL-2.0 unless otherwise noted.)
Much like fellow weak copyleft licenses LGPL and Mozilla Public License 2.0, the EPL carries more requirements on the use of the licensed code than permissive licenses, but offers more freedoms than strong copyleft licenses.
In this blog, we’ll review the history of the Eclipse Public License, analyze its key provisions, and share some of the bigger projects that use it.
History of the Eclipse Public License
The original version 1.0 of the Eclipse Public License was based on IBM’s Common Public License (CPL). There were two primary differences between the CPL and EPL-1.0.
- IBM served as the agreement steward for the CPL, while the Eclipse Foundation is the agreement steward for the EPL
- The EPL removed the following sentence from the CPL that covered potential patent litigation: “If Recipient institutes patent litigation against a Contributor with respect to a patent applicable to software (including a cross-claim or counterclaim in a lawsuit), then any patent licenses granted by that Contributor to such Recipient under this Agreement shall terminate as of the date such litigation is filed.”
Per the Eclipse Foundation website, the sentence was removed due to concerns that it was “overly broad” and a barrier to “the continued growth of the Eclipse eco-system.”
In 2017, the Eclipse Foundation published the current Eclipse Public License 2.0; the EPL-1.0 has since been deprecated. The EPL-2.0 has four major changes from the EPL-1.0, which we’ll discuss later in this piece.
Eclipse Public License: Key Provisions
As a weak copyleft license, the EPL is a middle ground of sorts between permissive options (like the MIT License or Apache License 2.0) and strong copyleft licenses (like GPL v2 and GPL v3.)
A core requirement of the EPL — one that’s not part of permissive licenses — is that derivative works of EPL-licensed code must also be licensed under the EPL. (As such, anyone who distributes a program that constitutes such a derivative work must also make their source code available.)
However, the EPL’s definition for a derivative work is narrower than GPL’s.
Under the EPL, if you simply use — rather than modify — an EPL-licensed component and keep it in a separate file, that would not constitute a derivative work, and you would not be required to make available your source code. With the GPLs, however, any use (modified or not) of the licensed code would create a derivative work.
Here are some of the Eclipse Public License’s other important provisions:
Eclipse Public License Requirements
Key requirements of the EPL are as follows. You must:
- Include a copy of the full license text and the original copyright notice
- Make available your source code when you distribute a derivative work based on the licensed code
- License any derivative works of the library under the same or later version of the EPL
- If you commercially distribute a product that includes an EPL-licensed program, you are required to defend that program’s contributors from any lawsuits/legal damages that may arise involving your product
Using EPL-Licensed Code
The Eclipse Public License allows users of the licensed code to:
- Use the code commercially: The EPL imposes no conditions on using the code in software that’s sold commercially except for the aforementioned requirement to extend legal protections to EPL contributors
- Change the code: Users can rework the code, but if they distribute these modifications, they must release these updates in source code form.
- Place warranty: Distributors of the original code can offer their own warranty on the licensed software.
- Add a Secondary License: Users can add a Secondary License to enable compatibility with GPL v2 or later; we’ll discuss this in more detail later in the blog.
The EPL does not allow contributors to be held liable for legal issues or damages, nor does it permit using contributors' names, trademarks, or logos.
Eclipse Public License and GPL Compatibility
The Eclipse Public License isn’t inherently compatible with the GPL License. For many years (prior to the release of EPL-2.0), the workaround for this was to dual-license projects under both EPL and the BSD License. But the release of EPL-2.0 offered a new solution: the Secondary License.
The Secondary License allows code licensed under the EPL to be combined with code covered by an incompatible license — specifically GPL v2 or later. So, code licensed under EPL with a GPL v2 Secondary License could be combined with code licensed under GPL v2 and then distributed as a combined program under GPL v2.
EPL-1.0 vs. EPL-2.0
As mentioned, there are four major differences between the original version of the Eclipse Public License (EPL-1.0) and the current EPL-2.0.
- In contrast to the original, the EPL-2.0 is suitable for scripting languages such as JavaScript, PHP, Python, and Ruby, among others. This is because the EPL-2.0 both defines source code and requires source code to be made available (where and when applicable).
- There’s a new option to add a “Secondary License” to enable GPL compatibility as described above.
- The EPL-1.0’s “choice of law” provision stated that the license was governed by New York State laws (and U.S intellectual property laws). The EPL-2.0 aims to make it easier for projects outside the U.S. to use the license by removing those references.
- The EPL-2.0 replaced the word “module” with “file” when defining what constitutes a derivative work. This refers to the idea that using (as opposed to modifying) EPL-licensed code does not constitute a derivative work so long as that code is kept in a separate “file” (previously termed separate “module”).
It’s relatively straightforward to relicense open source projects from the EPL-1.0 to EPL-2.0. All that’s required is that you update the file headers and notices.
Per the Eclipse Foundation’s website, if you’re using EPL-licensed code (which you don’t maintain) in a distributed program, you can take the following steps to re-license:
"Where the EPL-1.0 licensed content has not had its file headers updated to reflect the EPL-2.0, the licensee (contributor) may distribute the EPL-1.0 content under the EPL-2.0 by: (a) including a Notice File stating "the content is being distributed subject to the EPL-2.0 (see License File)" and (b) including the EPL-2.0 license text in the License File."
Eclipse Public License vs. Other Weak Copyleft Licenses
As mentioned, the Eclipse Public License has a lot in common with other popular weak copyleft licenses like the LGPL and Mozilla Public License 2.0, but there are a handful of notable differences.
EPL vs. Mozilla Public License 2.0
Like the EPL, the Mozilla Public License 2.0 allows users to keep (unmodified) MPL’d code in a separate file, then combine that code with code under a different license to create an aggregate work. The new/additional files can be released under a different license.
A notable difference between the two is that the the MPL 2.0 does not include the EPL’s legal protections for project contributors.
Note: The MPL is very similar to the CDDL (Common Development and Distribution License). The CDDL also allows users to combine licensed code (kept in a separate file) with code under a different license to create an aggregate work. And, it doesn't offer the EPL's legal protections for project contributors.
EPL vs. LGPL
A notable difference between the LGPL (Lesser General Public License) and other weak copyleft licenses is that the LGPL does not allow users to sublicense binaries under other terms, while the EPL and MPL 2.0 do.
Eclipse Public License: The Bottom Line
As a weak copyleft license, the EPL fills a gap between permissive and strong copyleft licenses. Although the EPL doesn’t rival the MIT or Apache 2.0 Licenses in popularity, several well-known projects are licensed under it. These include:
- Eclipse’s Jetty Project
- Eclipse’s Golo Language
- Clojure (licensed under EPL-1.0)
- AT&T’s Software Technology Toolkit (licensed under EPL-1.0)
For more information on popular open source licenses, visit our OSS license homepage.
