Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Archive for April 2009

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.

Written by Mike Milinkovich

April 30, 2009 at 6:45 pm

Posted in Foundation, Open Source

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.

Written by Mike Milinkovich

April 30, 2009 at 9:39 am

Posted in Foundation

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.

Written by Mike Milinkovich

April 27, 2009 at 2:27 pm

Posted in Open Source

Value of Open Source

Last evening I was in Toronto for the “Value of Open Source” panel at the University of Toronto’s School of Computer Science. The panel was one of a series being organized by the Free and Open Source Software Learning Center (FOSSLC).

The evening was almost more of a conversation than a traditional panel, with moderator Andrew Ross letting the audience largely drive the discussion. But it was a lot of fun and the feedback afterward was very positive.

As an aside, Mark Surman of the Mozilla Foundation was there on the panel. Richard Dice of the Perl Foundation was in the audience. It hadn’t really occurred to me before, but the Executive Directors/Presidents of Eclipse, Mozilla and Perl Foundations are all Canadians. Small world, eh?

The most challenging audience question came from Greg Wilson of UT who wondered about the missing gender in open source: women. I’m not sure of the source of his numbers, but as I recall he said that about 1 in 7 CompSci undergrads are women, while only 1 in 200 active open source committers are. I found those numbers quite startling, although I have certainly heard about the issue before. Although I believe that we have more than 1/200 in the Eclipse committer community, I don’t think we have 1/7. (The Eclipse Foundation itself is 7/17 which is probably close to most small software companies.) Ironically, there is really no easy way for us to tell because gender is not one of the things we track in our committer records. I guess the question to our community is: should we? Is there something the Eclipse Foundation could or should be doing on this front?

Thanks to Andrew Ross and the folks at Ingres for organizing and sponsoring the event. Also, thanks to Karen Reid for hosting the evening.

Written by Mike Milinkovich

April 24, 2009 at 2:28 pm

Posted in Foundation

Best Wishes

As you have probably read by now, this morning Bjorn announced his resignation from the Eclipse Foundation. I know I speak for everyone here at the Foundation and in the broader community that we wish him well wherever his path may take him.

Bjorn has made enormous contributions to the Eclipse community. Our development processes and lifecycle reflect his contributor-first philosophy. EclipseCon and Eclipse Summit Europe operate flawlessly and are world-class developer conferences. He built and led a great team (Anne, Karl, Gabe) in Portland. And those are but a few highlights of what he has accomplished while part of the EMO.

On a personal note, I have to thank Bjorn for all of his support over the past five years. I believe it is true to say that without him I wouldn’t be in this job. For that I am forever grateful.

Bjorn is one of those restless geniuses that never stops challenging your assumptions and forcing you to do better than you thought you could. He will be missed here at the Eclipse Foundation. Hopefully he will land a role somewhere within the Eclipse ecosystem so that his contributions to all of us can continue.

Looking forward, Wayne Beaton is going to move over to the Committer Community role and lead Anne and Gabe’s activities in support of our project and committer community. He will still be involved in evangelizing Eclipse, but now with a tighter tie into the projects.

Best wishes Bjorn.

Written by Mike Milinkovich

April 20, 2009 at 7:22 am

Posted in Foundation

2008 Retrospective

I wrote this retrospective recently for a Board committee, and Doug Gaff gave me the excellent suggestion that I blog it. I am sure that it is of interest to many in the community.

The following is a listing of the 2008 objectives set by the Board for the Foundation staff, and some thoughts on our accomplishments. I have to say that I think 2008 was a pretty darn good year for the team. Perhaps not an outstanding year, but an awfully good one. We got a lot of things done, and have really set the stage for future growth.

I am sure that I have forgotten some major accomplishments. My apologies in advance!

2008 Annual Objectives Completion

1. Help ship a great Ganymede release train

Thanks to a lot of great work by the project committers, the Ganymede release train went off without a hitch and by any measure was a great success. The Foundation staff contributed to that success in a number of significant areas:

  • Bjorn and team built and ran the Ganymatic build system that was used by the group. He also chaired the regular conference calls and ensured that the process ran smoothly.
  • Janet and team reviewed all CQs in time to ensure that there were no unresolved IP issues.
  • Ian and team executed on the marketing release plan, including the very successful Ganymede DemoCamp program.
  • Wayne executed a series of podcasts to raise awareness of the new features.
  • Denis and team made sure there were no infrastructure issues and that all of the systems were ready for the onslaught of downloads.

2. Maintain the financial and organizational health of the Foundation

There is a lot of work that happens behind the scenes to ensure that the Eclipse Foundation is a well run business. The fact that we’re a not-for-profit doesn’t mean that good management isn’t required to ensure that we keep the lights on, and our services to the community running. Here are few highlights:

  • We noticed the economic downturn in the autumn of 2008 and took immediate action to reduce expenses
  • Converted a significant portion of our reserve funds to CAD at a great exchange rate to reduce our exposure to currency fluctuations. (For those who don’t know, Eclipse’s membership revenue is in USD. But most of our staff, and thus our expenses, are actually in Ottawa, Canada.)
  • Retained all staff and did well on the staff satisfaction survey at the end of the year.
  • Achieved 99.966% uptime on all core IT infrastructure. (Which is pretty cool given that we have such a small IT team. Congrats to Denis, Karl and Matt!)
  • Deployed donated AMD servers to increase capacity and redundancy.
  • Achieved the 2008 financial budget in all material respects.

3. Grow membership and communicate membership value

The membership of the Eclipse Foundation is what funds Eclipse and what supports the operations of the Eclipse Foundation. If you (the reader) work at a company which supports Eclipse through being an active member please accept our deeply felt “thank you!” for your generous support.

  • Finished the year with 190 members. The goal was 180.
  • Implemented the placement of strategic developer logos on the eclipse.org home page.
  • Completely re-did the members content and membership benefit content on our website.
  • Implemented a major overhaul of our Bylaws and Membership Agreement to enable Enterprise Membership. This was the first time we had ever run a vote of the Membership to amend the Bylaws and Membership Agreement, so it was a significant undertaking.
  • Implemented automatic linking of projects that a member contributes to on their membership page. (See IBM’s for an example.)
  • Added member logos to the project pages to recognize their contribution. (See DSDP TM’s for an example.)

4. Implement programs to focus growth in industry verticals

Much of the future potential growth of Eclipse is in industry verticals. Our strategic direction is to take the Eclipse model of collaborative open development to these industries and help them be successful in using open source to create industry platforms.

  • Implemented the processes for the creation and lifecycle management of Industry Working Groups. This included gaining Board and Membership approval of changes to the Bylaws and Membership Agreement to restructure our membership classes.
  • Created our first IWG: Pulsar (Mobile tools)
  • Executed successful Eclipse Banking Days in Frankfurt and New York.
  • Had the initial meeting to kick off the Eclipse Automotive IWG.
  • Had initial conversations with companies interested in insurance, semi-conductor and network carrier industry working groups.

5. Sustain and grow our technical community

Eclipse lives or dies based on how vibrant our technical community is. Ensuring that we have sustainable growth in our project and committer population is a big part of what we try to do at Eclipse. To all of the developers (member employees, individuals and students) who work on or contribute to Eclipse projects thank you for your energy and enthusiasm. You are what keeps Eclipse fresh and exciting!

  • Executed a very successful EclipseCon 2008, with a lot of positive feedback on the technical content. Thanks go to Bjorn, Anne, Donald, et al that helped make EclipseCon a success!
  • Executed a very successful Eclipse Summit Europe, with a lot of positive feedback on the technical content. Thanks go to Bjorn, Anne, Ralph, Lynn, Donald, et al that helped make ESE a success!
  • Grew by approximately 40 new projects in 2008.
  • Pruned our committer rolls of inactive committers.
  • Introduced the notion of “committer emeritus”
  • Got Babel up and running to crowdsource translations for Eclipse projects.
  • Organized two series of DemoCamps in 2008 that featured events in at least 20 cities.

6. Foster Eclipse’s growth as an OSGi-based multi-tier runtime platform and community

I think that this is pretty self-explanatory. 2008 was the year that Eclipse runtime technology really took on its own identity. Which is major step forward.

  • Supported the creation of the Eclipse Runtime top-level project.
  • Planned and implemented a new Equinox community portal.
  • Planned and executed the launch on the Eclipse RT top-level project; had at least 5 positive press articles based on this launch.
  • Organized an Equinox/RCP/OSGi training series with Eclipse Member companies.
  • Focused on runtime topics as part of our Ganymede launch PR messages.

7. Improve committer satisfaction with Foundation processes and procedures

I know Eclipse has a lot of processes. In many ways those processes are what differentiates Eclipse and helps make it a unique place. But at the same time those processes can run the risk of creating unnecessary barriers to entry to participation and contribution to Eclipse. Balancing all of the interests is tough, but I really think that in 2008 we made some significant enhancements.

  • Executed a complete re-write of the Foundation’s IP Policy, including support for parallel IP for all projects, not just incubating ones.
  • Implemented automatically maintained IP logs for all projects.
  • Drafted and got Board approval for a revised and simplified development process.
  • Implemented xml project plan infrastructure to streamline the process for creating the annual Roadmap.
  • Implemented IPzilla enhancements to allow private conversations on IP issues between the EMO and the project leadership community.
  • Steady improvement in the portal applications to give committers better service and more options for self-service.

8. University outreach program

We actually accomplished a lot on university outreach in 2008. I don’t think we necessarily did a good enough job in communicating everything that we did, so hopefully the links below will help a little in that regard.

  • Google Summer of Code initiative was a great success in 2008, with 22 student projects.
  • Creation of the IDE4EDU project which provides a stripped down version of the Eclipse IDE targeted at students.
  • Developed a strategy for university outreach, and started engaging universities to raise awareness.

Written by Mike Milinkovich

April 17, 2009 at 11:38 am

Posted in Foundation

One Small Step Towards Reducing License Proliferation

OSI Certified

License proliferation has been a hot topic amongst the open source community for the past couple of years. I am happy to report that the Eclipse Foundation and IBM have collaborated to do our bit to help by superseding the Common Public License (CPL) with the Eclipse Public License (EPL). This means that the CPL will no longer be considered an active open source license.

Perhaps the best way to explain this is via a Q&A:

1. What was actually done?

There was a two step process that was followed to make this happen. First, following the terms of the CPL, IBM assigned the responsibility to serve as the Agreement Steward of the CPL to the Eclipse Foundation. Second, the Eclipse Foundation officially recognized the EPL 1.0 as the new version of the CPL 1.0. In OSI license terminology, the EPL now supersedes the CPL.

A quick read of the two licenses will quickly show that they are very very close. Other than their names and (previously) their Agreement Stewards, the only substantive difference is the breadth of the patent license termination in the event of a patent law suit. (See the second paragraph of Section 7.) For more information on the relationship between the CPL and the EPL see the EPL FAQ.

2. What does this actually mean?

For those projects that are currently using the CPL and wish to continue using it, not much. However this will open up an additional option for those CPL-licensed projects wishing to migrate to the EPL.

Using OSI’s classification of licenses, it means that the CPL will move from the “Licenses that are popular and widely used or with strong communities” to the “Superseded licenses” category as maintained by the OSI. It does not mean that the CPL has disappeared. However, it is the recommendation of the OSI, IBM and the Eclipse Foundation that new projects use the Eclipse license rather than the CPL if this “style” of license appeals to you. See below for more details if you have an existing CPL-licensed project.

3. Why was this done?

License proliferation in open source is a real issue. It costs businesses to review multiple licenses, and the plethora of licenses can be confusing to someone starting a new open source project.

Over the past five years we have seen the Eclipse Foundation go from a good idea that might work to one of the most successful open source communities out there. We have seen the Symbian Foundation adopt the EPL as its license, thereby bringing a huge community and code base in its own right to the EPL, plus demonstrating the utility of the license well outside of the Java domain that it is best known in. More recently, Google also added the EPL as one of the licenses it supports on Google Code. It is clear that if we wanted to consolidate on one license, that the EPL made the most sense.

4. I have a CPL-licensed project. What do I need to do?

You can continue to use it if you want to, although the whole reason we’re making this happen is because we wanted to provide projects with an easy option to migrate to the EPL to help reduce license proliferation.

There is a very simple path to moving your CPL-licensed project to the Eclipse Public License. Since the EPL has been denoted as the successor version of the CPL, you can use a provision in Section 7 (“In addition, after a new version of the Agreement is published, Contributor may elect to distribute the Program (including its Contributions) under the new version.”) to easily switch to the EPL.

5. When does this take effect?

Immediately.

6. Wait a second! The CPL also says “Each new version of the Agreement will be given a distinguishing version number.” How can the EPL 1.0 be a new version of the CPL 1.0?

Well, you’re right. We could have created a CPL 1.1 that simply pointed to the EPL 1.0. But frankly that seemed a lot more confusing than helpful. Especially since the licenses effectively differ by about one-and-a-half sentences. However, more importantly, the EPL is indeed the successor version to the CPL. The Eclipse Foundation and its members developed the EPL from the CPL by modifying those one-and-a-half sentences. The name of the license doesn’t change that history.

Written by Mike Milinkovich

April 16, 2009 at 1:57 pm

Posted in Foundation

Follow

Get every new post delivered to your Inbox.

Join 2,995 other followers