Some New License Flexibility
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:
- 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.
- 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!
Time Flies
Today is a bit of a milestone for me, as it is exactly five years since I assumed the role of Executive Director of the Eclipse Foundation.
I had an inkling that this was going to be a different kind of role when a few days before I even started a journalist by the name of Darryl Taft called my home to ask me if it was true I was taking the job. Being totally caught off guard, I think I said something dumb like “no comment”. Not an auspicious beginning for a very public position.
It is hard to over-state the early challenges we had getting the Eclipse Foundation up and running. Five years ago we had about fifty members, no staff, no bank account, no offices and the heat was on to take over the creaking IT infrastructure that was still hosted at IBM. The development and IP processes existed in paper form but had never even been tried for real.
Today we have over 170 members, seventeen wonderful staff in three locations and great IT infrastructure. Our development and IP processes have been refined through several iterations and are demonstrating real value to the committers, members and ecosystem at Eclipse. These processes are definitely not perfect, but they get the job done.
But the true excitement of being part of Eclipse has been seeing the original vision of a vendor-neutral open source foundation at the centre of a commercial ecosystem coming to fruition. That was the original vision of people such as Skip McGaughey, Dave Bernstein, Danny Sabbah and John Swainson. I am sure that there are others, and I apologize for not listing everyone. Those “founders” if you will deserve a lot of credit for getting the Foundation created and the Bylaws, etc. written.
Sure, we have no shortage of challenges, but today there exists a multi-billion dollar ecosystem with hundreds of companies and millions of developers using Eclipse. The growth in projects at Eclipse has been awesome to watch as well. The breadth of technology being developed at Eclipse would have been hard to even imagine five years ago. That is awfully darn cool.
This is a pretty tough job. It involves dealing with many different interests and trying to find workable solutions. Anyone who has known me for a long time will tell you that I am not a natural politician. But this has been the single most exciting job I’ve ever had and I look forward to the challenges of the next five years. We are not resting on our laurels here at the Eclipse Foundation. The best is yet to come.
EPL ~= ASL
Boy, am I on some kind of blog binge this week. It’s amazing how a few weeks without travel helps.
Dana Blackenhorn wrote a piece earlier today discussing Matt Asay’s article on why the Apache license is better than the GPL. In his article, he states the following:
If your company wants to release its own code, and control that code, if open source is mainly a marketing concept to you, then a BSD license such as Apache or Eclipse makes perfect sense.
Dana’s statement makes an error that I have seen repeatedly. Namely, that the EPL is a “BSD-style” license and is therefore similar or equivalent to the Apache license. This is just plain wrong. And it worries me that a long-time open source observer such as Dana would make this mistake.
The EPL is what is sometimes referred to as a “weak copyleft” license. It most certainly is a reciprocal license in the same way that the LGPL and the MPL are, for example. (The European Union describes the EPL as a strong copyleft license, in its paper describing license compatibility with the EUPL.)
In our view, the copyleft provisions of the EPL gives our community the best of both worlds. Yes, changes and modifications to EPL-licensed code need to be contributed back. This helps ensure that everyone involved is incented to make their contributions back to the platform, and encourages community building. But at the same time, because the EPL (a) does not define simply linking to it as creating a derivative work and (b) allows re-licensing of binaries under commercial terms, it encourages commercial adoption.
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.
Licenses Matter
I’ve been thinking about posting on this topic for a while, and recent posts by Greg Stein and Eric Raymond have finally motivated me to get off my butt and git ‘er done.
As I mentioned recently, the EPL is on a bit of a roll at the moment. And that is a very good thing. However, what I find interesting is that – and this is implicit in the words of both Greg and Eric – is that many in the open source community believe that there are only two interesting positions in the licensing debate: GPL or BSD/Apache. A position which I believe is just plain wrong.
Here is the reason: business models are driven by licensing models. And there are many more business models under the sun than those supported by only those two bipolar licensing positions. In particular, “weak copyleft” licenses such as the EPL are great licenses for those who want to build a ubiquitous software platform with a commercial ecosystem. That is because it allows for commercial licensing of products built on top of EPL-licensed code while also requiring modifications to the platform itself be contributed back to the community. This balance is particularly useful for companies and entrepreneurs that want to create industry platforms.
Of the two, I would have to say that Greg is the most wrong, because he bases his argument on the notion that developers should pick their license based on their personal philosophy. And apparently developers only have personal philosophies that fall into either completely permissive or completely free, with nothing in between. He got it particularly wrong with his closing comment:
Middle-of-the-road licenses like MPL, EPL, and CDDL are wishy-washy. They can’t decide to be permissive, or to maintain Freedom. Choose a philosophy.
Companies and (many) developers do not pick licenses based on a philosophy. They pick them based on their desired business model. I am certainly willing to agree that some people are not interested in thinking through the economic results of their choices. I’m not willing to agree that applies to everyone.
I agree with the content of Eric’s post because find Eric’s economic arguments quite persuasive. I do believe that open source software production is more efficient. But I do not expect that commercially-licensed software will disappear for a very long time, if ever. Personally I believe that the eventual steady state is one where open source platforms provide a commons of infrastructure that supports a wide variety of commercially licensed software and content. However, in one of his comments, Eric pointed to the BSD as the “classic choice”. I would assert that the EPL and similar licenses provide equal, if not better, benefits.
I am a big fan of rational choice economists such as Steven Levitt and Tim Hardford. EPL-like licenses send the correct economic signals to rationally incent the behaviour that I want to see: commercially profitable ecosystems built on top of vibrant open source platforms.
Life at Eclipse 