Life at Eclipse

Git has been growing in popularity, and I am particularly interested in its potential to reduce barriers to participating and contributing to Eclipse projects. There has been a vigorous conversation about using Git for Eclipse projects going on for some time over in bug 257706, including my own reservations about the idea. But it is clearly time to start making some progress on this topic.

In talking with Wayne, Denis and the committer reps on the Board of Directors, it seems that the most obvious place to start would be to have Git installed on our servers and providing a read-only cache of the work of all projects. The projects themselves will continue to use CVS and SVN. (see bug 280583)

I am personally willing to consider a future where Git becomes the standard SCM at eclipse.org, but time will tell if we can get there.

How can you help?

• Give us feedback on this idea, either in the comments here or in the bugs mentioned above.
• If you are involved in an Eclipse project and you would consider switching to Git, please start the conversation with your peers. Would someone be willing to start and maintain a list of willing projects somewhere?
• Get involved in the eGit project. The faster we have a first class team provider for Git, the faster we can use more Git at Eclipse. The CVS plug-in for Eclipse does truly rock, and there are lots of people at Eclipse who will not even consider switching if Git is not supported with equivalent function and stability

I have been remiss in updating our website with information regarding some decisions made by the Board late last year. Totally my bad.

So here is some good news:

1. Projects can license their example code using the Eclipse Distribution License (EDL) as well as the EPL. The advantage to this is that it is clearer to Eclipse users that they can start with EDL-licensed example code when they are developing their products or applications. Because the EPL is a copyleft license and the definition of derivative works can be fuzzy, there can sometimes be confusion as to whether something which started its life as a piece of example code needs to be EPL-licensed or not. You can find details on how to apply this to your project in our policy document.
2. Contributors of “non-code content” such as articles, whitepapers, etc. are now allowed to use two variants of Creative Commons licenses. This should make it easier for people to contribute their works to the Eclipse Resources library and other places on the Eclipse website.

If you have any questions on how to make use of these policy changes in your project, please drop us a line at “license at eclipse.org”.

I hope these improvements help!

We have been having a debate internally at the Eclipse Foundation whether we need to add the LGPLv2 to the list of licenses that Eclipse projects can use or pre-req. Despite what you may think, this is not an straightforward conversation.

The most obvious question is why don’t we allow LGPL today? The answer might surprise you because the primary issue is not really legal, it’s business. To date, the licenses that we allow Eclipse projects to include as dependencies in Eclipse projects allow for re-licensing the binaries under a commercial license. This is a huge win for our commercial ecosystem because it means that adopters know that they can take code from Eclipse, embed it in their products and make the result available to their customers under a single software license agreement. Of course, there are also some niggling legal issues, but this is the true crux of the matter.

So to be clear: at Eclipse, the test is not simply whether we can ship a piece of code from Eclipse. The code has to also be usable by our commercial ecosystem in their products.

The flip side, as we have heard, is that in places where there really is no alternative to LGPL licensed code we are causing our adopters to go through cruel and unusual steps to construct a functioning system. I need to hear your pain.

By the way, avoiding the LGPL is not an Eclipse-only viewpoint. The Apache Foundation also excludes it.

So here is my question for the community: how big a deal is this?

I would also like to hear from commercial members as to their experiences with LGPL. Do you use it today in your products? Do your customers see the licensing as an issue?

Here are the cases that I’ve been able to dig up from IPzilla. Please let me know if there are more:

• BIRT wanted to use a version of iText which contained LGPL code. After it was rejected I believe Actuate funded the development necessary to move iText off of the LGPL pieces. As I recall, it delayed the ability to output BIRT reports to PDF by about a year. On the other hand, the project lead thinks it was really worth the effort.
• The Open Health Framework project wanted to use Phonetix and a MySQL driver which were LGPL licensed. Their rejection was actually a factor in forking those projects at OpenHealthTools.org. In other words, those projects left Eclipse.
• Apogee (content management) wanted to use SWTCalendar and JMySpell which were both LGPL. They have had a hard time replacing those components so the project has been somewhat stalled as a result.
• SMILA (semantic search) had a number of components (including beanshell) rejected due to LGPL.
• ACTF wanted to use some IDL code necessary to access accessibility functions on Linux platforms.
• OFMP (open financial market platform) had fastutil rejected due to LGPL.

One closing point: I have heard at various times that the Subversive has been impacted by the LGPL rule. That is an urban legend. By far the greater problem is the TMate license for SVNKit, which is really an almost-GPL disguised to look like a BSD license. There is just no easy way to resolve the SVNKit licensing issue.