Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

European Cyber Resiliency Act: Potential Impact on the Eclipse Foundation

with 5 comments

Europe has proposed new legislation intended to improve the state of cybersecurity for software and hardware products made available in Europe. The Cyber Resiliency Act (“CRA”) will mandate that all manufacturers take security into account across both their development processes and the lifecycle of their products once in the hands of consumers. 

This document discusses the legislation and the potential impact it may have on the Eclipse Foundation and its 400+ projects and community. Many of the issues noted could have a similar impact on other open source organizations and projects. It is written based on our reading of the current draft legislation and a number of assumptions stated below. Note that is consciously does not include a discussion of possible revisions to the legislation, although we may post a followup which does. It also does not include any discussion concerning the warranty and product liability provisions of the legislation as we have not yet analyzed the impact those may have on us.

We are sincerely looking for comments and feedback, as it is quite possible that we have misunderstood or misinterpreted the documents.

It is important to stress that the Eclipse Foundation is better positioned to deal with the fallout from the CRA than many other open source organizations. We have staff. We have some resources. We have common community processes and practices shared across our many projects. We have CI/CD infrastructure shared by most (but not all) of our projects. We have a security team, written security policies and procedures, and are a CVE numbering authority. Despite being in a better position than most, we fear that the obligations set forth by the legislation will cripple the Eclipse Foundation and its community. 

There are a number of other excellent summaries of the worrisome impact of this legislation on the open source ecosystem. We highly recommend reading:

Both of those articles primarily focus on the potential impact of the CRA on individual open source projects. Olaf’s document in particular suggests improvements to the draft. In this document we want to focus on the impact on an organization such as the Eclipse Foundation and its open source projects if the CRA was approved in its current form. How the CRA should or could be amended is being discussed elsewhere. The purpose of this document is to provide a resource explaining the impact of the legislation as it stands today.

It is important to note that the CRA does make a laudable attempt to carve out free and open source software but only “…outside the course of a commercial activity…”. Maarten Aertsen does an excellent job of summarizing the problems with this carve out. In particular he references a definition of commercial activity used in EU Blue guide to the implementation of EU product rules which states:

Commercial activity is understood as providing goods in a business related context. Non-profit organisations may be considered as carrying out commercial activities if they operate in such a context. This can only be appreciated on a case by case basis taking into account the regularity of the supplies, the characteristics of the product, the intentions of the supplier, etc. In principle, occasional supplies by charities or hobbyists should not be considered as taking place in a business related context.

Assumptions

  • The CRA references the term “product” over 600 times but does not appear to define it. The act does define the term ‘product with digital elements’. For the purposes of this document we will assume that for the purposes of the CRA, any Eclipse Foundation project software made generally available to the public as a downloadable, installable, and executable binary would be considered a ‘product with digital elements’ under the regulation.
    • In addition, there are at least some EF projects which may be considered ‘critical product with digital elements’ (e.g. Kura, Keyple, ioFog, fog05) or ‘highly critical product with digital elements’ (e.g. Oniro, Leda, 4diac) .
  • The CRA defines ‘manufacturer’ as “any natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under his or her name or trademark, whether for payment or free of charge”. For the purposes of this document, we will assume that the Eclipse Foundation would be considered the manufacturer of the binaries produced by its projects. Among other reasons justifying this assumption, the Eclipse Foundation asserts that it owns the trademark rights for each of its projects and the binaries they release and (resources permitting) we market them as works of the Eclipse Foundation. 
  • As mentioned above there is an attempt to exclude free and open source software produced outside the course of a commercial activity from the scope of the legislation. For the purposes of this document we will assume that Eclipse Foundation project software would be considered as produced under the course of a commercial activity, and would therefore be subject to the legislation. This assumption is based on the following:
    • The Eclipse Foundation is not a charity. It is a Belgian-incorporated international nonprofit association of hundreds of business members. 
    • Eclipse Foundation projects are not, generally speaking, developed by hobbyists. While some are, our projects are commonly developed by full-time employees of our member companies or by individuals who are making a living from consulting services related to their project work. 
    • Eclipse Foundation projects provide goods in a business related context. By that we mean that EF projects are largely intended to provide software which is immediately ready for adoption by businesses either as a component within a commercial product or by use by employees in their daily work.
    • Eclipse Foundation projects provide a regularity of supply. As one extreme example, the Eclipse IDE takes great pride in having not missed a single release date in over 15 years.
    • Eclipse Foundation projects deliver high quality software, equivalent to the quality found in commercial products. So the “characteristics of the product” are equivalent to commercial products. 

Having said all of the above it is important to remind the reader that all Eclipse Foundation projects provide their software for free, on a non-profit basis, and under OSI-approved open source licenses which permit further use, study, modification, and distribution. 

Impact Assessment

CE Markings for Software Products

Fundamentally, the core of the proposed legislation is to extend the CE Mark regime to all products with digital elements sold in Europe. Our assumption based on the current text is that this process will be applied to open source software made available under open source licenses and provided free of charge, ostensibly under licenses which disclaim any liability or warranty. We are deeply concerned that the CRA could fundamentally alter the social contract which underpins the entire open source ecosystem: open source software provided for free, for any purpose, which can be modified and further distributed for free, but without warranty or liability to the authors, contributors, or open source distributors. Legally altering this arrangement through legislation can reasonably be expected to cause unintended consequences to the innovation economy in Europe.

Without a clearer exemption for open source, in order to comply with the legislation the Eclipse Foundation will be required to:

  • Develop, document, and implement policies and procedures for every project at the Eclipse Foundation to ensure they are conformant with the requirements of the CRA including:
    • All of the development and post-release security requirements set forth in Annex I, including providing notification and update mechanisms. 
    • All of the user documentation requirements set forth in Annex II.
    • All of the product technical documentation set forth in Annex V, including “…complete information on the design and development of the product…including, where applicable, drawings and schemes and/or a description of the system architecture explaining how software components build on or feed into each other and integrate into the overall processing.”
  • For each EF project release, prepare the project-specific documentation required by Annex V, including “…an assessment of the cybersecurity risks against which the product with digital elements is designed, developed, produced, delivered and maintained…”.
  • Determine for each project whether it meets the definition of ‘product with digital elements’, ‘critical product with digital elements’, or ‘highly critical product with digital elements’.
    • For each project which is a ‘product with digital elements’, establish, complete, and document a CE mark self assessment process.
    • For each ‘critical product with digital elements’ or ‘highly critical product with digital elements’ engage with an external CE auditing body and complete the additional processes required to get the CE mark approval. Note that it is not clear to us what the costs in time, resources, and money would be to implement these external audit processes. Our assumption is that they would be substantial.

      It is also important to note that in most other domains regulated with CE markings they are done where there are well known standards, specifications, and/or certification processes in place. These are not in place for most Eclipse Foundation open source projects. This could significantly increase the costs and risks associated with conformance.
  • For each single project release, document that the relevant CE mark process is followed (as described above), that an EU declaration of conformity is written and signed by an officer of the foundation, that the CE mark is affixed, and that the technical documentation and EU declaration of conformity is made available for at least 10 years after the release. Note that we estimate that in any given year the Eclipse Foundation’s projects make available several hundred releases.

Article 4(3)

Member States shall not prevent the making available of unfinished software which does not comply with this Regulation provided that the software is only made available for a limited period required for testing purposes and that a visible sign clearly indicates that it does not comply with this Regulation and will not be available on the market for purposes other than testing.

Many Eclipse Foundation projects make integration, nightly, weekly, and milestone builds available under their open source licenses available indefinitely. The intent is to provide for community testing and for traceability. These binaries are marked as such, but the terms under which they are provided do not require that they be used for testing purposes only. 

It is not clear how this requirement could be implemented by any open source project using modern CI/CD infrastructure and operating under the principle of transparency. Even if the binaries were marked as “testing purposes only”, the open source licenses they are provided under do, in fact, permit uses other than testing. Further, it is common practice to provide intermediate builds for extended periods of time (often permanently) to provide testers with access to past builds for problem identification and remediation. Discontinuing that practice would be significantly disruptive. And any solution based on providing intermediate builds under non-open source licenses would be impossible for Eclipse Foundation projects, as the EF does not own the copyright and obtaining the approval of all contributors would be impractical. In summary, compliance with this CRA requirement would represent a significant blow to open source development best practices. 

Article 5(1) and Section 1 of Annex I

(1) Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks

At a minimum this would require the development and enforcement of written policies requiring every project to assess their level of cybersecurity risk and to implement processes to ensure that there is a determination of the risk level and a justification for the development processes adopted.

(2) Products with digital elements shall be delivered without any known exploitable vulnerabilities
(3) On the basis of the risk assessment referred to in Article 10(2) and where applicable, products with digital elements shall:
(a) …(j)

These would require a material change to our community’s release processes to require attestations that there are no known vulnerabilities and to comply with the many requirements listed. 

(k) ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic updates and the notification of available updates to users.

With a few exceptions, EF projects do not “call home”, require any sort of user registration, and do not provide a mechanism for notifying all users that an update is either available or required. Implementing these requirements would require a whole new infrastructure to be mandated across all projects. 

Article 5(2) and Section 2 of Annex I “Vulnerability Handling Requirements”

In general, the Eclipse Foundation is in decent shape to deal with many of the stated requirements. As noted above we have a security team, written security policies and procedures, and are a CVE numbering authority. However, there are two notable elements in the requirements. 

(1) identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product

This would impose a legal requirement to produce SBOMs for all EF projects. Although it is something we aspire to, this is a very significant effort. It would also require actively monitoring all project dependencies for known vulnerabilities in dependencies. This is generally considered an unsolved problem within the open source ecosystem with no known path to implementation.

(3) apply effective and regular tests and reviews of the security of the product with digital elements;

These would require a material change to our community’s development processes to mandate a whole class of testing which is not currently mandated for our projects. This is a very significant effort both to implement and to maintain.

Written by Mike Milinkovich

January 15, 2023 at 9:22 pm

Happy Holidays from the Eclipse Foundation

As 2022 draws to a close, I would like to express my sincere gratitude to our contributors, committers, members, and the Eclipse Foundation team for your commitment, passion, professionalism, persistence, and tremendous contributions to our community’s success. 

This year included a number of accomplishments and milestones in the Eclipse community. We welcomed over 20 new projects, 55 new member companies, and a new working group with Eclipse Software Defined Vehicle. Also, this year, the Board of Directors approved the creation of Interest Groups, the next step in furthering the Eclipse Foundation’s governance framework to enable “innovation through collaboration” by empowering members to work together using a lighter-weight governance structure than our more formal working groups. Find out how to start a collaboration and share the opportunity with your colleagues and network.

After 3 years of virtual interactions, we held our first in-person EclipseCon in Ludwigsburg. This chance to connect with friends and colleagues, new and old, was not taken for granted with over 415 participants. We could not make it happen without our speakers, sponsors and participants! Mark your calendars for the next EclipseCon – October 16-20, 2023.

Moments like that remind us of the importance of coming together, and we hope that the new year will give us many more opportunities for our global community to collaborate.

All the best for 2023!

Written by Mike Milinkovich

December 20, 2022 at 7:30 am

Posted in Foundation

Introducing the Automotive Open Source Summit 

2022 has been a fantastic year for the Eclipse Foundation. We’ve managed to grow all aspects of our organization, due in no small part to the ongoing proliferation of open source across industries worldwide. Perhaps no one Working Group exemplifies our efforts in 2022 more than the Eclipse Software Defined Vehicle (SDV) Working Group, which has seen significant momentum in terms of new members, innovation, and new projects. Just this week, Mercedes-Benz Tech Innovation has announced they will be lending their own resources and talents to Eclipse SDV. With this in mind and before we all part ways for the holidays, I wanted to cap this year with some exciting news related to just this subject. 

Coming in early June 2023, the Eclipse Foundation and the Eclipse SDV WG will hold the first automotive industry event focused on open source software and collaboration-based innovation. Named the Automotive Open Source Summit and based in the Munich  area, this event will highlight speakers from organizations throughout the auto industry, including organizations outside the Eclipse community, as well as leaders within our own automotive initiatives. This will be a one-day and a half  event and specific details will be finalized early in the new year. 

The Summit will focus on latest trends, “business” topics  targeting executives, senior technical leaders, and other decision makers. The main conference will be preceded by an exclusive executive round table attended by the industry’s most influential leaders. Our goal is that this conference becomes a “must attend” event for all participants in the automotive software ecosystem regardless of whether they are actively engaged with open source technology. In the coming years, we plan on extending the program for developers by designing a technical targeted track.

The Summit will feature speakers from Eclipse automotive initiatives as well as organizations and leaders from outside the Eclipse community. We want to  attract the participation of all high profile open source and open specification initiatives in the automotive industry.

This is just one of the exciting new developments the Eclipse Foundation has percolating for next year. We can’t wait to give you and the rest of the community more details. In the meantime, Happy Holidays to you and yours for 2022 and we look forward to engaging with all of you in 2023! 

Written by Mike Milinkovich

December 16, 2022 at 7:30 am

Survey Says: Confidence Continues to Grow in the Jakarta EE Ecosystem

The results of the 2022 Jakarta EE Developer Survey are very telling about the current state of the enterprise Java developer community. They point to increased confidence about Jakarta EE and highlight how far Jakarta EE has grown over the past few years.

Strong Turnout Helps Drive Future of Jakarta EE

The fifth annual survey is one of the longest running and best-respected surveys of its kind in the industry. This year’s turnout was fantastic: From March 9 to May 6, a total of 1,439 developers responded. 

This is great for two reasons. First, obviously, these results help inform the Java ecosystem stakeholders about the requirements, priorities and perceptions of enterprise developer communities. The more people we hear from, the better picture we get of what the community wants and needs. That makes it much easier for us to make sure the work we’re doing is aligned with what our community is looking for. 

The other reason is that it helps us better understand how the cloud native Java world is progressing. By looking at what community members are using and adopting, what their top goals are and what their plans are for adoption, we can better understand not only what we should be working on today, but tomorrow and for the future of Jakarta EE. 

Findings Indicate Growing Adoption and Rising Expectations

Some of the survey’s key findings include:

  • Jakarta EE is the basis for the top frameworks used for building cloud native applications.
  • The top three frameworks for building cloud native applications, respectively, are Spring/Spring Boot, Jakarta EE and MicroProfile, though Spring/Spring Boot lost ground this past year. It’s important to note that Spring/SpringBoot relies on Jakarta EE developments for its operation and is not competitive with Jakarta EE. Both are critical ingredients to the healthy enterprise Java ecosystem. 
  • Jakarta EE 9/9.1 usage increased year-over-year by 5%.
  • Java EE 8, Jakarta EE 8, and Jakarta EE 9/9.1 hit the mainstream with 81% adoption. 
  • While over a third of respondents planned to adopt, or already had adopted Jakarta EE 9/9.1, nearly a fifth of respondents plan to skip Jakarta EE 9/9.1 altogether and adopt Jakarta EE 10 once it becomes available. 
  • Most respondents said they have migrated to Jakarta EE already or planned to do so within the next 6-24 months.
  • The top three community priorities for Jakarta EE are:
    • Native integration with Kubernetes (same as last year)
    • Better support for microservices (same as last year)
    • Faster support from existing Java EE/Jakarta EE or cloud vendors (new this year)

Two of the results, when combined, highlight something interesting:

  • 19% of respondents planned to skip Jakarta EE 9/9.1 and go straight to 10 once it’s available 
  • The new community priority — faster support from existing Java EE/Jakarta EE or cloud vendors — really shows the growing confidence the community has in the ecosystem

After all, you wouldn’t wait for a later version and skip the one that’s already available, unless you were confident that the newer version was not only going to be coming out on a relatively reliable timeline, but that it was going to be an improvement. 

And this growing hunger from the community for faster support really speaks to how far the ecosystem has come. When we release a new version, like when we released Jakarta EE 9, it takes some time for the technology implementers to build the product based on those standards or specifications. The community is becoming more vocal in requesting those implementers to be more agile and quickly pick up the new versions. That’s definitely an indication that developer demand for Jakarta EE products is growing in a healthy way. 

Learn More

If you’d like to learn more about the project, there are several Jakarta EE mailing lists to sign up for. You can also join the conversation on Slack. And if you want to get involved, start by choosing a project, sign up for its mailing list and start communicating with the team.

Written by Mike Milinkovich

September 26, 2022 at 9:00 am

Posted in Jakarta EE, Open Source

Jakarta EE 10 Brings Java Development Into the Modern Cloud Native Era

Jakarta EE, a Working Group hosted by the Eclipse Foundation, released Jakarta EE 10 today. 

This achievement was only possible because of a global community of contributors. Congratulations and thank you to everyone who played a part in this release. 

There are many new and innovative features added by the Jakarta EE community.

Jakarta EE 10 Enables Modern, Lightweight Java Applications and Microservices

Let’s start with some of the key updates in Jakarta EE 10 — updates that plant Jakarta EE firmly in the modern era of open source microservices and containers. 

Most prominently, Jakarta EE 10 includes a new profile specification: Jakarta EE Core Profile. The Core Profile includes a subset of Jakarta EE specifications that target the smaller, lightweight runtimes needed for microservices development. This is the first new Profile added to the enterprise Java specifications in over a decade.

In addition, new functionality has been added to more than 20 component specifications. For example:

Jakarta EE 10 also broadens support for annotations so it’s easier to build modularized applications and there’s better integration across component APIs.

Finally, I want to point out that Jakarta EE 10 gives enterprises the flexibility to leverage Java in the way that’s best for their organization. They can:

  • Develop and deploy Jakarta EE 10 applications on Java SE 11 as well as Java SE 17, the most current long-term support (LTS) release of Java SE
  • Take advantage of new features, including the modular system, that were introduced in Java SE 9 and supported in Java SE 11

The Jakarta EE Gamble Is Paying Off

This is all great news for Jakarta EE. But to understand how significant this release is, we need to go back to the Java EE days.

Java EE was the bedrock of application development for the Fortune 1000 for 20 years before it moved to the Eclipse Foundation as Jakarta EE. But the first Jakarta EE releases didn’t add new functionality. Then, Jakarta EE 9 introduced a major breaking change: the move to the jakarta.* namespace.

It’s hard to overstate what a gamble that was. Java EE had been basically backwards-compatible for more than two decades. We asked enterprises to change the fundamentals of applications they’d been relying on for a long time. We asked the enterprise Java ecosystem to re-align their products and opens source projects on a new namespace. Oftentimes, when you try to make such a radical change, your ecosystem says no, it’s too much work. And quite a few people thought the Jakarta EE gamble could fail for exactly that reason. 

But it didn’t. IBM, Red Hat, Payara, Spring, the Apache Tomcat and TomEE projects, and Eclipse Jetty, to name a few, all moved to the new namespace with us. 

Now, with new support for modern microservices architectures and containers, Jakarta EE 10 paves the way for Jakarta EE to drive the innovative, multi-vendor standards needed for the future of our industry. 

Get Involved in the Future of Jakarta EE

The momentum around Jakarta EE 10 is well underway. Eclipse GlassFish has released a compatible implementation, and other enterprises and project teams — including Fujitsu, IBM, Oracle, Payara, Red Hat and Tomitribe — are already working towards certifying Jakarta EE 10 compatible products 

Jakarta EE has an exciting future ahead, and we want everyone to participate and contribute. To learn more, connect with the global community. If enterprise Java is important to your business strategy, join the Jakarta EE Working Group. Learn more about the benefits and advantages of membership here.

Written by Mike Milinkovich

September 22, 2022 at 12:00 pm

Posted in Jakarta EE, Open Source

Tagged with , ,