Life at Eclipse

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!

At our recent face-to-face Board meeting earlier this month, an agreement in principle was made to move ahead with the largest overhaul of our intellectual property processes since the inception of the Eclipse Foundation 12 years ago. Now, don’t get too excited because months of work are going to be required before the new policies are approved, and the implementation of new processes are completed. But I did want to share the direction we are heading in with the community to get your input and feedback.

What do we do today?

The Eclipse Foundation takes a very rigorous approach to intellectual property management. As far as I know, we are the only open source foundation to have a dedicated staff whose sole responsibility is the review all of the code distributed by Eclipse Foundation projects. The easy part is the code that is written by Eclipse committers. The far more time-consuming piece is a detailed review of all of the dependencies used by or distributed with Eclipse projects. That dependency review includes checking license compatibility, scanning the code to look for potential issues, and checking in on the provenance of the code in question. That last piece (“provenance”), can be particularly time-consuming because it involves answering questions like “was the code ever re-licensed from licenseA to licenseB, and if so how was permission obtained from the contributors?”. Or “how does this project manage contributions to it?” To my knowledge, no other open source foundations or communities do the level of detailed analysis that we do.

The good news is that the Eclipse community and the IP team staff at the Eclipse Foundation can take a great deal of pride in knowing that what ships from Eclipse has been well reviewed, and can be safely consumed by users and adopters in downstream products. The bad news is that this is a lot of work for the projects, and can be very time consuming for everyone involved.

What are we changing?

The proposal is pretty simple. In the future Eclipse projects will be able to decide what level of IP due diligence they want performed for each of their releases. For the purposes of this discussion, let’s call them “Level 1” and “Level 2”, although there is a high probability that those labels will change.

“Level 2” “Type B” is what we do now. No change.

“Level 1” “Type A” takes a much simpler approach for dependencies. Basically, all that will be checked is license compatibility with the project license(s). We won’t do code scans or provenance analysis of any of a Level 1 Type A project’s dependencies. However, all of the existing processes around managing the code which is developed by or contributed to Eclipse projects will continue. (This includes things like committer agreements, CLAs, and git signed-off-by, etc.)

The decision on which level type a project wants can be specified on a per-release basis. So, for example, if a project wants have a very fast release cycle (e.g. ship something every 4 weeks) but still wants to ship a fully reviewed major release once a year, that would be a supported use case. The authority to make this decision rests with the project lead for the project.

This new approach will have particular value for new projects at the Eclipse Foundation. Rather than waiting for their dependencies to be cleared by the IP team, once the project can self-certify that all of their dependencies have compatible licenses they will be able to check-in their code and start working at Eclipse. We are hoping that this is going to reduce the ramp-up time for a new project from months to about a week. As part of making this happen we will need to find a scan tool which give an accurate report of licenses contained in code artifacts that is usable by developers. If anyone knows of any such tools, please let me know!

Why are we doing this?

There are lots of reasons, ranging from resources to agility to changing industry perceptions around risk in open source. But the most important one is that we want to help Eclipse projects be more successful. We have a lot of process that our projects need to deal with, and for a great many of them the IP requirements exceeded what their users and adopters required. So the time for a re-calibration has come.

When is this going to get done?

It’s hard to say with certainty, but our goal is to have this fully implemented by the end of this year. There are two major components to making that happen:

1. We have to make some significant changes to the Eclipse Foundation IP Policy, and have those reviewed and approved by the Board of Directors. That is going to take a few months.
2. We need to implement some changes in our tools and processes to support this. That includes changes to the Project Management Infrastructure (PMI) to track the IP level review type for a release, finding and hosting a license scan tool that committers can use to self-certify their dependencies, etc.

Where do we discuss this?

I’ve opened bug 496959 to discuss this, and to track all of the pieces that will go into its implementation. I am really looking forward to hearing from the community about this proposal. Personally, I am very excited by it, and think that a lot of projects will be as well.

Caveat: All of this assumes that the necessary changes are approved by the Board of Directors. The Board makes the call on these policies, and when they see the final edits to the IP Policy perhaps they will have a change of heart. But obviously if I thought that outcome wasn’t a high probability I wouldn’t be talking about this yet.

Edit: The original post has been edited to reflect that the we’ve decided to refer to the IP reviews as “Type A” and “Type B”, rather than “Levels”.