Life at Eclipse

As we started talking about back in February, the Eclipse Foundation is doing a major overhaul of our IP processes. With the Kepler release now firmly in its end-game, the time has come to start rolling this out.

In February, I identified three major pieces of work that needed to get done:

• First, we are going to implement Contributor License Agreements (CLAs) for all contributors at Eclipse. The CLA will be a short document that essentially asks The Three Questions once. We will collect some information about the contributor so that we have a record on file of who is giving us code or documentation. Note that the Eclipse Foundation CLA will be quite different from those in use at other organizations. For example, Apache’s CLAs basically give the ASF a license equivalent to ownership for contributions. The Oracle Contributor Agreement (OCA) used by OpenJDK community gives Oracle joint ownership of contributions. The Eclipse CLA is much more modest. In terms of licenses, all it says is that the contributor agrees that their contributions will be provided under the license(s) for the project they’re contributing to. You can review and discuss the draft CLA on bug 401349.
• Second, we are going to support signed-off-by for contributions which flow to Eclipse project via git and Gerrit. The goal here is to make it as simple as possible for Eclipse projects to accept contributions via the community best practices which have grown up around git. As part of this, we will be developing a contributor certificate of originality, inspired by the one used by the Linux community.
• And finally, we are going to automate as much of this workflow as possible. Our CLAs will be presented and completed on-line. There will be Gerrit support so committers get an immediate indication as to whether a contributor has a CLA on file. There will be git triggers which will reject a commit where there is no CLA on file for the author of the code commit.

Ever since then, we’ve been working on getting all of the pieces lined up to go live with these capabilities. Today is the first step!

The Eclipse Contributor License Agreement is now live. This means that contributors can execute a CLA, and get theirs on file. Committers will be able to use the PMI (project management infrastructure) to look up whether a particular contributor has a CLA on file. So starting immediately, you will be able to refer to a CLA rather than asking the “three questions” on a bug. This is basically delivering on the first item above.

For the second item, the Eclipse Foundation Contributor’s Certificate of Origin has been published, and contributors and committers should start using the signed-by option with git.

In order for a contributor to sign their CLA, they need to do the following:

1. Obtain and Eclipse Foundation userid. Anyone who currently uses our Bugzilla or Gerrit systems already has one of those. If they don’t, they need to register.
2. Login into the projects portal, select “My Account”, and then the “Contributor License Agreement” tab.

Navigate to the CLA

The day after Kepler ships — Thursday, June 27th — we will deliver on the third item, which is automation. On that day, we will start automatically enforcing CLAs. This means that every time a contribution arrives at one of our git repositories (including Gerrit), the author field will be checked to ensure that there is a CLA or Committer Agreement on file for the author. If there isn’t, the contribution will be rejected.

Progress!

The Eclipse Public License, and its predecessor the Common Public License have been in existence for around 12 years now. A lot has changed since the EPL’s introduction in 2004, and the time has come for a review to ensure it remains current. As a result, we are going to kick off a public process to solicit input on the license, and discuss possible revisions. Once we’ve arrived at a set of revisions which have a broad support, the Eclipse Foundation Board of Directors would have to unanimously approve the new version. And, of course, any revisions would be submitted to the Open Source Initiative to have them certified as compliant with the Open Source Definition.

I don’t want to steer the conversation in any particular direction, but as a sampler of issues, here are a couple:

1. The distinction drawn between object code and source code aren’t really helpful when you’re talking about scripting languages like JavaScript.
2. The use of the term “module” is confusing to some.

There are a few things that we already know we don’t want to change. First and foremost is that the EPL will remain a copyleft license. Another is that we want to continue to enable a commercially-licensed ecosystem based on Eclipse technologies.

We are going to be starting these discussions soon on the epl-discuss@eclipse.org mailing list (subscribe here), and will be tracking individual issues in the Eclipse Foundation/Community/License component in the Eclipse bugzilla.

If you are interested in the future of Eclipse licensing, please join in the conversation!

I’m very happy to announce that we are going to be making some fairly significant changes to the workflows and processes around how contributions flow into Eclipse projects, and how Eclipse committers will process them. The good news is that we think that the new approaches are going to make things a lot easier for everyone. For more details, you can take a look at the presentation I did at a recent Architecture Council meeting.

First, a quick summary of how contributions come into Eclipse today.

• A contributor makes some changes to an Eclipse project and sends them to Eclipse for review and acceptance by an Eclipse committer. The first complication is that there are several different ways that can happen: contributions can come as push to Gerrit, or a patch in Bugzilla. Which means that the conversations about contributions can occur in multiple places.
• Assuming the committer likes the contribution and wants to take it, they are then required to ask the contributor “The Three Questions” on either Gerrit or Bugzilla. The Three Questions are:
  1. Did you author 100% of the content you’re contributing?
  2. Do you have the rights to contribute this content to Eclipse?
  3. Are you willing to contribute the content under the project’s license(s) (e.g. EPL)

The problem with this approach is that it’s very manual, error prone, and annoying. In particular, asking a prolific contributor the same three questions each and every time they try to help you out is just not helpful. It is particularly annoying in the context of the normal git workflows, where there there are numerous conventions for dealing with contributions.

So here’s how we are going to make it better:

• First, we are going to implement Contributor License Agreements (CLAs) for all contributors at Eclipse. The CLA will be a short document that essentially asks The Three Questions once. We will collect some information about the contributor so that we have a record on file of who is giving us code or documentation. Note that the Eclipse Foundation CLA will be quite different from those in use at other organizations. For example, Apache’s CLAs basically give the ASF a license equivalent to ownership for contributions. The Oracle Contributor Agreement (OCA) used by OpenJDK community gives Oracle joint ownership of contributions. The Eclipse CLA is much more modest. In terms of licenses, all it says is that the contributor agrees that their contributions will be provided under the license(s) for the project they’re contributing to. You can review and discuss the draft CLA on bug 401349.
• Second, we are going to support signed-off-by for contributions which flow to Eclipse project via git and Gerrit. The goal here is to make it as simple as possible for Eclipse projects to accept contributions via the community best practices which have grown up around git. As part of this, we will be developing a contributor certificate of originality, inspired by the one used by the Linux community.
• And finally, we are going to automate as much of this workflow as possible. Our CLAs will be presented and completed on-line. There will be Gerrit support so committers get an immediate indication as to whether a contributor has a CLA on file. There will be git triggers which will reject a commit where there is no CLA on file for the author of the code commit.

There are a ton of details to be worked out, not least of which is the timetable to roll all of this out. Stay tuned for that. If you want to get involved in the conversation, please join in on bug 401236.

Update: fixed typo “we think we think” in the first paragraph.

I am very happy to report that after a little bit of conversation, the JRuby project has moved from the Common Public License (CPL) to the Eclipse Public License (EPL). So as of this moment, JRuby is tri-licensed under the EPL/LGPL/GPL. This is an excellent reminder to all remaining CPL-licensed projects (hello JUnit! – discussion thread here) to consider re-licensing under the EPL. I documented all of the history and background back in 2009 when the EPL officially became the CPL’s successor, and the CPL was deprecated by the Open Source Initiative (OSI).

This whole JRuby transition came about because Charles Nutter and I accidentally met one another over good Belgian beer at FOSDEM. Since that approach doesn’t scale, I am going to use this event to remind folks that if your project is still using the CPL, you should switch and it is really easy to do so.

Some key points:

• Back in 2009, the CPL was superseded by the EPL. This means that the EPL is the successor version of the CPL. It also means that using the CPL is the licensing equivalent of using deprecated code.
• Because the EPL is the successor version to the CPL, the “new version re-licensing” clause in Section 7 of the CPL applies. In other words, you can re-license your project without seeking the approval of all of your contributors.
• The CPL and EPL basically differ by about one sentence, which you can see here. The difference relates to the scope of patent licenses terminated should someone sue another party for patent infringement. This is the kind of stuff that lawyers love, but most developers don’t really care about.

Thanks to the JRuby team for fixing this so quickly!

Welcome to 2012 folks, its going to be a busy and exciting year. There will be a number of important new projects, programs and initiatives across the Eclipse community. When we’re done Eclipse and the Eclipse Foundation is going to be quite a different – and even more interesting – place. So in no particular order, here is a sampling of some of the big things I see coming.

• As of the Juno release, Eclipse 4 is going to be the base platform for the Eclipse ecosystem. This means that our download page will only have Eclipse 4.2-based packages. Eclipse 3.8 will also ship as part of the Juno release, but currently there are no 3.x releases planned after that. Although an enormous investment has gone into the backwards compatibility layer for Eclipse 4, it is obviously going to take testing and effort by the Eclipse projects and the many Eclipse adopters to migrate to Eclipse 4.2. So if you haven’t started testing with the Juno builds, now’s the time to start planning for it. Eclipse 4 is a complete re-write of the platform user interface, and brings a lot of value to the ecosystem, including a lot of improved APIs, more flexibility and a refreshed user interface. And its API is 100% binary compatible with the 3.x platform.
• The migration of the Eclipse community to git is going to be a significant event during 2012. Shutting off CVS in December will be a major milestone. And we are almost done getting the Gerritt code review tool up and running for all Eclipse projects. To make all of this happen has been a ton of work by the webmaster team, the IP team, and you, the community. We’re hoping that using git will make it easier for our community to experiment with, and contribute back to Eclipse projects.
• A Common Build Infrastructure for Eclipse projects is a new service we plan to provide for projects at Eclipse. It has long been a complaint that getting builds working and running reliably is one of the biggest PITAs in running a project. The goal of the CBI is to reduce that effort, and to provide a core hosted service on eclipse.org infrastructure that all of our projects can use. As part of the initial proof of concept, we’re tackling the toughest build of all: the Eclipse platform. Admittedly, CBI is going to take a lot of work, but we are actively recruiting for a full-time staff member to manage this, and to act as a resource for our project community. This is definitely one of the biggest and most exciting new services we’ve worked on for our committer community. So please get involved, and provide your feedback and your requirements.
• We will also be launching a new service for members – providing Long Term Support for Eclipse releases. There is a fundamental mismatch between the maintenance window for Eclipse releases and the enterprise products that are built and ship on top. Eclipse release trains at least offer SR1 (September) and SR2 (February) maintenance releases on a regular basis. But an SR2 eight months after a major release is small solace to anyone with a requirement to offer support or maintenance on a product or application for five or more years (as many organizations do).

  As we are rolling this out, it is important to note that the Foundation is not going to be providing support or maintenance directly. Rather, we will work to connect organizations seeking support for Eclipse software with those offering it in order to cultivate a vibrant ecosystem. To help service providers be more efficient and effective, the Eclipse Foundation will provide the infrastructure for the code repositories, bug trackers, build farms, test farms, software signing, intellectual property management, and governance for managing the projects. We will be the trusted organization doing the drudge-work so that others do not have to. In other words, in classic Eclipse style, the Foundation will be acting as an enabler for the ecosystem.

• Orion is going to ship its 1.0 release later in 2012. There is a ton of work still to do, but there is no doubt in my mind that Orion is an important new technology for the Eclipse community – a whole new tooling platform for the web, in the web.
• EclipseCon is moving to Reston, Virginia, just outside Washington, DC. We hope to attract a lot of new attendees from the East Coast. In addition to the new location, we’re also adding an entirely new co-conference: Agile ALM Connect
• And last but not least, we will be creating a number of new Industry Working Groups. IWGs such as Polarsys and M2M are going to be a large focus area for the Eclipse Foundation. But what is an IWG? Basically, they complement Eclipse open source projects with more support from the member companies that are interested in working on them and adopting them.

I see 2012 as a year of significant, and positive, change for the Eclipse community and the Eclipse Foundation. We are certainly not resting on our laurels! I encourage everyone to get involved and contribute to these new initiatives.