New Survey: How Do Developers Feel About Enterprise Java in 2023?
The results of the 2023 Jakarta EE Developer Survey are now available! For the sixth year in a row, we’ve reached out to the enterprise Java community to ask about their preferences and priorities for cloud native Java architectures, technologies, and tools, their perceptions of the cloud native application industry, and more.
From these results, it is clear that open source cloud native Java is on the rise following the release of Jakarta EE 10.The number of respondents who have migrated to Jakarta EE continues to grow, with 60% saying they have already migrated, or plan to do so within the next 6-24 months. These results indicate steady growth in the use of Jakarta EE and a growing interest in cloud native Java overall.
When comparing the survey results to 2022, usage of Jakarta EE to build cloud native applications has remained steady at 53%. Spring/Spring Boot, which relies on some Jakarta EE specifications, continues to be the leading Java framework in this category, with usage growing from 57% to 66%.
Since the September 2022 release, Jakarta EE 10 usage has grown to 17% among survey respondents. This community-driven release is attracting a growing number of application developers to adopt Jakarta EE 10 by offering new features and updates to Jakarta EE. An equal number of developers are running Jakarta EE 9 or 9.1 in production, while 28% are running Jakarta EE 8. That means the increase we are seeing in the migration to Jakarta EE is mostly due to the adoption of Jakarta EE 10, as compared to Jakarta EE 9/9.1 or Jakarta EE 8.
The Jakarta EE Developer Survey also gives us a chance to get valuable feedback on features from the latest Jakarta EE release, as well as what direction the project should take in the future.
Respondents are most excited about Jakarta EE Core Profile, which was introduced in the Jakarta EE 10 release as a subset of Web Profile specifications designed for microservices and ahead-of-time compilation. When it comes to future releases, the community is prioritizing better support for Kubernetes and microservices, as well as adapting Java SE innovations to Jakarta EE — a priority that has grown in popularity since 2022. This is a good indicator that the Jakarta EE 11 release plan is on the right direction by adopting new Java SE 21 features.
2,203 developers, architects, and other tech professionals participated in the survey, a 53% increase from last year. This year’s survey was also available in Chinese, Japanese, Spanish & Portuguese, making it easier for Java enthusiasts around the world to share their perspectives. Participation from the Chinese Jakarta EE community was particularly strong, with over 27% of the responses coming from China. By hearing from more people in the enterprise Java space, we’re able to get a clearer picture of what challenges developers are facing, what they’re looking for, and what technologies they are using. Thank you to everyone who participated!
Learn More
We encourage you to download the report for a complete look at the enterprise Java ecosystem.
If you’d like to get more information about Jakarta EE specifications and our open source community, sign up for one of our mailing lists or join the conversation on Slack. If you’d like to participate in the Jakarta EE community, learn how to get started on our website.
Product Liability Directive: More Bad News for Open Source
In my previous two blog posts I discussed concerns with the European Cyber Resilience Act (“CRA”) which we believe will harm both the open source community and the innovation economy in Europe. But the CRA needs to be understood as part of a larger legislative framework. In this post we will examine the potential impact of the proposed changes to the European Product Liability Directive (“PLD”) on the open source community and ecosystem.
As in previous discussions I think it is important to note that the intentions of the PLD are good. No one can argue that the time has come to protect consumers from poor software. But at the same time, it is important to ensure that the consumer liability obligations are borne by the economic actors who deliver products and services to consumers, and not by the open source community which enables so much benefit to society by providing free software but does not share in the profits of the delivery.
As I understand it, the purpose of the CRA is to establish which parties are responsible for ensuring the quality of software products, particularly as it relates to cybersecurity. The purpose of the PLD is to establish which parties are liable for defects which cause harm to individuals or their property. So strictly speaking, my assertion in my previous blog posts that the CRA will break the limited liability obligations that underpins free software was incorrect. It is the PLD which is doing that.
The European Commission presented a draft of the revisions to the PLD last September, and it is going through the process of being adopted by the European Parliament and the Council of the European Union. As a Directive, the PLD will be interpreted by each member state of the European Union and applied to updates of the local laws in each country. The specific intent of these revisions are to update the PLD of 1985 to address issues related to the modern digital economy. One of the key features of the PLD is its “no fault liability” model where injured parties can seek redress without demonstrating any error or fault on the part of the product manufacturer. The proposed revision explicitly expands the scope of no fault liability to cover software and artificial intelligence, and adds “loss or corruption of data” as a harm that could be suffered by a consumer.
There are numerous legal summaries of the PLD available, but this one from the law firm Baker Mackenzie provides a nice overview, as does this one from the law firm Cooley.
It has long been understood that product liability could not be completely waived by open source licenses in Europe. Hence, the “…to the extent permissible by law…” statements you see in many licenses. Since at least 1985, there have been strict provisions in Europe that you were always liable for harm caused to natural persons or their personal property as a result of using a defective product. From the perspective of an open source developer, the PLD extends and modernizes this legal framework in the following important ways:
- It explicitly extends the definition of product to include software and artificial intelligence;
- It explicitly extends the definition of harm to include loss or corruption of data;
- The definition of manufacturer (formerly producer) has been extended to cover developers, providers of software, providers of digital services, and online marketplaces;
- It makes it clear that a cybersecurity vulnerability is a product defect, and that failure to update a product to protect against a vulnerability may result in liability;
- It makes it clear that if a component is defective, liability may extend to the manufacturer of the component (e.g. the developer of the open source software), in addition to the manufacturer of the end product;
- Distribution of a product or component in Europe explicitly incurs liability obligations on the part of the distributor, unless they can identify a responsible economic actor in Europe; and
- There is an attempt to exclude open source from the provisions of the Directive, but as previously discussed the “…outside the course of a commercial activity…” language means that the exclusion is not helpful in practice.
Article 7 of the PLD goes to great lengths to identify the economic operators who can be held liable for a defective product, with a particular emphasis on identifying an entity in Europe who can bear the responsibility for a defective product made available in the single market. If you parse Article 7, who get something like the following to determine the party in Europe liable for a defective product:
- If the manufacturer is European, then the manufacturer is liable.
- Otherwise, if the importer or manufacturer’s authorized representative are European, then the importer and/or manufacturer’s authorized representative are liable.
- If none of the above conditions apply, each distributor is liable (each distributor is given 1 month to identify one of the above economic operators to hold the bag)
Note that the manufacturer of a defective component also becomes liable.
Should Open Source Developers be Worried?
I think they should. Particularly if they are located in Europe.
Huge caveat here. I’ve been studying the PLD for a couple of weeks now, and every time I read it I think of more corner cases and more scenarios. If anyone finds fault in my analysis or logic, do please let me know!
Scenario One
Imagine a scenario where a year ago or so a consumer in Europe lost data as a result of using the Wizbang product from BigCo GmbH. The vulnerability in Wizbang was caused by the famous Log4shell bug. As part of its normal build process, BigCo downloaded the Apache Log4j jar file from Maven Central. Under the PLD framework, the Apache Software Foundation (“ASF”) is the manufacturer of the Apache Log4j jar file and Sonatype (the company controlling Maven Central) is the distributor of the Log4j component as they made the Log4j software available to the European market. (The relevant definition reads “…‘making available on the market’ means any supply of a product for distribution, consumption or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge”). Both the ASF and Sonatype are US based organizations.
Under the PLD, BigCo, the ASF, and Sonatype are all ‘economic operators’ involved in the development of the Wizbang defective product. As mentioned above, Article 7 of the PLD lays out the liability obligations for each of the various types of economic operators.
My read of the PLD is that as the European manufacturer of Wizbang and the importer of the Log4j component, BigCo GmbH would be liable to consumers of the defective product. I think the ASF would not be held liable for the defect in Log4j because it does not meet the definition of an economic operator in Europe. I.e. the ASF has no legal presence in Europe. Similarly, Maven Central is a distributor in this context, but the algorithm in Article 7 puts the importer ahead of the distributor in the queue for liability obligations.
Scenario Two
Same as above, but instead the defective open source component is (say) the Eclipse Modeling Framework (EMF), so the component manufacturer is the Eclipse Foundation AISBL, a European-based open source foundation.
My read of the PLD is that as the European manufacturers of the Wizbang product and the EMF component, BigCo GmbH and the Eclipse Foundation would both be jointly and severally liable to consumers of the defective product. If I am correct, this scenario puts European open source projects, communities, and foundations at a disadvantage relative to their international peers.
Summary
The good news is that I can’t think of a scenario where Maven Central, or services like it, become liable as a distributor under the PLD. The components they distribute would be used by a manufacturer and there are several layers of economic operators in front of a component distributor before liability results. The same seems to be true for open source foundations based outside of Europe.
The bad news is that it does appear that the PLD as currently worded would expose European-based open source projects to product liability. I have to assume that this was an unintended consequence.
Proposed Enhancements
I hypothesize that when some people think of open source software components and the open source supply chain, they think of something like a braking system module that is assembled into a passenger car. After all, terminology like “component” and “supply chain” lends itself perfectly to that interpretation. I believe that a closer analogy would be inputs to a chemical process. Don’t think of a “braking component”, think acetate or sulphuric acid. I think this analogy is correct because beyond the sheer malleability of software, it is important to recall that open source software is by definition not restricted to any field of use. Every piece of open source software can (and is) used for any purpose that anyone can find for it. To give just one example, the Eclipse IDE platform was designed to implement desktop developer tools. But over the years it has ended up being used in scientific instruments on the International Space Station, to control medical imaging devices, mission planning for the Mars Rover, operations control of major railway networks, and ground station control software for space satellites. The adopters of open source have rich imaginations indeed.
The point of the above is that it is essential that open source software be excluded from the strict, no-fault liability obligations of the PLD. Not because open source developers are entitled to special treatment, but because the liability truly rests with the organization that placed the open source software into a product, and placed that product into the hands of a consumer. It is the act of using open source software that makes it critical, not the act of publishing or distributing it.
To that end, I feel that the correct enhancement is to strengthen the exclusion of open source in the PLD to make it much clearer than it currently is.
The Gory Details
For those who want to look into the language of the PLD, here are what I noticed as the relevant sections and what they mean. (Emphasis added by me in a few places.)
- (12) Products in the digital age can be tangible or intangible. Software, such as operating systems, firmware, computer programs, applications or AI systems, is increasingly common on the market and plays an increasingly important role for product safety. Software is capable of being placed on the market as a standalone product and may subsequently be integrated into other products as a component, and is capable of causing damage through its execution. In the interest of legal certainty it should therefore be clarified that software is a product for the purposes of applying no-fault liability, irrespective of the mode of its supply or usage, and therefore irrespective of whether the software is stored on a device or accessed through cloud technologies. The source code of software, however, is not to be considered as a product for the purposes of this Directive as this is pure information. The developer or producer of software, including AI system providers within the meaning of [Regulation (EU) …/… (AI Act)], should be treated as a manufacturer.
So Recital 12 makes it clear that software is a product under the PLD and that the developer is the manufacturer.
- (13) In order not to hamper innovation or research, this Directive should not apply to free and open-source software developed or supplied outside the course of a commercial activity. This is in particular the case for software, including its source code and modified versions, that is openly shared and freely accessible, usable, modifiable and redistributable. However where software is supplied in exchange for a price or personal data is used other than exclusively for improving the security, compatibility or interoperability of the software, and is therefore supplied in the course of a commercial activity, the Directive should apply.
Recital 13 provides a carve out for open source. However, it retains the same fatal flaw as the CRA in that the carve out applies only to “software developed or supplied outside the course of a commercial activity”, which is woefully misplaced if it is intended to provide any protection of the open source ecosystem from the scope of this legislation. To see why, please see Maarten Aertsen’s blog post.
- (23) In order to reflect the increasing prevalence of inter-connected products, the assessment of a product’s safety should also take into account the effects of other products on the product in question. The effect on a product’s safety of its ability to learn after deployment should also be taken into account, to reflect the legitimate expectation that a product’s software and underlying algorithms are designed in such a way as to prevent hazardous product behaviour. In order to reflect that in the digital age many products remain within the manufacturer’s control beyond the moment at which they are placed on the market, the moment in time at which a product leaves the manufacturer’s control should also be taken into account in the assessment of a product’s safety. A product can also be found to be defective on account of its cybersecurity vulnerability.
Recital 23 makes it clear that a cybersecurity vulnerability can be considered a product defect, and hence explicitly incur liability.
- (26) The protection of the consumer requires that any manufacturer involved in the production process can be made liable, in so far as their product or a component supplied by them is defective. Where a manufacturer integrates a defective component from another manufacturer into a product, an injured person should be able to seek compensation for the same damage from either the manufacturer of the product or from the manufacturer of the component.
Recital 26 makes it clear that if an open source component is integrated into a product, and that open source component is found to be defective, the developer of that open source component may be liable.
- (38) The possibility for economic operators to avoid liability by proving that a defect came into being after they placed the product on the market or put it into service should also be restricted when a product’s defectiveness consists in the lack of software updates or upgrades necessary to address cybersecurity vulnerabilities and maintain the product’s safety. Such vulnerabilities can affect the product in such a way that it causes damage within the meaning of this Directive. In recognition of manufacturers’ responsibilities under Union law for the safety of products throughout their lifecycle, such as under Regulation (EU) 2017/745 of the European Parliament and of the Council, manufacturers should also be liable for damage caused by their failure to supply software security updates or upgrades that are necessary to address the product’s vulnerabilities in response to evolving cybersecurity risks. Such liability should not apply where the supply or installation of such software is beyond the manufacturer’s control, for example where the owner of the product does not install an update or upgrade supplied for the purpose of ensuring or maintaining the level of safety of the product.
Recital 38 makes it clear that a failure to properly update a product to protect any security vulnerabilities is considered a defect and incur liability on the part of the manufacturer.
- (40) Situations may arise in which two or more parties are liable for the same damage, in particular where a defective component is integrated into a product that causes damage. In such a case, the injured person should be able to seek compensation both from the manufacturer that integrated the defective component into its product and from the manufacturer of the defective component itself. In order to ensure consumer protection, all parties should be held liable jointly and severally in such situations.
Recital 40 makes it clear that the manufacturer of a defective component is liable to the consumer, as well as the manufacturer of the end product.
- (42) The objective of consumer protection would be undermined if it were possible to limit or exclude an economic operator’s liability through contractual provisions. Therefore no contractual derogations should be permitted. For the same reason, it should not be possible for provisions of national law to limit or exclude liability, such as by setting financial ceilings on an economic operator’s liability.
Recital 42 makes it clear that the limitations of liability and no warranty clauses in open source licenses are superseded by the PLD.
Cyber Resilience Act: Good Intentions and Unintended Consequences
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.)
- 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.
- 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.
- 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.
- 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.
European Cyber Resilience Act: Potential Impact on the Eclipse Foundation
Europe has proposed new legislation intended to improve the state of cybersecurity for software and hardware products made available in Europe. The Cyber Resilience 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:
- Open-source software vs. the proposed Cyber Resilience Act by Maarten Aertsen.
- The EU’s Proposed Cyber Resilience Act Will Damage the Open Source Ecosystem by Olaf Kolkman.
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.
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!
Life at Eclipse 