Markdown

EPL

EPL is the Acronym for Eclipse Public License

The 2017 successor to version 1.0, stewarded by the Eclipse Foundation. The SPDX short identifier is EPL-2.0. The Foundation’s Board of Directors unanimously approved the new text, deprecated version 1.0, and made 2.0 the default license for Eclipse projects. That includes the Eclipse Project, which supplies the Eclipse IDE platform. Jakarta EE Technology Compatibility Kits contributed to the Foundation also ship under these terms.

Copyleft is intentionally weak and commercial-friendly. You may compile the Program and license object code commercially, including under a product EULA, as long as recipients can still obtain the Program’s source and their rights in that source are not cut back. Running a modified Program as hosted SaaS without distributing a copy does not, by itself, force you to publish those changes.

Weak Copyleft and the Patent Grant

The Foundation’s FAQ still calls this a weak copyleft license. If you modify EPL-2.0 source and distribute that code, or binaries built from it, outside your organization, you must make the corresponding source available under these terms. Private modification with no distribution creates no such duty. Versus version 1.0, the FAQ lists the copyleft term of art as file rather than module, removes choice-of-law, and states that the text is suitable for scripting languages such as JavaScript.

  • Modified Works: Copyleft attaches to additions, deletions, and edits to Program contents, including a new source file that contains Program contents. Files that only declare interfaces, types, classes, structures, or similar material in order to link, bind by name, or subclass are not Modified Works.
  • Plug-ins and APIs: The Foundation interprets derivative work consistently with the U.S. Copyright Act as applied to software. Linking might or might not create a derivative work. A plug-in written entirely as your own code is not one. Merely interfacing with Eclipse Platform plug-in APIs, without modification, does not make that plug-in a derivative work.
  • Patent grant: Section 2(b) is a non-exclusive, worldwide, royalty-free patent license under Licensed Patents to make, use, sell, offer to sell, import, and otherwise transfer the Contribution. It covers the Contribution-plus-Program combination when adding the Contribution causes infringement. Hardware as such is not licensed. Filing patent litigation that alleges the Program itself infringes terminates those Section 2(b) rights. The FAQ states that the patent terms did not change from version 1.0.
  • Commercial indemnity: A Commercial Contributor who includes the Program in a product offering must defend and indemnify other Contributors for third-party claims caused by that commercial distribution, such as performance claims or extra warranties. That duty does not cover intellectual property infringement claims.

Secondary License for GPL Compatibility

Version 1.0 had no path to the GNU General Public License (GPL). Version 2.0 adds an optional Secondary License: GPL or any later version, including exceptions or additional permissions the initial Contributor names. That later-version set includes GPL. Without Exhibit A, the Foundation and the Free Software Foundation both treat EPL-2.0 as incompatible with the GPL, including combinations that would be a derivative work, a work based on GPL code, the same source module, or (on the FSF’s view) a link.

  • Opt-in, not default: Mozilla Public License 2.0 (MPL) is GPL-family compatible unless the initial Contributor marks the files Incompatible With Secondary Licenses. EPL-2.0 is the opposite: GPL compatibility is off until the initial Contributor attaches the Exhibit A notice. Shipping a copy of the Agreement, Exhibit A included, is not enough.
  • Narrower secondary set: A Secondary License here can only be GPL-2.0 or later, plus named exceptions. The FAQ says you cannot name some other license as a Secondary License. MPL-2.0’s secondary set is broader: GPL-2.0, LGPL, and AGPL (and later versions).
  • Close to dual licensing: The FAQ calls the construct extremely close to dual licensing. EPL-2.0 remains the only license until the Program is combined and distributed with Secondary License work. A recipient of that combination may then treat the content under the Secondary License. The original project stays under EPL-2.0. The FSF describes Exhibit A as roughly equivalent, for users, to releasing the code under a dual license.
  • Relicense consent: Moving EPL-1.0 code to EPL-2.0 without a Secondary License can follow the upgrade clause in Section 7. Adding GPL compatibility is a relicensing. Every copyright holder must agree.
  • Jakarta EE pattern: Many Jakarta APIs use the SPDX expression EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0, which is this Secondary License plus the Classpath exception. The FAQ compares that stack to older dual CDDL or GPL-2.0-with-Classpath licensing. Adopters who never want the GPL path can ignore Exhibit A and consume the code under EPL-2.0 alone.

How It Compares

MPL-2.0 is the nearest neighbor: both are file-level weak copylefts with an express patent grant and a commercial binary path. The GPL is not. EPL-1.0 remains usable but deprecated; the Foundation asks new Eclipse work to adopt 2.0.

LicenseCopyleftGPL compatibilityNotes
EPL-2.0Weak, file-level Modified WorksOpt-in Exhibit A (GPL-2.0 or later, plus named exceptions)Default Eclipse license; Eclipse IDE platform; Jakarta EE TCKs
EPL-1.0Weak copyleft; no Secondary LicenseIncompatibleDeprecated predecessor; choice-of-law later removed
MPLWeak, file-level Covered SoftwareOn by default unless Exhibit B (GPL-2.0, LGPL-2.1, AGPL-3.0)Mozilla-style file copyleft; opposite default from EPL-2.0
GPLStrong, whole-work copyleftIt is the GPLCombining with EPL-2.0 that lacks Exhibit A is incompatible