Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Posts Tagged ‘Eclipse Foundation

Cyber Resilience Act: Good Intentions and Unintended Consequences

with 3 comments

In my previous blog post on the European Cyber Resilience Act (“CRA”), I touched on a topic which I feel warrants additional discussion. Specifically: 

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.

First, a mea culpa. In the quote above I stated that “…the proposed legislation is to extend the CE Mark regime to all products with digital elements sold in Europe.” That statement is inaccurate. It should have said “the proposed legislation is to extend the CE Mark regime to all products with digital elements made available in Europe.” That is a critical distinction, as it makes the CRA broadly extra-territorial. In today’s world where most software is downloaded over the internet, “made available” means that the documentation, certification, and liability requirements of the CRA are expected to apply to all software worldwide. 

I honestly believe that CRA was developed with the best of intentions. Software has become critically important to our economies and societies, and to date has been a completely unregulated industry. Recent events such as the SolarWinds and Apache Log4j vulnerabilities have shown that there can be very large economic impacts when something goes wrong. The Log4j event showed that open source software components can have a very large impact due to wide usage. Given that, it is a reasonable position that the time has come to implement regulations upon the software industry, and to ensure that open source software is included within the scope of those regulations. I want to stress that I believe that the open source community very much wants to be part of the solution to the industry problems that we all face with respect to supply chain security. The open source community provides extremely high quality software and takes great pride in the value that it provides to society. 

However, the CRA legislation (along with the companion revisions to the Product Liability Directive) in its current form will have enormous negative effects on both the open source community and the European economy. 

For the purposes of this blog post I am going to ignore for the moment the impact of applying the CE Mark regime to all software all at once, as that would be a long post in its own right. This post will focus on the unintended consequences of applying legal product liability obligations to the open source community and ecosystem. But before doing so, I want to spend a few moments describing what open source software is, and why it is important. If you have a good understanding of that topic, feel free to skip that section. 

The Economics of Open Source

Today’s software systems are mind-bogglingly complex. And for most systems, a very large percentage of the overall code base provides zero product differentiating features. For example, any modern system will require code which allows it to connect to the internet to acquire and share data. Open source at its core is a simple licensing model which allows individuals, researchers, academics, and companies to come together to develop and maintain software which can be freely studied, used, modified, and redistributed. The breadth of software which has been developed under this model encompasses every field of human endeavor. But arguably the most common use case is to share the cost of developing and maintaining software which implement non-differentiating technologies used across a broad spectrum of products and applications. To be clear, “non-differentiating technologies” means implementations in software of the types of technologies that many similar applications must implement. Examples include network access, database access, user authentication, and the like. It is impossible to overstate the economic benefits of being able to reuse software in this way. Reuse decreases lifecycle costs, reduces time to market, and mitigates development risk across every type of system which contains software. Which is to say, every single aspect of social and economic activity. That is why it is estimated that most modern software and cyber-physical products contain 80 to 90 percent open source. It is simply not economically viable to write all software yourself while your competitors are building theirs using open source. 

But the economic benefits of open source only start there. In fact, there is arguably even greater value in the pace of innovation which is made possible by open source. All developers today start their development off by selecting and assembling open source components to form the basis for their product or application. And they are able to do so without asking permission from any of the providers. This ‘permissionless innovation’ has vastly accelerated the pace at which new products in all fields can be developed and brought to market. When open source was first introduced, it was primarily used to commoditize technologies which were already well understood. Today, open source is used to introduce new technologies, in sectors such as Big Data, Cloud, Edge, AI and software defined vehicle, in order to accelerate adoption and create new market segments. 

It is important to remember that open source software is provided at zero cost to the consumer. This completely decouples its value from its sale price. And there are many examples of open source software which are almost immeasurably valuable: Linux, Kubernetes, Apache, and OpenJDK are just a few examples of open source which support multi-billion euro ecosystems. 

It is also important to recognize that open source software is a non-rivalrous good. In fact, it is an anti-rivalrous good in that the more a software component is used, the more valuable it becomes. This is incredibly important to understand: the value of a piece of open source software is not determined when it is made available. It becomes valuable (and potentially critical) when it is used. And the more it is used, the more valuable and critical it becomes. As a logging framework, Log4j was not a piece of software which at face value would be expected to be security critical; it became so because it was so broadly used and adopted. 

Finally, there is no open source business model. Open source licensing has enabled an incredibly successful collaborative production model for the development of software, but that is decoupled from the commercialization of that software. Obviously, given the massive investments in open source someone must be making money somewhere. And they are. Open source technologies are used in virtually every cyber-physical, software, SaaS, and cloud product on the planet. It is also very widely used in the internal bespoke software applications that run our governments, enterprises, and industrials. When we talk of the open source supply chain, it is important to recognize that what we are discussing is the use by governments and commercial organizations of freely provided software. Unlike any other market that I am aware of, the financial resources available to manage and secure the open source software supply chains are solely available to the consumers, rather than the producers. For this reason, it is important that any compliance burden be placed on the downstream commercial adopters and consumers, rather than the producers of open source. 

Unintended Consequences

Which brings me to the risks to Europe’s economy that I see from the CRA. The preamble to the legislation states: “For the whole EU, it is estimated that the initiative could lead to a costs reduction from incidents affecting companies by roughly EUR 180 to 290 billion annually.” On the cost side it states: “For software developers and hardware manufacturers, it will add direct compliance costs for new security requirements, conformity assessment, documentation and reporting obligations, leading to aggregated compliance costs amounting to up to roughly EUR 29 billion.” In other words, spend 29 billion to save 290 billion. The impact assessment further describes that an analysis was done which spurred the decision to extend to legislation to cover all tangible and non-tangible products: 

This option would ensure the setting out of specific horizontal cybersecurity requirements for all products with digital elements being placed or made available on the internal market, and would be the only option covering the entire digital supply chain.

As discussed in my previous blog post, the CRA as currently drafted will be extended to cover virtually all open source software. This will legally obligate producers of open source software to the documentation, certification, and liability provisions of the CRA. Let us focus here solely on the liability topic.

The fundamental social contract that underpins open source is that its producers freely provide the software, but accept no liability for your use, and provide no warranties. Every open source license contains “as is”, no liability, and no warranty clauses. I’ve always assumed that this is simple common sense: if I provide you with a working program that you can study, use, modify, and further distribute freely for any purpose, why should I accept any liability for your (mis)use of that program? It is the companies which commercialize the technology and make a business from it who need to accept liability and provide warranties to their paying customers, not the open source projects which they have freely consumed. The CRA fundamentally breaks this understanding by legislating non-avoidable liability obligations to producers of free software. 

What might be the consequences of forcing the producers of free and open source software made available in Europe to accept statutory liability for code that they provide? Remembering, of course, that all open source software is both developed and distributed over the internet so “made available in Europe” can arguably apply to it all. And also remembering that enormous amounts of open source software are produced worldwide by projects, communities, and nonprofit foundations which make no money off of their software, and who have always operated under the assumption that their liability obligations were extremely low. Thirdly, it is important to remember that open source software is provided for free. The producers of open source do not receive any revenue from users and adopters in Europe, so the usual market incentives to accept additional regulations to retain access to the European single market do not apply.

So with the caveat that these are all hypothetical scenarios, let’s look at some potential unintended consequences of the CRA’s liability obligations. (Some of these points are also made in Brian Fox’s excellent blog post.) 

  1. A reasonable and rational response would be for non-European producers of open source code to state that its use is not permitted in Europe. If you are not willing to accept statutory liability obligations for something you make available for free, a notice file stating the above would be an obvious reaction. What would this mean to the European companies that build products on platforms such as Linux, Kubernetes, Apache, and OpenJDK? I would assume that the vast majority of their procurement and compliance organizations would conclude that they can no longer use those technologies in their product development. Cutting Europe off from these platforms would have catastrophic consequences.
  2. European producers of open source will be at a significant disadvantage relative to their international peers. Since they cannot avoid the liability obligations, they will be forced to accept them as part of their operations. For a small project hosted at (say) Github, it would probably be simpler to just terminate the project and pull its source code off of the internet. For a foundation such as the Eclipse Foundation, amongst other things I would expect that we would be forced to procure a very large liability insurance policy to mitigate the exposure of the organization and its directors and officers to potential liabilities. The result would threaten the €65 billion to €95 billion that open source software development contributes to EU GDP, as per the Commission’s own study.
  3. The CRA extends the liability obligations to distributors of software. In the open source context, some of the most important distributors include the language and platform-specific package distribution sites such as npm, Maven Central, PyPi and the like. None of those sites are in a position to accept liability for the packages they make available. As Brian Fox of Sonatype stated “…the consequence of this would be [Maven] Central, npm, PyPi and countless other repositories being suddenly inaccessible to the European Union.” As Brian is the leader of Maven Central, I am confident he understands what he’s talking about. I cannot stress enough how disruptive it would be to Europe’s business if that should occur.
  4. The CRA liability obligations could also force European business to stop contributing to open source projects. At the moment, it is generally understood that the risk that contributions to open source may incur a liability to the company is low. The CRA changes that equation and as a result European companies may curtail their open source collaborations. This would be extremely damaging to the innovation economy in Europe, for the reasons described in the economics section above. It also runs counter to a number of European wide strategies such as digital sovereignty which explicitly have major open source components. Initiatives such as GAIX-X, Catena-X, Dataspaces, Digital Twins, and Industrie 4.0 all explicitly rely upon open source collaboration which could be at risk under the CRA. 

Europe’s Cyber Resilience Act was developed with the best of intentions. And it is certainly the right time to look at what regulations are appropriate for software generally, and given its importance open source software likely needs to be included in some manner. But the liability obligations imposed by the CRA upon projects, communities, and nonprofit foundations will have negative unintended consequences on Europe’s innovation economy and digital sovereignty initiatives.

Written by Mike Milinkovich

February 23, 2023 at 12:09 pm

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

Open Source Security at the Eclipse Foundation

Open source software is the single most important engine for innovation today. The ability to freely combine software components, frameworks, and platforms frees developers from constantly reinventing the wheel and allows them to focus on the new innovations that users want. Free software also enables business models to scale in ways that proprietary software would never allow. Globally and in all sectors of the economy, building on top of open source software is the dominant approach to delivering successful software systems today. 

However, with great success comes great responsibility. From Heartbleed to SolarWinds to Log4j, securing open source software and its global supply chain has never been more important. The reasons for this are many, but among them is that for too long open source has been treated by many of its consumers as “free as in free beer” where they should have been treating it as “free as in a free puppy.” Contributing to the sustainability of the projects and communities that deliver open source is really no longer a choice. It is a necessity.

At the Eclipse Foundation, we believe that foundations have a role to play in addressing the challenges of securing open source and its supply chain. Specifically, we want to provide services to our projects that help improve their security posture. But doing so requires additional staff and resources. That’s why we are so grateful for the financial support from the OpenSSF’s Alpha-Omega project, being announced today. This money will allow us to start building a team to roll out many of the ideas in our Open Source Software Supply Chain Best Practices document under the leadership of Mikael Barbero, our Head of Security. 

Some of the ways that we are going to put this funding to good use include:

  • Automate the generation of static source-based SBOMs for all Eclipse Foundation project repositories.
  • Implement a SLSA-based project badging program for Eclipse Foundation projects.
  • Initiate a number of security audits for high-profile Eclipse Foundation projects.

We are also going to provide regular and public updates to the community about our progress and initiatives.

Software security is a never-ending process. This funding is the first step in a journey. We appreciate the support of the Alpha-Omega project, and are committed to using it effectively. 

Written by Mike Milinkovich

June 19, 2022 at 7:28 pm

AQAvit Brings Quality Assurance to Adoptium Marketplace and Java Ecosystem

The launch of the Adoptium Marketplace on May 26 is exciting news for the millions of developers, researchers, and organizations who rely on TCK-tested compatible Java runtimes. As noted in the announcement, by providing a vendor neutral home for the OpenJDK ecosystem, the marketplace makes it easier than ever to access Java SE-conformant binaries necessary for cloud native and enterprise deployments.

But there’s more to the story. For a long time, compatibility has been the name of the game when it came to Java implementations. The Adoptium Marketplace has been set up to take the Java ecosystem to the next stage of its development. 

That’s where Eclipse AQAvit comes in. It brings quality assurance metrics into the marketplace, so that the Java community can begin to select binaries not just based on compatibility but on quality. 

Eclipse AQAvit Brings Quality Assurance to Java

Everything in the marketplace will be compatible with the relevant version of the Java SE Technology Compatibility Kit (TCK). 

But TCK compatibility doesn’t tell you anything about the quality of the implementation. In recent years, the number of OpenJDK-based runtime distributions has absolutely exploded. And although many vendors maintain their own release quality tests, OpenJDK distros have historically not been built to any consistent quality standard. It has become increasingly clear that the Java ecosystem needs a consistent, multi-vendor definition of quality.

Ensuring high-quality binaries are ready for production deployment is crucial for the Adoptium Marketplace. The AQAvit project team compiled tens of thousands of tests and built a few of their own to produce a comprehensive, systematic way of ensuring the quality of runtimes available. The AQAvit Quality Verification Suite covers a broad set of requirements, ensuring binaries provide superior: 

  • Performance
  • Security
  • Resilience
  • Endurance

They also ensure that the binaries can pass a wide variety of application test suites and can verify new functionality during runtime development. That’s what’s unique about the Adoptium Marketplace: it provides peace of mind knowing that the binaries are not only compatible but will actually meet the demanding requirements of your enterprise applications.

Contributing Helps Ensure AQAvit Meets Your Needs

And in the spirit of open source, you give a little to get a lot.

Many of the founding members of the Adoptium Working Group are Java developers and vendors, including Alibaba Cloud, Azul, Huawei, IBM, iJUG, Karakun AG, Microsoft, New Relic, and Red Hat. The marketplace enables working group members to promote their Java SE compatible releases verified to Eclipse AQAvit’s quality criteria. Their membership helps support the cloud-based infrastructure that drives Adoptium’s efficiency as a shared community project. In other words, the working group collaborates to create and provide access to high-performance, enterprise-caliber, cross-platform, open source-licensed, and Java-compatible binaries of OpenJDK builds, through the marketplace. 

Contributing to the AQAvit project is one of the best ways to ensure access to runtimes that meet specific needs. We encourage Java community members to get involved and contribute additional tests to cover the use cases their applications require. They’ll be incorporated in the AQAvit test suite, so every binary going forward will have to meet that standard. This way enterprises and developers can be confident any AQAvit-verified binaries they use will function as needed. 

Security Updates for Java

Quality assurance is a big part of what makes the Adoptium Marketplace unique, but it’s not the whole picture. Security fixes are also an important focus.

Once upon a time, you could count on getting security fixes for old versions of Java for a long time. After all, if you’ve deployed a set of applications on a version, you’re probably going to want to use it for a long time. 

That’s no longer the case elsewhere. But all the distributions in the Adoptium Marketplace will be kept up to date with the latest security patches or those patches will be backported to older LTS versions. This way you can be sure that your applications are secure, no matter which version of Java you’re running them on. Of course, this goes for new versions of Java too.

Everything Users Need in One Place

The Adoptium Marketplace brings together all these elements — quality assurance, adaptability to community needs, security updates for every version, sustainability — into a one-stop shop for binaries. Ultimately, this delivers five key assurances to end users:

  • The binary has been tested and is compatible with the relevant version of the Java SE TCK
  • The binary was built in accordance with open source principles
  • The binary has been fully verified using the AQAvit quality verification criteria, having passed through multiple tests to ensure it meets industry quality standards
  • The binary is as secure as possible, with the latest security updates included
  • The binary is brought to you by a vendor committed to supporting and participating in a multi-vendor, vendor-neutral collaboration

If your organization is considering participating in the Adoptium Working Group, have a look at the Charter and Participation Agreement. Or if you have questions, email us at

Written by Mike Milinkovich

May 31, 2022 at 7:33 am

Security Leadership at the Eclipse Foundation

As everyone who is involved in the software industry is well aware, security is a significant topic these days. In particular, open source supply chain security is top of mind across the entire ICT industry. The Eclipse Foundation, its community, its projects, and its working groups all have a strong motivation to be leaders in advocating and implementing security best practices. Our members, adopters, users, and stakeholders all desire that their security risks be mitigated to the degree possible. 

One thing that is clear, however, is that simply putting the burden of added security work on the shoulders of our committers and project leaders is not an option. This topic needs to be addressed by services provided by the Eclipse Foundation to our project community or it will fail. Without strong support in terms of release and build engineering, tooling, and education, developers simply do not have the time, interest, or skills necessary to be responsible for implementing security best practices. It is equally true that security, and particularly supply chain security, requires a programmatic approach. Security is not an attribute that you simply add to existing software.

So we need to provide services to our projects to implement our Open Source Software Supply Chain Best Practices. We envisage this as a collection of services provided to our projects by staff to protect our code repositories, secure third party artifacts, provide security audits, secure build pipelines, and protect build outputs. 

The Eclipse Foundation has long had a security policy, and is a CVE numbering authority. We have a long track record of taking security seriously. However, we are not going to be able to accomplish more without leadership. So, to that end, I am very pleased to announce that we have recently promoted Mikaël Barbero as our new Head of Security. Mikaël is well known to our community as having led our Common Build Infrastructure for many years, as well as having authored the best practices document referenced above. Mikaël will be providing leadership to our security initiatives, and will be working closely with our projects and our IT staff to steadily improve security across the Eclipse community. Some of this work will complement or leverage related efforts to improve our IP processes and provide software bill of materials (SBOMs) for all of our projects. We expect to make a number of program announcements over the coming months, so stay tuned. Please join me in welcoming Mikaël in his new role.

Written by Mike Milinkovich

May 12, 2022 at 7:41 am