Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

EPL/GPL Commentary

A while ago, we received a request to take a look at an open letter on the compatibility of the Eclipse Public License (EPL) and the GNU General Public License (GPL). This led to a number of conversations with the Free Software Foundation (FSF) on the topic. What we have learned and the conclusions that we have drawn are outlined below. You can also find the FSF’s summary and conclusions on their blog.

1. Introduction

In this context by “Eclipse plug-in” we mean a software module written in the Java programming language which is specifically intended to execute on top of the Eclipse platform which is provided under the Eclipse Public License (EPL). Eclipse plug-ins can be distributed in two different ways: (a) combined (e.g linked) with a copy of the Eclipse Platform, or (b) independently. In the latter case, such a plug-in would have to be combined by a user with the Eclipse platform in order to be executed. In short, Eclipse plug-ins are by definition useless without the availability of an instance of the Eclipse platform to be executed on.

2. Caveats

This blog post is not a substitute for professional legal advice. It is intended to provide general guidance to developers, but it was not prepared by an attorney nor is it in any way legal advice.

3. Generally Speaking, These Licenses Are Incompatible

The EPL and the GPL are inherently incompatible licenses. That is the position of both the Free Software Foundation and the Eclipse Foundation. In preparing this we consulted with the FSF to make sure we fully understood their interpretation of the GPL and how it interacts with the EPL. You may not link GPL and EPL code together and distribute the result. It doesn’t matter if the linking is dynamic, static or whatever. This bears repeating: if you or your organization are distributing EPL and GPL licensed code linked together into a single program you are almost certainly violating both the EPL and the GPL.

It is important that to understand the importance of linking in this discussion. If the EPL and GPL components interact with each other via pipes, sockets, etc. or if Eclipse is simply running as an application on top of GNU Linux then that is a completely different scenario and outside the scope of this analysis. The Eclipse CDT project for example makes use of gcc and gdb in its support of C/C++ development by restricting its interactions with those GPL-licensed facilities to the command line interface.

Note, however, that as free software proponents both of our organizations are interested in the freedom of users to make use of software. It may be possible for end users to create combinations of plug-ins where that same combination could not be lawfully distributed as a single program to third parties. The rest of this paper will look at this possibility and how such plug-ins could be distributed and assembled by end users.

It is the position of the Eclipse Foundation that the EPL is the preferred open source license for you to use for your Eclipse plug-ins. After all, the platform that you are leveraging when writing such a plug-in was provided to you under the EPL.

4. The EPL Perspective

The definition of “Contribution” in the EPL states that “Contributions do not include additions to the Program which: (i) are separate modules of software distributed in conjunction with the Program under their own license agreement, and (ii) are not derivative works of the Program” (emphasis added). Further, we make it clear in the EPL FAQ that simply linking to EPL does not constitute a derivative work. So, in other words, if you independently write an Eclipse plug-in that adds value on top of the Eclipse platform you are not required to license it under the EPL. In fact, many such plug-ins are licensed under commercial terms and conditions, as well as various open source licenses.

Under the terms of the EPL, it appears that it may be possible to license plug-ins under the GPL. What is clear, however, is that it is not possible to link a GPL-licensed plug-in to an EPL-licensed code and distribute the result. Any GPL-licensed plug-in would have to be distributed independently and combined with the Eclipse platform by an end user. This is why, for example, the Eclipse Foundation has allowed the independent distribution of GPL-licensed plug-ins via our Eclipse Marketplace.

5. The GPL Perspective

The GPLv2 is somewhat ambiguous on this topic, but the GPLv2 FAQ clarifies the position of the FSF. Under the heading “What is the difference between “mere aggregation” and “combining two modules into one program”?” they state that “If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.” A similar analysis holds true for the GPLv3 which you can see in the GPL FAQ under the heading “What legal issues come up if I use GPL-incompatible libraries with GPL software?”. In other words, it appears that it is the position of the FSF that since your plug-in was designed to run on top of the Eclipse platform it doesn’t matter if they’re distributed separately: the GPL should not be used for licensing Eclipse plug-ins.

If you or your organization owns all of the copyrights to the plug-in(s) in question, there is one mechanism which may provide a solution to this dilemma. That is to create a license exception which specifically allows linking to EPL-licensed code. However, if you do not own all of the copyrights to your GPL-licensed plug-in or other GPL-licensed libraries used by your plug-in then this issue remains.

The FSF’s position is, however, a matter of some debate. It is clear that they prefer that Eclipse plug-ins not be licensed under the GPL. But in the same section of the FAQ they also say that “This is a legal question, which ultimately judges will decide”. It is important that you seek your own competent legal advice if this situation applies to you or your organization.

6. Summary

Choosing to license an Eclipse plug-in under either version of the GPL places important constraints on how you distribute that plug-in. The purpose of this blog post is to provide developers with some general guidance on those constraints and the requirements placed on them to conform with the terms and conditions of both the EPL and the GPL. But this post was not prepared by an attorney nor is it in any way legal advice. Seek the advice of your own attorney.

Written by Mike Milinkovich

April 6, 2010 at 7:15 am

Posted in Foundation, Open Source

28 Responses

Subscribe to comments with RSS.

  1. Great summary. It really makes me wonder. What if the people behind the licenses could take a step back and review the consequences? Is this really what was intended?

    I’m convinced that both FSF and Eclipse are huge fans of open source. Yet, the license debacle blocks several great initiatives. Given all the negative consequences and extra work involved for open source developers all over the world, I wonder who (if any) it is that collects the benefits. I’m probably stupid, but I’ve never been able to figure that out. Lawyers undoubtedly have some gain, but a situation where that’s the only (positive?) outcome, must be considered fairly useless to all other parties involved.

    Can someone help me out with that?

    Thomas Hallgren

    April 6, 2010 at 12:43 pm

  2. I am a bit disappointed that neither you nor the FSF refer to the use cases described by Andrea in his open letter.
    E.g. if I get you right, the use case 5 subcase 2 (in short: distributing a GPL-bundle with the Equinox runtime) is not possible. If this is true, I agree with Thomas that this is really a huge and very negative implication – and one which goes far beyond Eclipse plugins: It highly constrains all (Equinox-)OSGi-based Open Source projects.
    I wonder how SpringSource was able to offer the dm Server under the GPL – at they state that “This practice of using different open source licenses for different components is common.” So is it only common but not legal? For all Open Source developers (without a layer at hand) life would be so much easier if it would be common AND legal…


    April 6, 2010 at 1:15 pm

  3. Thomas,

    I disagree with the notion that there exists a “license debacle”. Open source software comes with terms and conditions. Just because something is open source does not mean that a developer can use it without regard to the license terms. And yes, these licenses are working as designed.

    I believe that the key beneficiaries are the people, companies and communities that are contributing the code. They are the ones that typically care the most about those terms and conditions, because it defines how they are making available their intellectual assets.

    In the specific case of Eclipse, there are many contributors who would not have open sourced their software under license alternatives such as the GPL or the BSD. The EPL offers a particular combination of reciprocity and commercialization that many contributors find attractive.

    Mike Milinkovich

    April 6, 2010 at 1:20 pm

  4. @Kai,

    I think that the case of an OSGi bundle is subtly different than an Eclipse plug-in. By “Eclipse plug-in” we mean something which is inherently designed to run on top of the Eclipse platform. (E.g. they make use of Eclipse-specific APIs.)

    In the case of OSGi bundles, there exist runtimes other than Equinox upon which the bundle could run. Those OSGi runtimes (Apache Felix, Knoplerfish, etc.) are available under a variety of licenses, which means that the analysis included here may or may not apply. Frankly, it would be more of a question to the FSF than Eclipse. Try asking the FSF Compliance Lab at licensing (at)

    Mike Milinkovich

    April 6, 2010 at 1:37 pm

  5. Thanks, Mike. I know there are other options than Equinox, still it would be nice to use the same framework for design and runtime when doing MDD.
    From what I read from the FSF, I do not see that bundling is a problem as long as I include the special exception in the GPL license. It’s only your post which states that “it is not possible to link a GPL-licensed plug-in to an EPL-licensed code and distribute the result.”
    Could you maybe also comment on the Spring dm Server distributable? This is clearly under GPL and contains many EPL-licensed parts…


    April 6, 2010 at 1:56 pm

  6. @Kai

    Re: “…it would be nice to use the same framework for design and runtime when doing MDD”. The simple fact that the bundle could be deployed to a GPL-compatible runtime may change the FSF’s analysis. But I obviously cannot speak for them.

    I thought I made it clear elsewhere in the post, but to reiterate: “ is not possible to link a GPL-licensed plug-in to an EPL-licensed code and distribute the result UNLESS ALL OF THE GPL CODE IS COVERED BY A SPECIAL EXCEPTION AGREED TO BY ALL OF THE RELEVANT COPYRIGHT HOLDERS.”

    I do not want to comment on any particular scenario where the actions of a party may appear to differ from either my or the FSF’s blog post. Each such analysis requires a _lot_ of work on our part to evaluate. If you believe that a license violation exists contact license (at) or the FSF Compliance Lab at licensing (at), or both.

    Mike Milinkovich

    April 6, 2010 at 3:00 pm

  7. Related to this topic, I was wondering if anywhere on this blog or over at does it discusses this same issue but with respect to EPL vs LGPL? I’m wondering if the EPL and LGPL are similarly incompatible in the foundation’s view.


    April 6, 2010 at 3:36 pm

  8. @Mike,

    Perhaps you misunderstood my point. In my view, the debacle is ever present. For years now, we haven’t been able to use Maven in Buckminster, nor can we use SVN. That’s just two examples that are close to me. I know that the “Marketplace” will ease the situation a bit but the fundamental problem still exists.

    Open Software comes with terms and conditions, sure. I can live with that if the terms and conditions made any sense and/or helped the provider/consumer in some way. But tell me how the people behind Maven or Subversion are helped by the current situation? Or how it helps the Buckminster community? I’m in both camps (contributor and consumer) and I encounter these kinds of problems every day. Sometimes I have to do clean room re-implementations of perfectly functional code. It’s stupid to say the least and I am, to be honest, more then a little tired of it.

    You bring up dynamic linking as not being permitted. Yet, we provide gtk ports of swt that are completely reliant on dynamic linking with GPL’ed software. That’s apparently allowed. I argued that the same thing ought to be true for Subversion a while back, but for some reason that was interpreted differently. I still don’t know why.

    For me, as an open source contributor and consumer, licensing is an ongoing concern that is both painful and resource consuming. It puts shackles on creativity and has a profound impact on productivity.

    For what? So that the end user can click “I accept” without even reading the licenses? I know I never bother to scroll the page. Do you? Does anyone? If they do, can they really understand what the text means?

    Thomas Hallgren

    April 6, 2010 at 5:40 pm

  9. Thanks for the article, Mike.

    It answers a number of questions I have been asked many times in my work. And yes, I do know it is not legal advice, but it serves as a good starting point when you have to decide whether the Eclipse platform is usable as an application platform in a specific project.

    Do we (read you) know of any other common OSI licenses with the same type of EPL-compatibility problems as GPL?

    Tonny Madsen

    April 7, 2010 at 2:51 am

  10. @Kai, if SpringSource is distributing GPL bundles on top of an EPL OSGi framework (Equinox), given what Mike says that seems suspect to me. But I’m not a lawyer nor do I plan on playing one on TV.



    April 7, 2010 at 3:36 am

  11. @Thomas,

    Sorry, but license compatibility issues are a fact of life. I didn’t invent the problem, so please don’t shoot the messenger.

    GTK is licensed under the LGPL, not the GPL. (Please see That is a very large and important difference.

    I am not 100% sure which issue you’re referring to with respect to Subversion, but my guess is that it is related to the requirement for SVNKit and its TMate license ( which looks like BSD but it is effectively GPL.

    Mike Milinkovich

    April 7, 2010 at 9:07 am

  12. @Tonny,

    Because of the strong copyleft requirements of the GPL (and its derivatives such as the Affero GPL), it is a bit of a unique case. So I can’t think of another OSI-approved license off the top of my head which has the same set of issues.

    See Sam Ruby’s short and sweet summary of GPL license compatibility, with its clever reference to blood type compatibility.

    However, I haven’t spent a lot of time researching this and reserve the right to be misinformed 🙂

    Mike Milinkovich

    April 7, 2010 at 9:19 am

  13. IANAL

    I agree with Mike. The situation sucks but legally, you can’t combine GPL and EPL in the same product. GPL just doesn’t allow it.

    That said, it would only be an issue if the FSF sued on a license violation. So, say, some person would write a plugin which uses the SVN libraries and another person takes that and creates a bundle that already contains all the necessary libraries and uploads that somewhere, I doubt they’d get sued. It would be pointless. The goal of the FSF is to make sure that companies can’t rip off the GPL developers. So they might sue if IBM did that or the Eclipse foundation (but they’d ask politely to stop this first). But not some private person who puts that on his personal homepage or something.

    Aaron Digulla

    April 7, 2010 at 9:30 am

  14. @Mike,

    You are not the target of my frustration :-). I’m just reflecting and wondering if the inventors of the licenses did foresee the sometimes very negative impact and millions of working ours spent just to get around issues that shouldn’t need to be there in the first place. The whole concept of Open Source builds on ease of collaboration. License incompatibilities unfortunately destroys a lot of that. I doubt anyone really intended that. A doubt that makes the whole thing even more frustrating.

    Thomas Hallgren

    April 7, 2010 at 9:32 am

  15. @Thomas,

    Well, if it makes you feel any better, I believe that the licenses are working exactly as designed. But I doubt that actually makes you feel any less frustrated 🙂

    Certainly the conversations we had with the FSF about how they interpret the GPL and apply it to cases like the Eclipse platform were educational.

    Mike Milinkovich

    April 7, 2010 at 9:47 am

  16. @Greg,

    No the LGPL is not as incompatible. In many ways the LGPL is similar to the EPL in intent.

    With the normal caveats (IANAL, TINLA) I would say that it is OK to distribute EPL and LGPL components together, particularly if great care is taken to use separate directories and the like to clearly differentiate the two. However, the distribution of LGPL components is not typically allowed by Eclipse projects themselves because of the restrictions that the LGPL places on downstream re-distribution. The Apache Software Foundation takes the same position, and you can read their explanation by searching for “LGPL” on the page.

    P.S. Cutting-and-pasting code is an entirely different question. Developers should really be extremely cautious about cutting-and-pasting code which are under two different licenses.=

    Mike Milinkovich

    April 7, 2010 at 12:50 pm

  17. @Thomas,

    Subversion is Apache licensed. The issue is that, like Eclipse with GTK, it optionally links with some LGPL licensed components. The issue is not that Subversion and Eclipse are not compatible, it is that the Eclipse Foundation does not allow its projects to distribute LGPL components from That is a decision of the Foundation and not about the compatibility of the licenses. As Mike points out, the Apache Foundation places the same restrictions on software distributed from its servers.

    It is possible to build and provide Subversion binaries that do not include or use any of these LGPL licensed components. The Subversive project has simply decided not to pursue that option. FWIW, there are some tradeoffs in doing this so it is not an unreasonable decision.


    April 8, 2010 at 8:56 am

  18. @Mike,

    Jetty is now EPL licensed. Based on your answers to previous questions I believe you agree it would be OK to distribute Jetty as the servlet container for an application (WAR) with GPL licensed components.


    April 8, 2010 at 8:58 am

  19. @Mark,

    Re: Jetty – it is actually dual licensed EPL and ASL, so it is yet another case. What you have briefly described seems OK to me. But the question seems to be more of a GPL compliance question than an EPL one. You may want to direct that question to the FSF.

    Re: Subversion – I am surprised that SVN is still shipping LGPL binaries now that the project is part of the Apache Software Foundation. I would have thought that as part of moving to the ASF that they would have started to comply with the ASF’s policy on LGPL distribution. Or am I misunderstanding something?

    Mike Milinkovich

    April 8, 2010 at 11:33 am

  20. fortunately more an more open source projects are dual-licensed.
    per ex. LogBack (native implementation of SLF4J) now uses a dual-license:
    EPL and LGPL. this makes it easier to work with from Eclipse Projects.


    April 11, 2010 at 6:58 am

  21. @Mike

    Subversion has never really provided binaries. It provides a source release for distributors to use. If binaries are distributed when we do our first ASF release, they would be built without the optional LGPL dependencies as I have recommended Eclipse do in the past. There are no current plans to start providing binary releases though.


    April 12, 2010 at 9:54 pm

  22. I find it odd when people “get frustrated” by these sorts of posts. There’s nothing new about some of these issues, and, really, everyone should be thanking Mike for having the patience to interact with the FSF.


    April 15, 2010 at 9:12 am

  23. I’m pretty delayed on these discussion, but reading the article and the replies I still have a doubt.
    If I’m distributing a program that has a GUI based on SWT, which is licensed under EPL, can the program be licensed under GPL (v3)?
    It is for sure no derivative work from SWT in the EPL understanding, as the SWT code is untouched, neither it is a plugin to run on top of an EPL-licensed program.
    Also, this phrase can bee seen in the FSF’s ‘Quick Guide to GPLv3′:
    “…GPLv3 has adjusted the definition of System Library to include software that may not come directly with the operating system, but that all users of the software can reasonably be expected to have. For example, it now also includes the standard libraries of common programming languages such as Python and Ruby.

    The new definition also makes it clear that you can combine GPLed software with GPL-incompatible System Libraries, such as OpenSolaris’ C library, and distribute them both together. These changes will make life easier for free software distributors who want to provide these combinations to their users…”

    So it seems I have no restrictions in distributing my program (a jar file under GPL) along with the SWT (a jar file under EPL) toghether, as long as both licenses are seen. Am I right?


    July 14, 2010 at 3:31 pm

  24. Gabriel,

    My apologies for the slow reply. I was on vacation last week with now internet connection.

    I hate to pass the buck here, but I think that this question would be better directed to the FSF. Ultimately, whether this is permitted is dependent on their interpretation of the GPLv3.

    Mike Milinkovich

    July 19, 2010 at 9:28 am

  25. Hi Mike,
    This article is a good summary but does not precise the situation about the LGPL. As you commented later, the LGPL is not the GPL and you even wrote “it is OK to distribute EPL and LGPL components together” but on the other hand, the Eclipse Foundation seem not to allow the inclusion of LGPL in its products because of re-distribution constraints. This is a bit confusing – could you please elaborate on this ? Is it finally OK to distribute EPL and LGPL components together or not ? Thanks in advance for the explanation.


    December 2, 2010 at 9:59 am

  26. Frederic,

    As you have correctly surmised, the LGPL is a different case. And a complicated one.

    Some organizations do choose to ship EPL and LGPL together and have obviously gotten legal comfort that it is OK to do so. A good examples in the mix of Symbian (EPL) and Qt (LGPL) you see in Nokia products. The fact that they are doing so is not an issue for the Eclipse Foundation.

    However, to date the Eclipse Foundation has made the decision that the provisions of the LGPL run counter to the requirements of our commercial ecosystem. As an example, the EPL allows companies to relicense their binaries under a commercial license, while the LGPL does not.

    It is an imperfect situation, but that is where we are at the moment. The key point is that you can and should seek your own legal advice when making your decisions.

    I hope this helps!

    Mike Milinkovich

    December 3, 2010 at 2:56 am

  27. Greetings! I was curious to know if setting up a site
    such your own: http://mmilinkov.wordpress.
    com/2010/04/06/epl-gpl-commentary/ is hard to do for inexperienced people?
    I’ve been hoping to set up my own website for a while now but have been turned off because I’ve always assumed it demanded tons of work.
    What do you think? Many thanks

    Raspberry Ketone Benefits

    December 13, 2012 at 9:52 pm

  28. Hiya! I just discovered your webpage: EPL/GPL Commentary | Life at Eclipse
    when I was searching It
    looks as though someone enjoyed your blog so much they decided to bookmark it.
    I’ll surely be coming here more often.

Comments are closed.

%d bloggers like this: