Life at Eclipse

If you are a Java developer, Christmas came early this year.

Today Google announced that they are making many of the key assets that they acquired from Instantiations. Specifically, GWT Designer, CodePro AnalytiX, WindowBuilder Pro and WindowTester Pro are now all available for free from Google. Many thanks to Google for taking this step! I expect that today’s announcement will significantly improve the productivity of millions of Java developers using Eclipse.

This is a big deal for Java developers. These are professional-quality tools from which Instantiations made a very nice business for many years. And free is a great price. I expect to see lots of happy developers using them, and soon. There were certainly many very happy and congratulatory comments on the announcement.

This is also a big deal for Eclipse. These tools provide a great boost to the productivity of developers using the Eclipse platform. The most obvious example is in the area of GUI building. Let’s face it, the “available for free” GUI building story on Eclipse has been painful for a long time. (Just take a look at the commits meter.) Having this suite of tools available for free can only help to increase the value of the Eclipse platform to the community of Java developers. And with support for Swing, SWT and GWT you can use whichever Java-based UI framework that best meets your requirements.

All in all, a great day for Java developers!

We are announcing today the creation of the Application Lifecycle Tools Top-Level Project, which will retain the well-known Mylyn nickname. From the charter: “Mylyn is an open source collaborative software development project dedicated to providing an extensible, standards-based platform to address a broad range of needs of accessing task and application lifecycle management tools and services using the Eclipse platform.” Also check out Mik Kersten’s blog post on this.

This is important news for the Eclipse community, as it creates a centre of gravity for the application lifecycle tooling projects at Eclipse. Down the road, we hope to see an even more vibrant ecosystem of projects and adopters leveraging Mylyn as their ALM platform.

This is also a great example of a project growing and maturing at Eclipse. Mylyn (nee Mylar) started as Mik Kersten’s PhD thesis project. After the successful completion of his doctorate, Mik brought Mylyn 1.0 to Eclipse as an incubator project, where it was an immediate success with the community. Mylyn has certainly been one of the most popular innovations within the Eclipse tools community over the past several years and continues to be an important differentiator of the Eclipse IDE. After exiting incubation, Mylyn moved to the Technology PMC where it built out its frameworks and APIs, then to the Tools PMC, where it grew to be one of the most active and accessible projects at the Eclipse community. There have been over 900 code contributions to Mylyn by non-committers, with 1/7th of Bugzilla bugs and enhancement requests solved by community contributors. That is an outstanding record of community involvement.

Largely because of its popularity, over the past several years Mylyn has created its own ecosystem of extensions. You can find Mylyn connectors for most bug tracking and SCM environments. Furthermore, it started getting used as an integration point targeted by projects at Eclipse. Mylyn has truly become the de facto ALM integration framework at Eclipse. And in doing so has grown and matured to the point where making its own top-level project is the logical next step. Stay tuned for some further announcements over the next couple of weeks concerning both new and moving projects as part of this restructuring.

Please join me in offering hearty congratulations to project lead Mik Kersten at the Mylyn committers and contributors who made this possible. I look forward to having new participants in this top-level project to continue to innovate and expand Eclipse’s IDE role as the best, most extensible, and most innovative tool platform.

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.