Life at Eclipse

We’re thrilled to share that the Eclipse Foundation has signed a collaboration agreement with the OpenAtom Foundation, China’s first open source foundation. Together, we will be driving the development of Oniro, an open source project that builds upon the versatile OpenHarmony operating system. Our aim is to create a modular and globally compatible operating system platform and ecosystem, catering to a wide spectrum of smart devices.

Oniro is more than an open source project. To our knowledge, this marks the first instance of two open source foundations engaging in such detailed technical collaboration – a significant step towards cultivating a global ecosystem for open intelligent devices. The collaborative approach not only ensures a competitive landscape, but also opens doors for participation by organisations worldwide, affirming the far-reaching impact of open source on technical innovation.

OpenHarmony: A Robust Platform

OpenHarmony shines in its versatility, offering robust support for a wide array of smart devices that not only showcases scalability, but also highlights its adaptability. Designed for scalable management of distributed systems, OpenHarmony stands out as a flexible platform capable of accommodating IoT solutions of varying scale.

In recent years, OpenHarmony has made some noteworthy advancements. It’s been certified in over 200 devices and now supports more than 40 development boards. With a vibrant community of over 6,200 contributors and over 16 million lines of code, it has fostered 42 distributions and played a pivotal role in launching over 200 devices.

Oniro: Tailoring OpenHarmony for Western Markets

The goal of the Oniro Project is to elevate the OpenHarmony platform by developing a suite of Western market-focused modifications and add-ons, while preserving compatibility with the core platform. This dynamic collaboration encompasses advancements in application frameworks, system-level components, software development tools, and a toolchain ensuring adherence to regulatory compliance, intellectual property compliance, and licensing.

As per Statista’s 2023 forecast, the worldwide count of connected devices is anticipated to nearly double by 2030, reaching an impressive 29.42 billion IoT devices. Oniro is well positioned to actively participate in this expansive growth with strong execution of the 3 fundamental principles on which this project is built: seamless interoperability, modularization, and a visually appealing user interface. These principles not only embody the core mission of Oniro, but also position it as the go-to option for a broad range of applications, including consumer electronics, home appliances, industrial IoT devices, smart home devices, and multimedia devices.

Join the Innovation Journey

As OpenHarmony and Oniro join forces, exciting times are ahead. We invite you to be part of this journey, contribute your ideas, and participate in the magic that unfolds when open source organisations collaborate. Stay tuned for more updates as we collectively build a future where innovation knows no bounds!

As the title says, there is good news to share on the progress of the European Union’s proposed Cyber Resilience Act (“CRA”) as the final revisions agreed to in the trilogue negotiations appear to largely exclude the open source community from its scope.

I have written (here and here) and spoken extensively about our concerns with the European Union’s proposed Cyber Resilience Act (“CRA”) in the past. As originally drafted, the CRA would have had an enormous negative impact on both the open source community and the EU’s innovation economy. In short, it would have required most open source projects (and every open source project that matters) made available in Europe to meet unrealistic regulatory requirements related to their secure software development and maintenance. OSS projects would have also been required to affix the CE Mark on their releases certifying that these regulatory requirements had been met, which additionally would have required outside audits performed for critical infrastructure projects such as operating systems. You can read the links above if you want to get a full understanding of the dire implications of the original draft of the CRA.

While the Eclipse Foundation has always shared the goals of the CRA to improve the state of security in the software industry, we have been very vocal in expressing our concerns with how unrealistic requirements could damage the open source community and Europe’s innovation economy. We have been very active in raising community awareness of the issues over the past year. For example, we helped facilitate two open letters co-signed with many of our peer organizations detailing the issues (here and here). 

But we also invested a great deal of time and energy in constructively engaging with policymakers by providing explanations of the functioning of our ecosystems and technologies. The European Commission, the European Parliament, the Council through the Spanish Presidency, as well as numerous policy makers at the national level have all been open to our contributions and recognise our efforts to protect European open innovation. I would like to thank my colleagues Gesine Freund, Enzo Ribagnac, Mikaël Barbero, and Gaël Blondelle for their many contributions to this process. 

We were not alone in these efforts. An assuredly incomplete list of other open source organizations that contributed to raising awareness includes: Apache Software Foundation, Internet Society, Free Software Foundation Europe, Linux Foundation, Mozilla Foundation, NLNet Labs, Open Source Initiative, Python Software Foundation, The Document Foundation, and many others. OpenForum Europe played a pivotal role in facilitating communication between these groups, and Ciarán O’Riordan at the OFE deserves recognition for his yeoman’s effort in coordinating the community’s input throughout the discussions on the CRA. 

On December 1st it was announced that the EU co-legislators had reached political agreement on the CRA. Although the final text is still being worked on, we are happy to report the open source community has been listened to. The revised legislation has vastly improved its exclusion of open source projects, communities, foundations, and their development and package distribution platforms. It also creates a new form of economic actor, the “open source steward,” which acknowledges the role played by foundations and platforms in the open source ecosystem. This is the first time this has appeared in a regulation, and it will be interesting to see how this evolves. The Eclipse Foundation will be investing a great deal of effort into helping refine this concept and its implementation to ensure it aligns with the norms of the open source community. The final revisions also extended the implementation phase to three years, which means full compliance with the CRA will likely start in early 2027. OpenForum Europe’s recent press release on the CRA is certainly worth a read for additional context. 

It is important to recognize and thank the many people that were involved in achieving this significantly better outcome. Both those who were involved from the side of the co-legislators who genuinely listened and made extensive improvements, and the many people from the open source community who invested their time and energy into explaining the unique requirements of the open source community. 

But this journey is only beginning. 

It is important to note that while the CRA has been revised to largely exclude the open source community from its scope, this legislation will still have an enormous impact on the software industry as a whole. 

Open source projects will not be required to directly implement the mandated processes described in the CRA. But every commercial product made available in the EU which is built on top of those open source projects will. For the first time in the software industry’s history, it will soon have regulatory requirements for secure software development and maintenance. I predict this will put pressure on projects and communities to enhance their processes to assist in downstream commercialization. 

After all, if a project is used in hundreds of products, doing the bulk of the CE Mark conformance work in the project rather than repeating the effort hundreds of times makes enormous sense. But as we all know, OSS projects at the moment simply do not have the resources to do this. It is impossible to know how all of this will play out, but an optimistic hypothesis is that once companies are required by law to meet secure software development practices they will be incented to invest in the upstream projects they rely upon. The Eclipse Foundation will be working hard to ensure that we evolve to support the needs of our committers, projects, and members in order to support the implementation of these new regulatory requirements. We will be discussing this early in the new year. 

Interesting times!

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.