Life at Eclipse

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.