Search Results
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 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!
Help Pick the New Name for Java EE
This blog post is based on the text of Eclipse EE4J’s very first GitHub Issue. Please join the conversation over there!
We need a new brand name for the set of specifications that will be created by the new community process. This brand name will also become a certification mark in the industry for compatible, independent implementations. The open source projects that fall under the Eclipse EE4J top level project will be one such implementation. In short, we need a new name to replace “Java EE”. Much like the OpenJDK project implements the Java SE Platform specification, the EE4J projects will provide implementations of a set of specifications that we today call Java EE: we need a brand name for this set of specifications.
With this in mind, we are initiating a community process to select the brand name. This process will be managed by the EE4J Project Management Committee (“PMC”) with assistance from the Eclipse Management Organization (“EMO”). The name that is selected by this process must pass legal and other trademark searches to ensure that the names are available for use. As a result, it is possible that the favoured selection will not be the ultimate choice. The final decision will be made by the EMO Executive Director (“EMO(ED)”) in consultation with the PMC.
The process is described in greater detail below.
Nominations
Names can be nominated by anyone in the community via this GitHub Issue record.
Nominations will be open from November 15 until November 30, 2018.
Naming Guidelines
All suggested names must conform to the following:
- They must conform to Oracle’s trademark usage guidelines. Amongst other things this means that the name cannot start with the word “Java”.
- They must conform to the Eclipse Foundation trademark guidelines.
- They must not be obscene, sexist, racist, controversial, etc., and they must not be frivolous (e.g. we’re not going to choose Boaty McBoatface or the like.)
Any suggested names which fail to meet the above criteria will be rejected.
Name Selection Process
The process will be executed as follows:
- Members of the community will be invited to enter their nominations into the specified channel;
- At the end of the nomination period, the names suggested by the community will be reviewed by the PMC to identify those which meet the criteria specified in the by the naming guidelines (depending on response, the PMC may decide to further reduce the list to a manageable size);
- The PMC will then initiate a community vote using the CIVS system (which will produce an overall ranking of the choices); and
- The results of the vote will be delivered to the EMO(ED) who will engage in the required legal and other trademark searches to ensure that the names are available for use, and consult with the PMC to make the final decision.
Since we have no idea what sort of community response to expect, it is difficult to time box anything other than the initial nomination process. But this will be an open and transparent process, and we invite the community to engage in all aspects of it. There is a great deal of legal, marketing, and community thought that goes into selecting an industry brand, so it’s important that we get this right. This may take a little time.
Java: Free At Last
There was lots of news in the land of Java yesterday. If you have not already seen the posts by Mark Reinhold and Donald Smith of Oracle, I encourage you to read:
- Moving Java Forward Faster
- Accelerating the JDK release cadence
- Faster and Easier Use and Redistribution of Java SE
There has been an enormous number of articles written about this news, most of which have focused on the new time-based release cadence. Obviously coming from an Eclipse background, I’m a big believer in the idea of release trains. After all, Eclipse Foundation projects have been doing this for over a decade. I believe that this is going to be a good thing for the Java platform, once the teams inside Oracle get into the groove of producing time boxed releases.
But relatively little has been written about what I think is the really big news:
“…Oracle plans to ship OpenJDK builds under the GPL…” and “…within a few releases there should be no technical differences between OpenJDK builds and Oracle JDK binaries.”
Which means that Java will finally be freed of the explicit and implicit field of use restrictions which have dogged it since its invention. Developers will be free to use Java on any device, without requiring any additional licensing or other permission. I believe that this is going to lead to a resurgence of innovation in the Java ecosystem. And I am particularly optimistic about what this could mean for Java as the language of choice for many solutions in the Internet of Things.
The license that Java binaries are currently distributed under today is the Oracle Binary Code License, which states (emphasis added):
“General Purpose Desktop Computers and Servers” means computers, including desktop and laptop computers, or servers, used for general computing functions under end user control (such as but not specifically limited to email, general purpose Internet browsing, and office suite productivity tools). The use of Software in systems and solutions that provide dedicated functionality (other than as mentioned above) or designed for use in embedded or function-specific software applications, for example but not limited to: Software embedded in or bundled with industrial control systems, wireless mobile telephones, wireless handheld devices, kiosks, TV/STB, Blu-ray Disc devices, telematics and network control switching equipment, printers and storage management systems, and other related systems are excluded from this definition and not licensed under this Agreement.
Making Java binaries available directly from OpenJDK is going to free the Java platform for developers. Getting these directly from the platform owner, and (more importantly) having them be identical to the commercial binaries is a radical step forward. OpenJDK-based binaries will be exactly on par with, and equivalent to, the commercial ones. Although almost all of the Java source code has been open source at OpenJDK for many years, the subtle differences in content, performance, and reliability have prevented mainstream adoption of OpenJDK binaries by enterprises and industrials.
A little over a decade ago, Sun Microsystems started the process of open sourcing Java. It seems that Oracle is finally finishing the job. Good for them.
Eclipse Contributor License Agreements Are Live
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:
- 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.
- 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!
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:
- Did you author 100% of the content you’re contributing?
- Do you have the rights to contribute this content to Eclipse?
- 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.
Life at Eclipse 