Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Archive for the ‘Foundation’ Category

Frequently Asked Questions About Jakarta EE 8

I’d like to thank the community for the level of engagement we’ve seen in response to my post from last week.   This post, which again represents the consensus view of the Jakarta EE Steering Committee, answers some questions about Jakarta EE 8, which is planned as the initial release of Jakarta EE, and is intended to be fully compatible with Java EE 8, including use of the javax namespace.   We thought it would be useful to reiterate the messages we have been delivering about this release.

Note that this post is not about future Jakarta releases where the namespace will be changed. There is a vigorous discussion going on right now on the jakarta-platform-dev@eclipse.org list (archive), so if you are interested in that topic, I would suggest you participate there. We expect that it will be about a month before the Jakarta EE Spec Committee will determine the next steps in the Jakarta EE roadmap.

Will Jakarta EE 8 break existing Java EE applications that rely upon javax APIs?

No, Jakarta EE 8 will not break existing existing Java EE applications that rely upon javax APIs.   We expect Jakarta EE 8 to be completely compatible with Java EE 8. We expect Jakarta EE 8 to specify the same javax namespace, and the same javax APIs and the same behavior as is specified in Java EE 8.    We expect that implementations that pass the Java EE 8 TCKs will also pass the Jakarta EE 8 TCKs, because the Jakarta EE 8 TCKs will be based on the same sources as the Java EE 8 TCKs. Jakarta EE 8 will not require any changes to Java EE 8 applications or their use of javax APIs.

What will Jakarta EE 8 consist of?

The Jakarta EE 8 specifications will:

  • Be fully compatible with Java EE 8 specifications
  • Include the same APIs and Javadoc using the same javax namespace
  • Provide open source licensed Jakarta EE 8 TCKs that are based on, and fully compatible with, the Java EE 8 TCKs.
  • Include a Jakarta EE 8 Platform specification that will describe the same platform integration requirements as the Java EE 8 Platform specification.
  • Reference multiple compatible  implementations of the Jakarta EE 8 Platform when the Jakarta EE 8 specifications are released.
  • Provide a compatibility and branding process for demonstrating that implementations are Jakarta EE 8 compatible.

Will there be Jakarta EE 8 compatible implementations?

Yes.  Multiple compatible implementations of the Jakarta EE 8 Platform will be available when the Jakarta EE 8 specifications are released.  We expect that any Java EE 8 compatible implementation would also be Jakarta EE 8 compatible, and the vendors in the Jakarta EE Working Group intend to certify their Java EE 8 compatible implementations as Jakarta EE 8 compatible.  In addition, because the Jakarta EE TCKs are available under an open source license, we will “lower the bar” for other technology providers to demonstrate Jakarta EE compatibility for their implementations. The lower cost and more liberal Jakarta EE trademark licensing will allow more technology providers to leverage and strengthen the Jakarta EE brand in the Enterprise Java community.  Jakarta EE 8 will provide a new baseline for the evolution of the Jakarta EE technologies, under an open, vendor-neutral community-driven process.

What is the process for delivery of Jakarta EE 8

The process for delivery of Jakarta EE 8 specifications will be fully transparent and will follow the Jakarta EE Specification Process.  Expect to see in coming weeks the delivery of initial, draft Jakarta EE 8 component specifications corresponding to Java EE 8 component specifications.  These will contain Javadoc defining the relevant APIs, and TCKs for compatibility testing. To publish specification text, we need to acquire copyright licenses for this text.  We have obtained Oracle and IBM’s copyright licenses for their  contributions, and intend to obtain the remaining copyright licenses required to publish the text of the Jakarta EE 8 Platform specification, and as much as possible of the component specifications. If you contributed to the Java EE specifications at the JCP in the past, expect to be contacted by the Eclipse Foundation to provide a license to use your contributions in Jakarta EE going forward. Providing such a license will be an important step in supporting the new specification process and the Jakarta EE community.  You will see these draft specifications evolve to final specifications in an open community process. Join the specification projects and participate!

When will Jakarta EE 8 be delivered?

The Jakarta EE Working Group intends to release final Jakarta EE 8 specifications by the fall of 2019.    This is an open community-driven effort, so there will be transparency into the process of driving the Jakarta EE 8 specifications, delivery of the Jakarta EE 8 TCKs, and Jakarta EE 8 compatible implementations.

Written by Mike Milinkovich

May 8, 2019 at 8:00 am

Posted in Foundation, Jakarta EE

Update on Jakarta EE Rights to Java Trademarks

Summary of progress to date and implications of the agreement between Eclipse and Oracle on Jakarta EE and use of Java trademarks and the javax namespace.

Introduction

The migration of Java EE to the Eclipse Foundation has been an enormous effort on behalf of the Eclipse Foundation staff and the many contributors, committers, members, and stakeholders that are participating.

This post was reviewed and represents the consensus view of the Jakarta EE Steering Committee.

Earlier this year GlassFish 5.1 was certified at Eclipse using the Java EE 8 TCK at the Eclipse Foundation. Since then under the direction of the working group the community established a Jakarta EE Specification Process (JESP) for the evolution of the Jakarta EE specs at the Eclipse Foundation. Specification projects are being created for all of the Jakarta EE specifications. The TCK process is being refined for Jakarta EE in concert with the new Jakarta EE compatibility logo. This is all being done in support of the Jakarta EE 8 release.

Progress to Date

The Jakarta community has been busy.

  • Oracle contributed GlassFish and the Java EE APIs and TCKs to Jakarta EE.
  • The Jakarta EE Working Group was formed and supporting committees to provide governance to the community and facilitate collaboration.
  • Eclipse GlassFish was certified with the Java EE TCK at the Eclipse Foundation.
  • The Eclipse Foundation Specification Process was created, and customization created and approved for the Jakarta EE Specification Process.
  • Specification projects are being created and work is underway now within the community to deliver the Jakarta EE 8 release later this year.
  • There is an initiative underway for Oracle, IBM, Red Hat and other members of the JCP to contribute their specification documents created at the JCP to Jakarta.

It had been the mutual intention of the Eclipse Foundation and Oracle to agree to terms that would allow the evolution of the javax package namespace in Jakarta EE specifications.   Unfortunately, following many months of good-faith negotiations, the Eclipse Foundation and Oracle have been unable to agree on terms of an agreement for the Eclipse Foundation community to modify the javax package namespace or to use the Java trademarks currently used in Java EE specifications.   Instead, Eclipse and Oracle have agreed that the javax package namespace cannot be evolved by the Jakarta EE community. As well, Java trademarks such as the existing specification names cannot be used by Jakarta EE specifications.  Because of the complexity and confidential nature of our negotiations, the Eclipse Foundation and Oracle have also agreed that we will not attempt to characterize here what has resulted in this outcome. It is the best outcome we could mutually achieve for the community. Some additional context is provided in the Eclipse Foundation Board and Jakarta EE Steering Committee meeting minutes.

What restrictions does this outcome impose on the Eclipse community?

Oracle’s Java trademarks are the property of Oracle and the Eclipse Foundation has no rights to use them.   The implications of this are as follows:

  1. The javax package namespace may be used within Jakarta EE specifications but may be used “as is” only.  No modification to the javax package namespace is permitted within Jakarta EE component specifications. Jakarta EE specifications that continue to use the javax package namespace must remain TCK compatible with the corresponding Java EE specifications.
  2. Jakarta EE component specifications using the javax package namespace may be omitted entirely from future Jakarta EE Platform specifications.
  3. Specification names must be changed from a “Java EE” naming convention to a “Jakarta EE” naming convention.  This includes acronyms such as EJB, JPA or JAX-RS.

In addition to the above, any specifications which use the javax namespace will continue to carry the certification and container requirements which Java EE has had in the past. I.e., implementations which claim compliance with any version of the Jakarta EE specifications using the javax namespace must test on and distribute containers which embed certified Java SE implementations licensed by Oracle. These restrictions do not apply to Jakarta EE specifications which do not utilize javax, including future revisions of the platform specifications which eliminate javax.

Note that the ratified Jakarta EE specifications will be available under a different license (the Eclipse Foundation Specification License). This is the reason why the Eclipse Foundation is currently asking the community to update their contributor and committer agreements.

What is next for the Jakarta EE Working Group?

The Jakarta EE Working Group including Oracle will continue to do what they set out to do: namely, move Java EE to the Eclipse Foundation. The group remains committed to creating a Jakarta EE 8 specification, logoed under the Eclipse Foundation’s Jakarta trademark. Further, the group is also committed to future versions of the Jakarta EE specifications that deliver on the original promises of innovation and evolution in cloud-native Java.

What does it mean for Jakarta EE to not modify the javax package namespace?

The Agreement does allow for modification and evolution under a new namespace, such as jakarta. It is expected that all future evolution and innovation will not use the javax namespace.

What happens to the Jakarta EE brand?

The Jakarta EE compatibility and the Jakarta EE member logos have both been decided on by the community and published. Work is underway to deliver the branding usage guidelines and supporting trademark license agreement. We expect to see the usage of these brands later this year.

Will there be a Jakarta EE 8?

Yes. The community is working hard to deliver the Jakarta EE 8 release, which is Java EE 8 delivered from Eclipse. We expect that many application servers will certify as Jakarta EE 8 compatible.

What happens beyond Jakarta EE 8?

The guiding principle for Jakarta EE 9 will be to maximize compatibility with Jakarta EE 8 for future versions without stifling innovation.  This will most likely involve two key topics: migration of some or all of the Jakarta EE specification source to a new namespace for future evolution; means to provide backwards compatibility with javax at a binary level, allowing old applications to run on Jakarta 9 implementations with some form of build or runtime tooling.

So while there will be a point in time where future versions of specifications will have to go through a source code incompatible change with respect to the previous javax based packages, this will be a straightforward transformation.

Further plans are being evolved by the Jakarta EE community via the Jakarta EE Platform Project. Your comments and participation are encouraged.

What does this mean for the EE4J projects?

The specification projects need to be renamed to not use Oracle’s Java trademarks. The Jakarta community gets to decide on the new names. This is an opportunity to tighten up the naming and get a better level of consistency. The future of Eclipse Enterprise for Java (EE4J) projects will be determined by the community who participate in those specifications and open source projects.

What is next for Eclipse GlassFish?

Work is underway at the Eclipse GlassFish project running the Jakarta EE 8 TCK and being ready to support its role in the TCK for interop testing. The future of Eclipse GlassFish will be determined by the community who participate in the project.

How will specs be updated beyond Jakarta EE 8?

Jakarta EE specifications will be updated according to the approved Jakarta EE Specification Process (JESP). The actual enhancements will be determined by the community who participate in those specification projects.

Written by Mike Milinkovich

May 3, 2019 at 6:00 am

Eclipse Foundation on the move!

After 15 years at 102 Centrepointe Drive in Ottawa, the Eclipse Foundation is on the move. We will now be located at 2934 Baseline Road, Suite 202, Ottawa, ON, K2H 1B2.

Back in 2004, when we took the space current space on Centrepointe, there were only three of us on staff. Fifteen years later we have been joined by over 20 more staff in the Ottawa office, where we now occupy all three floors of our building. With this growth, we have simply outgrown our existing space.

On May 6th, we move to a new office space nearby that allows us all to be on one floor and doesn’t significantly increase travel time for anyone on our team. The decision to move to one floor was largely based on research that shows that having employees on one floor improves collaboration and offers more opportunities for interactions, thereby building relationships. Our new office also allows room for us to grow as we continue to grow. These fresh new facilities offer several benefits for our company, such as a free gym, lots of green space (think outdoor meetings where creativity can bloom), an on-site cafeteria which provides healthy food options, several in-office meeting rooms and a large boardroom where we can host our larger meetings…and have a few parties for our hard-working staff.

If  you are in the area, please drop by and say hello. We would certainly welcome the opportunity to show you our amazing new digs!

Written by Mike Milinkovich

April 24, 2019 at 3:47 pm

Posted in Foundation

The 2019 IoT Developer Survey Results are Live

After months of hard work, the 2019 IoT Developer Survey results are live today. This year marks the fifth year the Eclipse IoT Working Group has asked the global IoT developer community to share their perceptions, requirements, and priorities. The survey has proven to be an influential assessment of the IoT market as viewed from the development front lines. Access the full findings of the 2019 IoT Developer Survey here.

Over 1,700 individuals took the survey between February and March 2019. Just like in previous years (see results from 2018, 2017, and earlier here), Eclipse IoT collaborated with key IoT ecosystem players like Bosch and Red Hat to maximize the reach of the survey.

The key findings this year include the following:

  • IoT drives real-world, commercial outcomes today. 65% of respondents are currently working on IoT projects professionally or will be in the next 18 months.
  • IoT developers mostly use C, C++, Java, JavaScript, and Python
  • AWS, Azure, and GCP are the leading IoT cloud platforms
  • Top three industry focus areas remain the same as last year: IoT Platforms, Home Automation, and Industrial Automation / IIoT.
  • MQTT remains the dominant IoT communication protocol leveraged by developers
  • The Eclipse Desktop IDE is the leading IDE for building IoT applications

IoT gets real(er)

Consistent with our findings last year, two-thirds of the respondents to our survey develop and deploy IoT solutions today or will be doing so within 18 months. This continued focus on building and deploying real world solutions is reflected in the increases in developers’ focus on performance, connectivity, and standards shown in the survey.

C and Java dominate

C won out as the programming language of choice for constrained devices, while Java was most popular for gateways/edge nodes and IoT cloud. Neither of those findings are surprising. C and C++ have long been the languages of choice for small embedded systems where minimizing memory space and power consumption, and maximizing processor utilization are key. Java is the dominant language and platform where the memory and processing resources are larger, and the complexity of the systems are greater. In particular, Java is the language of choice for most cloud infrastructure projects, so seeing it lead in IoT cloud is consistent with that.

AWS, Azure, and Google hold on to the lead

As expected AWS, Azure, and GCP maintain their status as the leading IoT cloud platforms. The list of three and their rankings are entirely consistent with their relative weights in the cloud computing marketplace as a whole, so there is no surprise to see this reflected in our results.

A continued focus on platforms, home automation, and IIoT

IoT Platforms (34%), Home Automation (27%), and Industrial Automation / IIoT (26%) were the respondents’ three most common industry focus areas. These areas are likely to continue to be key targets for IoT developer activity.  The fact that IoT Platforms is consistently year after year the number one focus for IoT developers is interesting. It implies that enterprises and industrials are putting resources into building their own IoT platforms for use by their companies. To me this suggests that industrial IoT is going to be a huge opportunity for hybrid cloud, as companies build and run IoT solutions on-premise based using modern, open technologies.

Security is (still) top of mind

Security is still the top concern for IoT developers. Communication Security (38%) Data Encryption (38%), and JSON Web Tokens (JWTs) (26%) were the top three security technologies cited in the survey, with virtualization also starting to play a stronger role in IoT Security.

MQTT is still the dominant IoT communication protocol

HTTP (49%), MQTT (42%), and Websockets (26%) were the top three communications protocols used by IoT developers. The growth in MQTT adoption over the past seven or eight years has been phenomenal, and I like to think that the Eclipse IoT community with its Eclipse Paho and Eclipse Mosquitto projects had a small part to play in that. Having robust open source implementations available has certainly been part of the MQTT’s success. Looking forward that main challenge we see for further MQTT adoption is the lack of interoperability built into the protocol. While MQTT is a great lightweight, low latency protocol it does not provide any guidance on the topic structures and payload definitions used by any device or application. This means that no two teams using MQTT would expect to have their systems be able to reliably exchange data. The Eclipse Tahu project defines the Sparkplug protocol — created by Arlen Nipper one of the co-inventors of MQTT itself. Sparkplug defines the topic structures and payload definitions necessary for out-of-the-box interoperability of SCADA systems. We are hopeful that Sparkplug could spur MQTT to even greater adoption in industrial IoT use cases.

The Eclipse Desktop IDE is the leading IoT IDE

45% of respondents use the Eclipse Desktop IDE. It is not at all surprising that the Eclipse IDE has a strong franchise with IoT developers, given the dominance of C and Java. The Eclipse CDT project has long been hugely important in the embedded software space. The past decade CDT has been used by virtually every chip, SOC, and RTOS company as the basis for their toolset. Those developer solutions also typically use additional tools such as the Target Management Framework, and Remote Systems Explorer that were specifically designed with the embedded developer in mind. That, coupled with the Eclipse IDE’s broad use amongst professional Java developers makes its leadership in IoT clear.

In addition, close to 10% also use Eclipse Che, our community’s next generation cloud-based tooling solution. It really seems part of the future of IoT is in the cloud, one way or another.

Access the full findings of the 2019 IoT Developer Survey here.

Thanks to everyone who took the time to fill out this survey, and thanks again our Eclipse IoT members for their help with the promotion.

We are very interested in hearing your thoughts and feedback about this year’s findings. And, of course, we are always open to suggestions on how to improve the survey in the future!

Written by Mike Milinkovich

April 17, 2019 at 7:00 am

Posted in Foundation, Open Source

Measuring Industrial IoT’s Evolution

Today the Eclipse IoT Working Group announced major milestones as IoT’s largest Open Source community:  41 member companies, 37 projects, and 350 contributors. It’s hard to believe that it all started in 2011 with just three projects and the basic goal to reduce the complexity of developing machine-to-machine IoT solutions.

And it’s an interesting day to reflect on “where we are today” on the Industrial IoT adoption curve.

Where the arrival of consumer IoT adoption is obvious in our day to day lives–with smart thermostats, smart doorbells, Alexa and Google voice attendants, and ever more gadgets creeping into our smart homes–industrial IoT’s progress has been much trickier to follow.

Key industries in industrial IoT — like manufacturing — have companies that have been around for 40, 50 and 100 years. There’s an inherent complexity in rolling out new technology in brownfield scenarios. It’s much more difficult to drop new technology into plants with massive existing computer-controlled systems, each with their own alphabet soup of protocols and frameworks that people outside of that industry have never even heard of.

Remember the Earliest Days of the Commercial Internet?

The cleanest way I can think to explain where we are in industrial IoT adoption today is to draw an analogy to the early days of the commercial Internet.

A lot of people’s concept of the Internet’s origins is Mosaic and the advent of the web browser. Sure, the human interface to the web — the modern browser — was a critical enabler for the commercialization of the Internet. But I think the plumbing — and more specifically, the LAMP stack — was the most critical enabler for the Internet’s acceleration from disparate connected systems on academic and science campuses, to the web as we know it today.

The industry’s standardization on the Linux, Apache, MySQL, and PHP scripting language open source “stack” brought uniformity, predictability, and scalability guarantees for everyone building web applications. Those guarantees inspired the massive wave of innovation in web applications that allowed businesses to capture new revenue opportunities, while the underlying stack just worked. Industry doesn’t want to innovate below the value line–it wants to create new services on top of standard infrastructure.

To date, Industrial IoT still awaits its LAMP stack, to give industry the uniform building blocks and graduate away from the proprietary one-offs of the first generations of creating IoT systems. Eclipse IoT represents the largest open source community that’s racing to standardize on those open, interoperable, and flexible components for industrial IoT. It is our conviction that the basic building blocks of the IoT must be open source in order to enable the full array of highly scalable business models necessary to the IoT’s success.

Eclipse IoT: Building the LAMP-Like Stack for Industrial IoT

Let’s take a look at some Eclipse IoT projects that I believe have the same characteristics of modular, open source components, with broad appeal to industrial IoT use cases today. Obviously these aren’t perfectly analogous to Linux, Apache, MySQL and Perl / PHP / Python – but I think the case can be made that they are addressing some of the critical application infrastructure pieces that industrial IoT needs to take off. And just like the LAMP stack, all of these components are 100% open source, and therefore offer the flexibility and permissionless innovation characteristics that helped launch the commercial Internet.

Eclipse Paho

In terms of protocols, Message Queuing Telemetry Transport (MQTT) is the most widely adopted in IoT. While it’s been around for a dozen years, MQTT remains the standard of choice for IoT messaging with 80% of Eclipse IoT Developer survey takers using it. Eclipse Paho is a hardened open source client implementation that focuses on integration with a wide range of middleware, programming and messaging models..

Eclipse Tahu / SparkPlug

MQTT is very lightweight and easy to understand, but does not allow out of the box connectivity. SparkPlug compliments the transport layer–so you can get immediate interoperability. That’s a huge missing piece now. Topic structures, payload structures, all that stuff. Eclipse Tahu extends that capability of SparkPlug and addresses the existence of legacy SCADA/DCS/ICS protocols and infrastructures to provide a much-needed definition of how best to apply MQTT into these existing industrial operational environments.

Eclipse Kura

Kura is a gateway project that provides all the technology you need for building the middle tier in an industrial IOT application. Most IoT implementations have sensors that send telemetry data to some gateway device that does processing at the edge, then determines whether that data needs to be shared with higher order business processes. One of the big responsibilities is protocol translation. Coming in could be any number of low level industrial protocols you’ve never heard of, then going out would be translated for the cloud, over MQTT or HTTP itself. Kura focuses on MQTT–allowing you to data into on premise business process applications or to the cloud for large scale collection. The constrained devices that are collecting data at the edge need to funnel your data back through routers and firewalls, and Kura provides a critical gateway to allow the brokering of data between the sensors, processing at the edge, and publishing via MQTT to IoT cloud platforms such as Eclipse Kapua.

Eclipse ioFog

Where constrained devices are tend to be cheap sensors with limited functionality, edge devices tend to push processing, memory and compute to the edge, to avoid the round-robin back to datacenters and the cloud (which is not possible for latency reasons).

Conclusions

If industry is arguing over how to build and deploy and get interoperability those are extreme barriers to widespread adoption of industrial IoT. That’s the case for an industry standard stack based on common standards, and that’s why we firmly believe the future of IoT will be open source.

There was a version of the Internet that existed for many years. Before the browser came along and before HTTP and HTML, the interfaces to the Internet were command line interfaces that only a very technical person would love. Once the browser came along, there was the possibility of widespread adoption. But the widespread adoption could not have happened if the server side equation were proprietary. We are at a similar inflection point with industrial IoT. The combination of open source, open standards, and the backing of a diverse ecosystem of partners will be key to delivering the interoperability and flexibility required to break free of locked-in, proprietary solutions and see adoption soar.

Written by Mike Milinkovich

February 25, 2019 at 8:00 am

Posted in Foundation

Eclipse Foundation: 15 Years Young

Saturday, February 2, 2019 marks the 15th birthday of the Eclipse Foundation. That was the day that it was publicly and officially announced, and the opening day of the first ever EclipseCon conference.

The creation of the Eclipse Foundation was quite an event at the time. It was really the first time that a member-supported consortium was married to a truly open and meritocratic open source project community. In 2004, the existing open source foundations were organizations like Apache and Mozilla, which are organized as charities. The consortium approach is a model that has become completely normalized (think Linux Foundation, Cloud Foundry, CNCF, etc.), but in 2004 it was very novel. In my personal experience the balance that we have within the Eclipse community between open source development, and fostering the use and adoption of that technology has been incredibly powerful.

There were 50 organizations that were founding members of the Eclipse Foundation, but it should be recognized that IBM, SAP, HP, and Intel did the heavy lifting in drafting the Bylaws and establishing the legal framework for the EF. IBM and SAP remain strategic members of the Eclipse Foundation to this day, and their support is greatly appreciated. From 50 we have grown to over 275, and that growth reflects the continuing relevance of the Eclipse Foundation to the software and broader technology industry.

But it has been the growth of the project community at Eclipse that has been the most exciting. When the Eclipse Foundation was founded 15 years ago, there were about 12 projects hosted here. That number is now over 360. Our committer population has grown from about 150 in 2004 (mostly IBMers) to a very diverse group of almost 1600. But the growth in the breadth of technology hosted at the EF has been striking. Our roots are in desktop developer tools, and the Eclipse IDE remains our most broadly used project. But our community has grown in ways that we never imagined at the outset: modeling and model-based engineering environments, the Internet of Things, automotive technologies, geospatial, and cloud native Java runtimes are all now significant pieces of the overall Eclipse community. What all of these projects have in common are a shared community of practice around the Eclipse Development Process, and our robust intellectual property management.

Interestingly, we’re seeing project growth at the Eclipse Foundation continuing to accelerate. Last year was a record year of project growth. You may assume that was because of the migration of Java EE from Oracle to Jakarta EE at the Eclipse Foundation, but we had significant growth over and above that in other areas such as IoT.

The past 15 years has been an adventure. The Eclipse Foundation has survived and thrived in a world that has changed dramatically over that period of time. But more importantly, the community that we serve has grown and thrived. There are far too many people that deserve a “thank you” than I could possibly list here. But you know who you are. So thanks to all, and looking forward to many more years of success for the Eclipse community.

Written by Mike Milinkovich

February 1, 2019 at 3:00 am

Posted in Foundation

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!

Written by Mike Milinkovich

November 5, 2018 at 1:27 pm