LGPL Pain
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.
Life at Eclipse 
Mike, the TMate License also has an option for commercial adopters if they want to use it. Sure they are requested to pay for the right to use it, but there is an option. This is no different than other licenses that may be used. The Commercial adopter has to do their own leg work at times on the licensess and their comfort level with adopting those licenses.
The XSL Tools project has been denied bringing in the DocBook XSL stylesheets due to it’s varied use of a variety of licenses. However these stylesheets are being used by many commercial applications, and distributed by many Commercially available applications like Oxygen XML.
As you said, whether a license is acceptable to a company is a business level decision. In many cases rejecting a license causes Eclipse to have to re-invent the wheel, create more code to maintain, and makes it much more difficult to deliver features faster to the user community and adopters. Not every company will fund it, and it can also keep necessary code contributions from reaching eclipse. Your example of the Apogee is a great example.
Projects will seek to be hosted at Sourceforge or other places where the licensing burden is put on the adopters and not the developers. A balance has to be struct. As always a project should list the licenses of the code that it adopts so that its community can determine for itself whether they want to use it or not.
IP Review should still occur though.
Dave Carver
April 30, 2009 at 10:16 am
Let me add a few Teneo and others projects wanted to use Hibernate and that could not happen.
ECF wanted to use JGroups and couldn’t.
Dali wanted contributions from Hibernate Tools but that could not happen, once again because of LGPL.
And then of course the exception to the rule the SWT integration on Linux is already using LGPL based libraries – so apparently the license is already accepted ?
Max Rydahl Andersen
April 30, 2009 at 10:54 am
You can soon add UFaceKit to the list of modules who want to make use of LGPL-Code because at the very moment Nokia-Releases their QT-Java-Stuff under LGPL I’m going to file a IPZilla for it. Staying with QT which is going to be LGPL this might be interesting for the CDT guys, … . Another LGPL library UFaceKit wants to use is SwingX.
Other examples are probably those projects who want to use Hibernate (e.g. Teneo, CDO) which is under LGPL but for me (as project lead of UFaceKit) as of now LGPL is important because of QT and because of SwingX.
Tom Schindl
April 30, 2009 at 12:01 pm
@Max, @Tom, Thanks for the pointers. That is exactly the kind of information I’m looking for.
@Dave, I understand the points you’re making. We have these conversations endlessly at the EMO, on the IP Advisory Committee and on the Board. We are trying to balance the needs of many constituencies and the policies reflect those balances.
You and I will have to agree to disagree on whether the TMate license is anything like the other open source licenses used by Eclipse projects. Nothing we ship today would require any downstream distributor to pay royalties to some vendor.
Mike Milinkovich
April 30, 2009 at 2:24 pm
@Max – Re:SWT on GTK, the only LGPL artifacts used are header files, which are a bit of special case under the LGPL. We don’t distribute any LGPL source code AFAIK.
With respect to contributions to Dali, any contributions to an Eclipse projects have to be under the EPL unless unanimously approved by the Board. I am not talking about hosting LGPL project development at Eclipse, only about making use of LGPL artifacts developed elsewhere.
Mike Milinkovich
April 30, 2009 at 2:38 pm
What about allowing for libraries that also have a commercial license? This way people willing to use in their commercial project would have the possibility to by just paying.
Pascal Rapicault
April 30, 2009 at 2:58 pm
@Pascal: Sorry but I don’t understand your question. What do commercial licenses have to do with the LGPL?
Mike Milinkovich
April 30, 2009 at 4:05 pm
Can’t let this one go by without commenting. 🙂
At Wind River, we ship gcc and a good chunk of Linux with our embedded Linux product, and we even ship gcc for use with vxWorks. Licensing is probably more a concern for many of our vxWorks customers and we ship our own commercial compiler for those that don’t want to use gcc. But you can’t do commercial embedded Linux development without using LGPL libraries and GPL executables. But that’s just our world and I understand the needs of other vendors to keep things GPL/LGPL free.
But I think Eclipse needs to come clean. Is it the rule that everything at Eclipse must be consumable by all members of Eclipse. That does imply that LGPL is a non-starter. And I don’t have a problem with that. Those members pay for most of the development that happens at Eclipse and it needs to meet their business requirements to justify that investment.
But, then, be clear about it, or at least more clear that we have. If you have a project and you are faced with a technical decision that violates these rules, then you need to make a different decision or find somewhere else to host your project. And many projects have already decided to go somewhere else and you’ll find a lot of Eclipse related projects out on SourceForge and elsewhere.
My concern, and maybe this is yours as well, is that this really creates two Eclipses. One that meets the members business needs, and one that is truly a collection of open source projects where the committers are free of these concerns. Let’s make that call, and if there has to be two Eclipses, I’d like to see the second one get organized so that we can have a strong ecosystem for both sides. (And, BTW, change this one to eclipse.com ;).
Doug Schaefer
April 30, 2009 at 4:36 pm
Related discussion that may (mostly) apply to Eclipse:
http://www.apache.org/legal/ramblings.html
If you want to chat, let me know, and I’ll gladly set aside some time.
Sam
April 30, 2009 at 6:44 pm
@Sam – I love the article! Obviously, Eclipse does not aspire to be a “universal donor” (our license does not make that possible), but there are many thoughts there that are very helpful, and which apply to Eclipse as well as Apache.
I will contact you and arrange a time to chat.
Thanks!
Mike Milinkovich
April 30, 2009 at 7:04 pm
I believe Pascal is suggesting that one would allow projects to redistribute LGPL licenses where those packages are also licensed under a commercial license so that if a consumer doesn’t want to deal with the LGPL they have the option of purchasing the software under a commercial (non-LGPL) license.
Adrian
April 30, 2009 at 7:24 pm
@Adrian – I don’t think that we want to start distributing commercially-licensed software from Eclipse. Even if you ignored all open source scruples, I don’t know how we could distribute commercially licensed code in a vendor-neutral way. Or am I misunderstanding the scenario yet again?
That said, perhaps using p2 to help users install code under various licenses, where portions come from other servers (e.g. _not_ eclipse.org) might be a solution that solves all of the constraints. End users get what they want with ease, and the Foundation isn’t distributing the code in question.
Mike Milinkovich
April 30, 2009 at 8:08 pm
@Doug – I would like to refer you to the Purposes definition of the Eclipse Bylaws: “The purpose of the Eclipse Foundation is to advance the creation, evolution, promotion, and support of the Eclipse Platform and to cultivate both an open source community and an ecosystem of complementary products, capabilities, and services.” You can even see our commercial interest directly in the Eclipse Public License where it says “…this license is intended to facilitate the commercial use of the Program…”.
In other words, Eclipse has *always* been about balancing the needs of both our projects and our ecosystem. This has always been true, and should not be news to anyone.
This does not create two Eclipses. This has been the balancing act that we have been in since the day the Eclipse Foundation started. And far from being a problem, I believe the marriage of a vibrant open source project community to a commercial ecosystem is our greatest strength. Of course it keeps our jobs here pretty interesting at times :-).
To answer your question, I would not say that it is the rule that everything at Eclipse must be consumable by *all* members of Eclipse. But I do believe that every project at Eclipse needs to be consumable by a significant number of commercial adopters. What we ship from Eclipse is intended to be useful to commercial adopters. Eclipse is not SourceForge. If you actually just want to hack code and not care about adoption by the Eclipse ecosystem then you’re right: your project likely belongs elsewhere.
Mike Milinkovich
April 30, 2009 at 8:12 pm
@Mike – I also played with the idea of moving suspicious 3rd party bundles (e.g. some JDBC drivers, etc. ) to a not_eclipse.org p2 server. If I remember correctly this approach suffered from three main problems/complications:
1. Legal:
I think I’m not allowed to add such discovery URLs to my eclipse.org features. (is that correct??)
2. Repository:
I don’t really want to operate such a p2 repository on my own.
Users would certainly prefer a single repo be configured locally (not one per Eclipse project).
3. Build System:
Our builds are already at a level of complexity that I’m not very keen on adding synchronization of some output artifacts with outside locations. I guess I’ll have to do it anyway and I hope that the Eclipse.org firewall policies won’t require me to have manual distribution steps in my builds.
Eike
May 1, 2009 at 2:36 am
@Mike: You’re right. I took an extreme position and I know you are working hard on trying to make this happen. But what frustrates me is that Wascana is no different than the commercial product that many Eclipse members in the embedded space ship to their customers. In that light, Wascana would be something that members can take and put in their products. And, yes, I believe that number would be “significant”. The explosion of embedded Linux into the commercial space certainly brings the argument against GPL into question.
@Eike: That’s exactly what I’m doing with Wascana. The p2 repo is at SourceForge. That’s why I wonder if whether it would be a good idea to host the master p2 repo off site. Users would prefer a single repo, but why does it have to be on eclipse.org? Hmm, this is starting to gel into a new blog post…
Doug Schaefer
May 1, 2009 at 8:40 am
Mike said, @Max – Re:SWT on GTK, the only LGPL artifacts used are header files, which are a bit of special case under the LGPL. We don’t distribute any LGPL source code AFAIK.
You distribute .so files which IMO is comparable to i.e. a jar file in Java.
See http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.gtk.linux.x86/about.html?revision=1.10&view=markup for the glory details.
You say you dont distribute LGPL source code and that is probably true, but if that is the only hinderance then I dont see why using Hibernate or any of the other libraries here as binaries is not possible ? I know it is not as simple as that but just saying that the SWT bindings are just as much LGPL code and binaries as i.e. a hibernate library is.
About Dali then yes, the main code that would be contributed would of course be EPL but since it used parts of LGPL libraries it was not possible.
Max Rydahl Andersen
May 1, 2009 at 9:07 am
@Eike, the answers to your questions are:
#1: We are working hard to make this possible. The Pulsar initiative needs this, for example.
#2: Depending on how we do in writing the policy for #1, it may be possible to do this at Eclipse. Or not.
#3: I haven’t thought about the build problem. But if we fix #1 and #2, I think we can figure out this one 🙂
Mike Milinkovich
May 1, 2009 at 9:42 am
@Mike, the idea would be that Eclipse would only redistribute the LGPL package. The commercial license would be an option for those that find the LGPL unpalatable. However I’m just providing clarity on what I believe Pascal was saying. I don’t think it makes the situation any better and there are many problems such a concept introduces. For example, the commercial terms may also be unpalatable in many ways.
Adrian
May 1, 2009 at 11:18 am
@Mike, for clarity: while the SWT GTK+ Binding is binary in Eclipse binary distributions, the Java source code of the bindings is LGPL and they live in CVS and in Eclipse source distributions. However I would argue that most people do not have a reason to redistribute that source.
Adrian
May 1, 2009 at 11:23 am
The User-friendly Desktop Internet GIS project (http://udig.refractions.net/) is one of the first Eclipse RCP application and has been held up on this issue.
The project has considered joining eclipse, and recently the eclipse labs. The difficulty is the use of the GeoTools library which is LGPL, JTS Topology Suite which is LGPL etc… These libraries are where all the hard math is actually done and it takes many years to produce a numerically stable result. GeoTools for example is 14 years old.
So replacing these libraries is not an option; leaving us out of the Eclipse ecosystem. With respect to eclipse labs we are also held up by GIT not being offered (which seems to be the direction the wind is blowing).
Jody
July 15, 2010 at 8:59 pm
Jody, have you considered asking GeoTools and other projects to dual license their work as LGPL/EPL or just go to EPL (which is in the same “spirit” as LGPL imho)?
It would be great to see some of your work at the Eclipse Foundation.
Chris Aniszczyk
May 24, 2011 at 3:39 pm