Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Java EE Moves to the Eclipse Foundation

with 11 comments

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.

Advertisements

Written by Mike Milinkovich

September 12, 2017 at 4:21 pm

Posted in Foundation

Java: Free At Last

with 8 comments

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:

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.

Written by Mike Milinkovich

September 7, 2017 at 4:45 pm

Posted in Foundation

EPLv2: A New Version of the Eclipse Public License

The Eclipse Foundation is in the process of revising the Eclipse Public License (EPL). Refreshing a popular open source license is a big job, and one that we have been chipping away at for over a year.

The EPL and its predecessor the Common Public License have been around for about 16 years now. For a full presentation on the changes we are considering and their motivation, you can check out our presentation, or the video on YouTube.

Please get involved. Just as importantly, if you are a developer involved in the Eclipse community and ecosystem, encourage your colleagues in the legal department to get involved. The discussions are happening on the epl-discuss@eclipse.org mail list (subscription required). The most recent public drafts of the EPLv2 can be found here.

Written by Mike Milinkovich

April 7, 2017 at 2:17 pm

Posted in Foundation, Open Source

Tagged with , ,

Progress Update on IP @ Eclipse

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.

Written by Mike Milinkovich

August 22, 2016 at 2:01 pm

Posted in Foundation

Contributor Agreement Update

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!

Written by Mike Milinkovich

August 15, 2016 at 8:30 am

Posted in Foundation

Overhauling IP Management at the Eclipse Foundation

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”.

Written by Mike Milinkovich

June 29, 2016 at 9:00 am

Posted in Foundation

Eclipse Tooling Platforms

Two weeks ago at EclipseCon, the Eclipse Che project announced its 4.0 release. This announcement is the first major result from the Eclipse Cloud Development strategy we announced eighteen months ago. Eclipse Che is an innovative new IDE platform which has been designed specifically for the needs of web and cloud developers, offering a whole new way to think about developer workspaces in a container world. Tyler Jewell, the Che project leader and CEO of Codenvy did a keynote at EclipseCon North America where he welcomed IBM, Microsoft, Red Hat, and SAP on stage to show what they are already doing with the Che technology. The reaction to the announcement from developers, adopters, and the press has been amazing.

In short, Eclipse Che is on track for becoming a huge success.

However, as with many things in life success in one area raises questions about others. In particular we’ve heard some questions about what this all means for the Eclipse JDT IDE that developers have known and loved for the past fifteen years. TL;DR: Eclipse Che and the Eclipse IDE platform are complementary to one another, and both are going to be more successful because of each other.

More details:

Is Eclipse Che going to replace the Eclipse IDE?
No. It’s a different project, staffed by a different team. Remember, this is open source where the community is the capacity. There is obviously some overlap between both, but they have distinct goals, advantages and benefits, so the Eclipse IDE platform remains relevant and actively developed.

Is Eclipse Che and the Eclipse IDE interoperable?
Partially. There are ways to move many projects between the Eclipse IDE and Eclipse Che. We generally see many opportunities to make it simpler for developers to smoothly transition from local to distributed development and back. There are generally more opportunities for the projects to collaborate together than to compete.

So there are 2 IDE platforms in the Eclipse Community?
The Eclipse Community actually has three platforms for building tooling extensions. Eclipse RCP, Eclipse Orion, and Eclipse Che. Eclipse RCP’s desktop plug-in model and structure is widely adopted and broadly understood. Eclipse Orion provides a client-side plugin framework to enable web tooling and editor extensions. Eclipse Che builds on Orion and Eclipse JDT to create a distributed workspace and cloud IDE extension platform. These platforms are partially competing, and we’re fine with that.

Why is the Foundation fine with that?
The community is the capacity, and we would much rather have innovative new projects happen at Eclipse than elsewhere. The Eclipse Foundation is fine with internal competition. Both the Foundation and the Community know that competition can bring innovation. Moreover, Eclipse Che and the Eclipse IDE have different objectives that drive them to create different extension architectures.

What are the main differences?
Che defines a workspace to include all of the dependencies necessary to let a developer contribute without first installing software. The Che workspace includes a runtime, project files, and a cloud IDE. The nature of workspaces makes them portable and shareable. Che provides a server that hosts multiple workspaces for a group.The Eclipse IDE targets the developer workstation with tighter integration to the system and more options to customize it locally.

Is this short-term, mid-term, long-term…?
We are not the ones who decide this. Developers now have one more alternative with Eclipse Che, and we’ll let them make their choices and drive the future of software development. Let’s ask this again in 5 years 😉

Written by Mike Milinkovich

March 29, 2016 at 11:05 am

Posted in Foundation