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 firstname.lastname@example.org mail list (subscription required). The most recent public drafts of the EPLv2 can be found here.
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:
- 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.
- 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.
- 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:
- 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.
- 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
levelreview 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”.
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.
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 😉
Yesterday I talked about three interesting new runtime projects which have joined the Eclipse community, and made the point that we are extending our reach beyond our “…original comfort zone of tools…”. But that doesn’t mean that we are not seriously investing in tools. In fact, in 2016 the Eclipse Foundation itself is hiring new staff to do exactly that.
The first position was just posted on our forums. For the first time ever, the Eclipse Foundation is looking to hire a full-time Eclipse platform developer. This position will be responsible for adding new features and fixing bugs in Eclipse under the umbrella of the Friends-Enabled Eclipse IDE/Platform Enhancements Program (FEEP). (Awkward name, great acronym!) The FEEP process ensures that it is the community leadership that guides what new investments we make in the Eclipse IDE and Platform. It is financially supported by the personal and corporate donations that we receive under the Friends of Eclipse program. You can help make Eclipse better with your donations!
Around the middle of this year we also intend to hire a Java Tools Evangelist, who will work with the community to help promote not only the Eclipse IDE, but also newer tool projects such as Eclipse Che.
Like I said, 2016 is off to a great start!
Yesterday was quietly one of the biggest days ever for Eclipse. That is because of three new project proposals that went live. It’s certainly unusual for us to have three new projects at once, but I’m not sure if it’s unprecedented. However, I am really excited about these projects, and what they mean for the future of the Eclipse community.
- Edje is a new IoT project that brings Java functionality to very small devices. It provides a standard hardware abstraction Java API required for delivering IoT services that meet the constraints of small, Arduino-class devices. The initial code contribution for Eclipse Edje is coming from MicroEJ, who has been working in this area for many years.
- IoT Connector provides a generic, cloud-based IoT platform architecture which supports the implementation of IoT solutions requiring device connectivity, device management, and interaction with business applications. The Eclipse IoT Connector project is targeting numerous runtimes such as Cloud Foundry, RabbitMQ and AMQP, and Docker. It is co-led by Bosch and Red Hat, two of the Eclipse Foundation’s Strategic Members.
- OMR aims to provide a technology platform for building language runtimes. It consists of core components that can be used to build runtimes for languages such as Ruby and Python. These components include: memory management, threading, platform port (abstraction) library, diagnostic file support, monitoring support, garbage collection, and native Just In Time compilation. Eclipse OMR is led by the same folks who build the IBM J9 Java virtual machine.
Several years ago we decided that the Eclipse Foundation was going to start welcoming projects outside of our original comfort zone of tools based on Java and OSGi. It has taken a while to get that message out, but it is clear that it is starting to be heard. None of these project are tools in the traditional Eclipse sense. They are runtimes and frameworks targeting environments from the smallest microcontrollers to the largest clouds.
Each of these projects are very ambitious in their own right. To have all three launched on the same day is crazy cool. I am really looking forward to watching these grow and mature as part of the Eclipse community.
EclipseCon North America March 7-11 in Reston, VA will be the place to be to find out more about these new projects. We’ll have talks on all of them.