The EPL as a Platform License

Yesterday’s announcement of the OpenDaylight project has gotten very wide coverage. It looks like a well-done announcement, and the industry support for this important new collaboration is stellar. Yet another great example of how open source is facilitating collaboration on new and innovative industry platforms.

In my opinion, one important detail of the announcement has not received sufficient notice:

OpenDaylight … is structured and governed using open source best practices and is licensed under the Eclipse Public License (EPL)…

So OpenDaylight is flying in the face of a lot of recent conventional wisdom that the Apache License is the default license of choice for new industry collaborations. (See here here and here.) Frankly, I thought I would see pigs fly before seeing Microsoft fully participating in an EPL-licensed open source community.

I think that this could be the start of a new trend, because as we’ve seen platform fragmentation in the Android ecosystem is becoming bit of an object lesson for the industry.

The EPL has a couple of really important features that make it a particularly good platform license. It strikes the perfect balance between the competing interests of the collaborative community who is building the code, and the commercial interests who want to use that code in their products and services.

• The EPL is copyleft, which means that if a company forks the code to further their interests, they need to make that code available under the EPL. This is a powerful incentive to simply do the work in the main project, in collaboration with the other players.
• The EPL is commercially friendly, allowing corporations to build products on top of EPL-licensed code and use their own End User License Agreement when selling to their customers. This provides the ability for companies to leverage EPL-licensed open source code in traditional software business models.

The combinations of those two main features has been a big part of the success of the Eclipse community. We’ve seen remarkably few forks at Eclipse (aka fragmentation), while enjoying massive amounts of commercial adoption of our technologies. Will the OpenDaylight announcement make other industry open source collaborations think a little bit harder about their license choices? Time will tell, but I think this could be an interesting trend to watch.

Public Review Drafts of New IP Documents Now Posted

A few weeks ago, I talked about a major overhaul of our IP processes. As part of that, we have posted our Public Review Drafts of our Eclipse Foundation Contributor License Agreement (CLA) and our Contributor’s Certificate of Originality (CoO).

I was asked why we needed both documents. I will repeat the explanation here:

The two documents are complementary.

The CLA is something that a contributor signs, and is a legal agreement.

The CoO is a statement that clarifies what we expect from contributors when they use the “signed-off-by” feature in git.

There is a saying that many lawyers use: “belts and suspenders”. Yes, there is some overlap between these two approaches, but there since the DCO is not something that a contributor is expected to sign, I don’t think that it adds any extra burden to the process.

Your comments and feedback would be greatly appreciated. However, please don’t do it in the comments here. We would prefer the community’s feedback on bug 401349.

Update: s/DCO/CoO/ in blockquote.

A Major Overhaul of Eclipse’s IP Process: CLAs, signed-off-by and more

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.

JRuby Moves to the EPL

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!

Eclipse Says Goodbye to CVS

Well, December 21st is here and the the apocalypse didn’t happen! But it’s still a big day at Eclipse because today at 12:00 noon, Eastern Time, our webmaster team of Denis and Matt started the process of turning CVS into a read-only service. At this point, we are down to only a handful of projects which still have a CVS repository, and we have hit the long-published deadline.

This is a journey that the entire Eclipse community has been on for at least two years. I have to admit that when I first heard of the idea that we should move the  Eclipse community from CVS to git, I was adamantly against the idea. The notion seemed to big, too scary, and the idea that we could get the community to move seemed too unlikely. But as time went by the logic and benefits of moving to git started to clearly make  sense. The trend towards social coding is huge. Working with the developer community which has grown up around github is large and vibrant. It is critically important to all open source organizations to make it as easy as possible to attract more contributors, and leveraging git is a big part of making that happen.

There are a lot of people that worked hard to make this happen. In no particular order:

• Chris Aniszczyk, who is an elected Committer Rep on Eclipse’s Board pushed hard to make this possible. Not only did he tirelessly champion this transition at the Board, he worked hard on EGit and JGit to get the tools in place to make it possible. For anyone who wonders about how important your elected representatives are on the Eclipse Board, Chris is a great example of how influential these directors are. Chris blogged about the transition today as well.
• Shawn Pearce, and the entire EGit and JGit teams. Shawn started those projects and helped bring them to the Eclipse Foundation. When we started this process, one of the biggest impediments was the lack of great tools. Shawn, Chris, Matthias, Remy, and many others have worked extremely hard to get these great tools in place. Given how mature and feature-rich the CVS Team Provider was, they had a lot to accomplish and not a lot of time to do it in.
• Wayne Beaton has done a great job in tracking down all of the Eclipse projects and coaching them on what they needed to do to transition their projects to Eclipse. It has been a huge job to get 180+ projects moved, and Wayne has done an enormous job in ensuring that each and every project knew about the transition, and helped them get it done.
• The Eclipse webmaster team of Denis Roy and Matt Ward helped migrate all of the repositories over, and basically made this all possible. I can’t even imagine how many repositories they’ve created for the projects over the past year or so.
• And finally, all of the Eclipse projects deserve a big round of applause. It has been a big job to move to git, involving learning new tools, deciding on a repository architecture, re-doing their builds and so one. In particular, I want to thank some of the older and larger projects such as Eclipse, Web Tools and BIRT who had years of working practices that they’ve had to re-do to make this all possible. In particular, John Arthorne and Paul Webster really helped by elaborating some best practices, and establishing some solid git usage policies that have been widely adopted by the community as we’ve transitioned.

So thanks and congratulations all the way around. It’s been a big job, but we collectively got ‘er done!