Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Archive for the ‘Jakarta EE’ Category

New Eclipse Foundation Committer and Contributor Agreements

leave a comment »

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 license@eclipse.org 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!

Written by Mike Milinkovich

November 5, 2018 at 1:27 pm

Introducing the Jakarta EE Specification Process

I am very happy to announce that we are publishing a draft of the Eclipse Foundation Specification Process for community review and feedback. This specification process will be used by Jakarta EE as the new open specification process, replacing the JCP process previously used for Java EE. It is also expected that this new process will be of interest to other Eclipse working groups.

We are really looking forward to your feedback, which you can do via the Jakarta EE Community mailing list (preferred), or on the document comments.  The feedback provided will be used as input to finalizing a first version of the specification process and its adoption by Jakarta EE and other working groups at the Eclipse Foundation.  

As you are reviewing this draft specification process, please keep in mind the following key points about the approach that was taken by the Specification Committee.

  1. We want to design a specification process to replace the JCP. While there are many differences with the JCP, the key objective was to make the whole process as lightweight as possible.
  2. We want the specification process to be as close to open source development as possible. This is actually not a trivial exercise, as by its very nature drafting specifications is a somewhat different process.
  3. This is the Eclipse Spec Process, so we want to reuse the Eclipse Development Process wherever possible, and we want to ensure that the general flow and tone of the EDP is followed.
  4. We want to create a process that allows code-first development. Specifically, we want to enable a culture where experimentation can happen in open source and then have specifications be based on those experiences.
  5. We want the specifications that result from this process to be as high quality as possible. In particular, this means that we need to take care of the intellectual property flows, and to protect the community’s work from bad actors. This requirement manifests as two fundamentally important differences from the EDP:
    • Specification Committee approval is required for releases from Spec Projects, in addition to the normal PMC approval; and
    • We introduce the notion of “Participants” who are committers who represent specific member companies on a Spec Project. This is necessary to ensure that the IP contributions (particularly patents) from companies are properly captured by the process.

All of us at the Eclipse Foundation would like to recognize the tireless efforts of the members of the Specification Committee. A lot of hard work has gone into this document, and it’s very much appreciated. We are certain that Jakarta EE, and many other Eclipse technologies, benefit from the thoughtful efforts of this Committee.  In particular, we would like to thank the following Specification Committee members and alternates:

Fujitsu: Kenji Kazumura​, Mikel DeNicola
IBM: Dan Bandera​, Kevin Sutter
Oracle: Bill Shannon​, Ed Bratt​, Dmitry Kornilov
Payara: Steve Millidge​, Arjan Tijms
Red Hat: Scott Stark, Mark Little
Tomitribe: David Blevins​, Richard Monson-Haefel
PMC Representative: Ivar Grimstad
Elected Members: Alex Theedom, Werner Keil​

I also wish to recognize Tanja Obradovic and Wayne Beaton from the Eclipse Foundation team who have driven the process throughout – many thanks to you both!

Written by Mike Milinkovich

October 16, 2018 at 3:18 pm

Posted in Foundation, Jakarta EE, Open Source

Tagged with , ,