Life at Eclipse

Oracle announced today that they, along with IBM and Red Hat, will be moving Java EE to the Eclipse Foundation. I would like to welcome everyone involved to our community. We look forward to working with all of the participants in the Java EE ecosystem as it moves to a more open and collaborative development model.

Java EE has been at the center of enterprise computing for almost twenty years. As enterprises move to a more cloud-centric model, it is clear that Java EE requires a more rapid pace of innovation. The open source model has been shown time and again to be the most successful way to innovate in today’s world. The Eclipse Foundation is focused on enabling open collaboration among individuals, small companies, enterprises, and the largest vendors. The Eclipse MicroProfile project is, we believe, an excellent example of the developer community led style of collaboration we support. We look forward to supporting the Java EE community as it creates the platform for the next twenty years of business applications.

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.

As promised in my last post, today we are rolling out the new Eclipse Contributor Agreement (ECA). As I mentioned earlier, if you already have an active Eclipse CLA, you don’t have to do anything….your CLA remains active and you can convert to the new agreement when it expires after three years. That said, we think that the new agreement is clearer, and more consistent with the practices of the broader free and open source community.

In other news, last Wednesday the Eclipse Foundation Board of Directors approved the new IP Policy that I discussed in late June. This means that by the end of this year, projects at the Eclipse Foundation will be able to pick the type of IP due diligence that they want. If you want to learn more, I strongly suggest that you read my previous post on the topic, and join in the conversation on bug 496959.

The Eclipse Foundation continues to enhance its policies and procedures to make it a better place for developers to host their projects. I hope everyone agrees that these are all steps in the right direction.

In addition to overhauling our IP processes, next week the Eclipse Foundation will be updating our contributor agreements. The changes we’ll be making include:

1. Rename the CLA to the “Eclipse Contributor Agreement” or “ECA”. The reason we’re doing that is that in many circles within the free and open source community “CLA” has a negative connotation, as many CLAs require authors to assign ownership of their contributions to some entity. Eclipse does not do this, nor ever intends to do so. We have had a number of instances where people have assumed that our CLA does something it doesn’t, just because of the name. Hopefully a different TLA will help with that.
2. The current CLA basically copies and rephrases the Eclipse Contributor Certificate of Originality (CoO). It would be a lot easier to simply embed a direct copy of the relevant text in the ECA.
3. The Eclipse Foundation has its own CoO. We have had a number of requests to move to the Linux Foundation’s Developer Certificate of Origin (DCO), as it is widely adopted and well understand by the broad community of open source producers and consumers. So we are going to do that.

We do not consider these changes to be a big deal from a legal perspective — the end result of good record-keeping and clear IP flows remain the same. As a result, everyone with existing Eclipse CLAs will continue to use those until they expire. We are hoping that these changes will not cause any disruption to our existing contributor work flow.

Please let me know if you have any questions or concerns!