Here’s the final chapter in our License FAQ series. Previously, we covered your most frequently asked questions about GPL, the Apache License 2.0, the BSD License Family, CDDL and the MPL. Today let’s take a close look at the Eclipse Public License (EPL).
The Eclipse Public License is an open source license developed by the Eclipse Foundation. It’s derived from the Common Public License (CPL). The Eclipse codebase now available under the EPL was formerly licensed under the CPL.
The EPL license is a copyleft license. If you modify an EPL’ed component and distribute it in the source code form as part of your program, you’re required to disclose the modified code under the EPL. If you distribute such a program in its object code form, you’re required to state that the source code can be made available to the recipient upon request. You’re also required to share the method for requesting the source code.
The Eclipse Foundation makes clear that, in their opinion, ‘merely interfacing or interoperating’ with an Eclipse plugin does not make your code a derivative work of the plugin
If you redistribute a program with an EPL component, you are obligated to include the full license text and the copyrights.
The EPL protects the author from possible lawsuits or damages caused if a company used his/her component in a commercial product. It also offers patent grant.
Yes, the EPL is considered a weak copyleft license.
Weak copyleft licenses requires you to disclose your source on source code, but not on binaries and therefore you can compile covered sources with others and distribute the resulting (merged) binaries under the licence of your choice. With ‘strong’ copyleft license, the GPL family, you are obligated to reuse the same licence in case of re-distribution of copies or derivatives on both source and binaries.
The EPL revises the CPL by deleting the first sentence in the 7th section of the original CPL that was believed to be overly broad and non-conducive to the growth of the Eclipse ecosystem. The removed content explained how the CPL handled patent retaliation.
The GNU GPL family of licenses has a strong copyleft clause requiring users to release their software’s full source code irrespective of the percentage of the GPL’ed code included. The EPL on the other hand doesn’t require you to open source your entire code. You’re only required to open source any included modified EPL-ed components when distributing in the source code form, and make the source code available upon request when distributing in the object form.
The EPL is not compatible with the GNU GPL. The GPL requires the user to release the entire software and that the distributor not “impose any further restrictions on the recipients’ exercise of the rights granted”. The EPL, however, requires that anyone distributing the work grant every recipient a license to any patents that they might hold that cover the modifications they have made.
Because this is a “further restriction” on the recipients, distribution of such a combined work does not satisfy the GPL.
The LGPL is a weak copyleft version of the GNU GPL protecting users creating non-derivative works from having to open source their code when using or linking to an LGPL-ed component.
The EPL too is a weak copyleft license that only requires users to open source any included modified EPL-ed code, but with no obligation on its linking. You will need to release the modified EPL-ed components in case it was modified and released in its source form.
The Apache License 2.0 doesn’t force you to release your modified version of the Apache Licensed code. Besides, if you’d like, you can choose to release your modified version under a different license (however, you’re required to retain the Apache License for the unmodified parts of the code).
This is very different from the requirements of the EPL, where a developer is required to open source the modified EPL-ed code when distributing in the source code form, and make it available upon request when distributing in the object code form.
Besides, the EPL-ed code in a program can only be released under the EPL, even if the full program is released under a different license.
MIT is one of the most permissive free software licenses. Basically, you can do whatever you want with a software licensed under the MIT license – only if you add a copy of the original MIT license and copyright notice to it. Its simplicity is the reason behind its high adoption rate among developers.
If you contrast the MIT License with the EPL, you’ll see that EPL has certain requirements when it comes to distributing code — a developer is required to distribute the source code of any included EPL-ed code if any modifications are made to it. Besides, if an EPL-ed modified program is distributed in the object code form (even if it’s part of a proprietary software), the developer is required to make the modified EPL-ed code available if a recipient requests for it. Additionally, an EPL-ed component can only be released under the EPL.
A developer can choose to distribute a BSD-licensed program as per his/her choice. The BSD license doesn’t impose the reciprocity clause either.
The way the EPL differs from the BSD Licenses is very similar to the way that the EPL differs from the MIT License. Again, the key point of distinction is the requirements regarding distribution. The EPL requires developers to share the modified source code of an EPL-ed component. If the distribution happens in the object code, the developers are still required to open the source code of the modified EPL-ed code upon request.
Yes, as the original creator of a program, or after obtaining the permission from the original creator of a program, it’s possible to mix code licensed under the EPL with other compatible licenses. However, you must note that the source code of an EPL-ed software can only be released under the EPL.
So these are ten of your top Eclipse Public License questions answered. Do you have any more questions about the EPL that you’re looking to get answered? Do share them in the comments. I’d be happy to extend the post to cover them.
The author of this blog is not a lawyer, and you should not interpret this as legal advice of any kind. Information is provided on an as-is basis. For a legal consultation, please contact your legal advisor.