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.
