Archive for the ‘Foundation’ Category
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.
2010 Election Results
I am pleased to announce the results of the 2010 Board elections.
The elected Committer Member representatives for 2010 will be:
- Chris Aniszczyk
- Boris Bokowski
- Ed Merks
The elected Sustaining Member (e.g. Solution and Enterprise Member) representatives for 2010 will be:
- Hans Kamutzki
- Mik Kersten
- Adam Lieber
Please join me in extending a hearty congratulations to the winners!
I would also like to extend a warm “thank you” to the remaining candidates: Hans-Joachim Brede, Bjorn Freeman-Benson, Shawn Pearce, Doug Schaefer and Yves Yang.
In addition, I would like to recognize Hans-Joachim Brede (Bredex), Doug Gaff, Shawn Pearce (Google) and Mike Taylor (Instantiations) for the past service they provided to the Eclipse Foundation as Directors. They have all been excellent representatives for our community. They will be missed.
Oracle Keynote on Java Technology and Community at EclipseCon
This year’s EclipseCon has a little bit of that “right time, right place” magic going for it. As a significant conference soon after the oft-delayed closing of the acquisition, it provides a good opportunity for Oracle to talk directly to developers about where they are going to take Java. There is both a technology and a community story to be told, and from the abstract it appears that Steve Harris and Jeet Kaul are going to be tackling both topics. Steve and Jeet are the development execs responsible for driving the Java platform and I, for one, can’t wait to hear what they have to say. Phrases like “rational optimism”, “profound opportunity” and “empowered community” in the abstract have certainly captured my interest.
If you’re looking forward to hearing about the Oracle-Sun strategy for Java’s future, EclipseCon will be the place to be. We’ve extended the early bird registration rates for one extra day, until Monday February 15th, so register now! See you at EclipseCon.
2010 Elections: Candidates Posted
The candidates for the 2010 Eclipse Foundation Board of Directors are now posted. There are five nominees for Committer Rep and five nominees for Sustaining Member Rep, each group competing for three available seats.
We will have the candidates full bios and positions up by February 8th. Voting opens on February 22nd. You can find a full description of all of the key dates here.
I hope to see lots of community members getting involved in the discussions!
The Two Solitudes
I don’t think you can go to school in Canada and not read Hugh MacLennan’s the Two Solitudes. So for me it was an obvious metaphor for a phenomenon that has become apparent to me over the past year or so. That is: Europeans and Americans (particularly Californians) view the practice of software development in materially different ways.
I travel a lot to both Europe and California and I talk to a lot of people about what they are building and how they are building it. In my personal and completely unscientific experience the difference between the two regions is stark. I thought it might be interesting to explain what I am observing and see if others see things in a similar way. I freely admit that my experiences could be completely coloured by sample bias (e.g. maybe I’m just talking to completely different crowds in the different regions).
BTW, some of these ideas are distantly related to Michael Cusumano’s book The Business of Software, where he points out that the US is somewhat unique in looking at software as a business. Certainly there are not that many European independent software vendors relative to the US.
It seems that most of the Europeans I talk to are focused on large systems engineering problems. As a result, they largely view software as part of a supply chain, where what they are working on is going to either be part of or in support of a systems engineering product such as an automobile or an airplane. The next largest group that I talk to are fairly typical application developers working in large banks, insurance companies and the like. But here are the interesting bits:
- Both of these groups are deeply concerned about software complexity and both are looking to modeling and model-driven development as part of the solution. They view modeling as absolutely strategic to their future ability to develop the software their customers or businesses will need.
- I also see a lot more interest in desktop applications as opposed to web applications. Just recently I had two different conversations with groups that are migrating existing web applications to Eclipse RCP desktop applications. This is not to say that Europeans don’t build websites or use RIAs! But in my experience there is a very noticeable difference in the relative interest in desktop applications in Europe.
Now if you’re still reading this, you’ve likely guessed where its going next. My experiences in the US generally and even more so in California is that the Web is king and that anything which doesn’t run in the browser is uninteresting. I also uniformly get incredulous reactions if you ask someone in the US if they’re using modeling or model-driven development practices. They’re all hacking code with small, fast, super-smart teams. It’s just a completely different world in my personal experience.
Do others have similar observations?
The challenge for Eclipse in this context, of course, is to be relevant in both contexts. I actually think that we are doing a good — but not yet great — job of doing so. Projects like e4 are leading the way to making the Eclipse platform more relevant in the Web 2.0 world. But it certainly has a ways to go. The Modeling project has a virtual alphabet soup of technologies in it, but at the moment falls short of a providing a cohesive modeling platform. Something I hope to see the community begin to address shortly.
Life at Eclipse 