New Eclipse Foundation Committer and Contributor Agreements
Note: to see redline versions of the changes to the documents discussed below, please visit this contribution and committer agreements page.
Over my almost 15 years of sharing updates about what’s going on at Eclipse, some blogs are more important than others. This one is important as it requires action by our members, committers, and contributors! There is a lot of ground to cover explaining what’s going on and why we’re changing things, so please forgive me for a longer than normal post.
tl;dr. The Eclipse Foundation is starting to develop specifications. First for Jakarta EE, but soon for other areas as well. We want to make it clear that contributions to our open source projects may someday be used to create a specification, because we believe in code-first innovation. We also believe that if you’re contributing to open source, you want your contributions to be used for open purposes, including specs.
We are updating our standard contributor and committer agreements, and we will be requiring all our committers and contributors, as well as those members who have member committer agreements, to re-sign their agreement with us.
To make this happen, we will be reaching out to everyone who needs to re-sign. You don’t have to do anything yet – just be aware the change is coming, and please act when we do make contact with you.
First, a bit of background. All contributions and commits made to any Eclipse Foundation project are covered by one of three distinct agreements – the Member Committer Agreement, the Individual Committer Agreement, or the Eclipse Contributor Agreement.
These agreements basically say that if you contribute to an Eclipse project, your contributions are being made under the license of the project. That license is usually the Eclipse Public License, but about 20% of our projects using additional or alternate licenses such as the Apache License, BSD, or MIT. It is important to note that the way things work at the Eclipse Foundation, the Foundation itself does not acquire any rights to the contributions. This is very different from other organizations like the FSF, OpenJDK, or the Apache Software Foundation. Eclipse uses a licensing model sometimes referred to as symmetrical inbound/outbound licensing, where contributors license their code directly to the users (recipients) of their contributions. Our approach requires us to ensure that all of our contribution agreements provide all necessary grants because we at the EF don’t have any rights to re-license contributions.
As most are aware, Eclipse is now about to start hosting specifications as open source projects. This is very exciting for us, and we think it represents a new opportunity for creating innovative specifications using a vendor neutral process. The first specification projects will be a part of the Jakarta EE initiative, but we expect other specification projects to follow shortly.
Everyone expected to re-sign one of these is encouraged to ensure they understand the details of the agreements and to seek their own legal advice. However, the change we have made is basically to ensure the copyrights in contributions to Eclipse projects may be used in specifications as well. (For the lawyers in the crowd, please note that these additional grants do not include patents.) We certainly expect that our committers and contributors are fine with this concept. In fact, I assume that most folks would have expected that this was already obvious when they contributed to an open source project. To that, all I can say is….ahhhh…the lawyers made us do it.
The new agreements are already posted, so they are in immediate effect for new contributors and committers. Since we need to overhaul our contribution agreements, we are also taking this opportunity to fix a few things. In particular, our committers will know that up until now they’ve been required to be covered by both a committer agreement and the ECA. We’re going to fix that, so if you sign an Individual Committer Agreement, or are covered by your employer’s Member Committer Agreement, you will no longer have to personally sign an ECA. We are also going to implementing electronic signatures for ICAs using HelloSign. So going forward there is going to be a little less paper involved in being a committer. Yay!
We’re sensitive that asking our contributors and committers to ‘update their paperwork’, especially if they’re not working on a specification, is – well, a pain in the backside. But we’re hoping everyone will be supportive and understanding, and recognize that we take IP very seriously, and it’s one of the real value propositions of working with Eclipse.
Contributors who have an ECA will see them revoked over the coming months, and will be asked to re-sign the new one. We will be starting first with the contributors to the EE4J projects, since they are the ones who are most likely to have contributions flowing into Jakarta EE specifications.
Executing this change represents a massive effort for our team, as it literally means updating hundreds of committer agreements. Our staff will be emailing individually each individual and member company needing to update their agreement with us, but we will be spread it over a period of the next few months. So don’t be surprised if you don’t get an email for a while – we will get to everyone as soon as we can.
Stay tuned for emails on this subject that will be sent to our various mailing lists with more details. If you have questions, feel free to reach out to us at email@example.com and we’ll do our best to provide answers.
I thank our entire community in advance for accommodating this significant change. We are excited about the Eclipse Foundation hosting an even more vibrant collection of projects, and believe hosting open source specification projects is a great step forward in our evolution!