Free and Open in the Latest Draft of the EU Cyber Resilience Act
New provisions related to free and open software in the December 20 draft of the CRA:
Recitals
Recital 10
This Regulation applies to economic operators only in relation to products with digital elements made available on the market, hence supplied for distribution or use on the Union market in the course of a commercial activity. The supply in the course of a commercial activity might be characterized not only by charging a price for a product, but also by charging a price for technical support services when this does not serve only the recuperation of actual costs, or by an intention to monetise, for instance by providing a software platform through which the manufacturer monetises other services, by requiring as a condition for use the processing of personal data for reasons other than exclusively for improving the security, compatibility or interoperability of the software, or by accepting donations exceeding the costs associated with the design, development and provision of a product with digital elements. Accepting donations without the intention of making a profit should not be considered to be a commercial activity.
Interesting to see language specifically including donations over costs as a form of monetization.
Recital 10b
Software and data that are openly shared and where users can freely access, use, modify and redistribute them or modified versions thereof, can contribute to research and innovation in the market. To foster the development and deployment of free and open- source software, in particular by microenterprises and small, medium-sized enterprises, including start-ups, and not-for-profit organisations, academic research and individuals, the application of this Regulation to free and open-source software products supplied for distribution or use in the course of a commercial activity should take into account the nature of the different development models of software distributed and developed under free and open-source software licences.
Recital 10c
Free and open-source software is understood as software the source code of which is openly shared and the license of which provides for all rights to make it freely accessible, usable, modifiable and redistributable.
This shows up in a definition, also quoted below.
Free and open-source software is developed, maintained, and distributed openly, including via online platforms.
Not all software distributed “openly” gets developed and maintained “openly”. But I don’t see open development and maintenance in the actual definition within the text.
In relation to the economic operators covered by this regulation, only free and open-source software made available on the market, and therefore supplied for distribution or use in the course of a commercial activity should be covered by this Regulation.
The mere circumstances under which the product has been developed, or how the development has been financed should therefore not be taken into account when determining the commercial or non- commercial nature of that activity.
Keeping focus on when software can cause harm. Not elevating free- or open- process distinctions above that focus.
More specifically, for the purpose of this Regulation and in relation to the economic operators referred therein, to ensure that there is a clear distinction between the development and the supply phases, the provision of free and open-source software products with digital elements that are not monetised by their manufacturers is not considered a commercial activity.
Here is the line. I wonder how “clear” this will actually be in practice.
Furthermore, the supply of products with digital elements qualifying as free and open-source software components intended for integration by other manufacturers into their own products with digital elements should only be considered as making available on the market if the component is monetised by its original manufacturer.
For instance, the mere fact that an open-source software product with digital elements receives financial support by manufacturers or that manufacturers contribute to the development of such a product should not in itself determine that the activity is of commercial nature.
In addition, the mere presence of regular releases in itself does not lead to the conclusion that a product is supplied in the course of a commercial activity.
Finally, for the purpose of this Regulation, the development of products with digital elements qualifying as free and open-source software by not-for-profit organisations should not be considered a commercial activity as long as the organisation is set up in a way that ensures that all earnings after cost are used to achieve not-for-profit objectives.
I’m noting “not-for-profit”, rather than “charitable”, here.
This Regulation does not apply to natural or legal persons who contribute source code to free and open-source products that are not under their responsibility.
Safe harbor for individual contributors. “Under their responsibility” is an interesting turn of phrase here.
Recital 10d
Taking into account the cybersecurity importance of many free and open-source software products with digital elements that are published but, within the meaning of this Regulation, not made available on the market, legal persons which provide support on a sustained basis for the development of such products with digital elements qualifying as free and open-source software, which are intended for commercial activities, and play a main role in ensuring the viability of those products ('open-source software stewards') should be subject to a light-touch and tailor-made regulatory regime.
Why? How does this advance the purpose the law?
This includes certain foundations as well as entities that develop and publish free and open-source software in a business context, such as not-for-profit entities developing free and open-source software in a business context. This regulatory regime should take account of their specific nature and compatibility with the type of obligations imposed. It should only cover free and open-source software products with digital elements that are ultimately intended for commercial activities, such as for integration into commercial services or into monetised products with digital elements.
Why not others?
For the purpose of the light-touch and tailor-made regulatory regime, an intention for integration into monetised products includes cases where manufacturers that integrate a component into their own products with digital elements either contribute to the development of that component in a regular manner or provide regular financial assistance to ensure the continuity of the software product.
The provision of sustained support to the development of a product with digital elements includes but is not limited to the hosting and managing of software development collaboration platforms, the hosting of source code or software, the governing or managing of free and open-source software products with digital elements as well as the steering of the development of such products. Given that the light-touch and tailor-made regulatory regime does not subject open-source software stewards to the same obligations as manufacturers under this Regulation, they should not be able to affix the CE marking to the products with digital elements whose development they support.
Recital 10e
The sole act of hosting products with digital elements on open repositories, including through package managers or on collaboration platforms, does not in itself constitute making available on the market of a product with digital elements.
Safe harbor for forges and repositories.
Providers of such services should only be considered distributors if they make such software available on the market and hence supply it for distribution or use on the Union market in the course of a commercial activity.
Recital 10f
In order to support and facilitate the due diligence of manufacturers that integrate free and open-source software components that are not subject to the essential requirements laid down in this Regulation into their products with digital elements, the Commission should be able to establish voluntary security attestation programmes, either by a delegated act supplementing this Regulation or by requesting a European cybersecurity certification scheme pursuant to Article 48 of Regulation (EU) 2019/881 that takes into account the specifics of the free and open-source software development models. The security attestation programmes should be conceived in such a way that not only legal or natural persons developing or contributing to the development of a product with digital elements qualifying as free and open-source software can initiate or finance an attestation but also third-parties, such as manufacturers that integrate such products into their own products, users, or European and national public administrations.
Recital 10g
In view of the public cybersecurity objectives of this Regulation and in order to improve the situational awareness of Member States as regards the Union’s dependency on software components and in particular on potentially free and open-source software components, the administrative cooperation group (ADCO) established by this Regulation should be able to decide to jointly undertake a Union dependency assessment. Market surveillance authorities should be able to request manufacturers of categories of products with digital elements established by the ADCO to submit the software bills of materials (SBOMs) that they have generated pursuant to this Regulation. In order to protect the confidentiality of SBOMs, market surveillance authorities should submit relevant information about dependencies to the ADCO in an anonymised and aggregated manner.
Recital 45
… Manufacturers of important products with digital elements qualifying as free and open-source software should be able to follow the internal control procedure based on Module A provided that they make the technical documentation available to the public.
Recital 62
… Furthermore, power to adopt delegated acts should also be conferred to the Commission to establish voluntary security attestation programmes for assessing the conformity of products with digital elements qualifying as free and open-source software with all or certain essential requirements or other obligations laid down in this Regulation, as well as to specify the minimum content of the EU declaration of conformity and to supplement the elements to be included in the technical documentation. …
Text
Chapter I. General Provisions
Article 3
Paragraph 18a
‘open-source software steward’ means any legal person, other than a manufacturer, which has the purpose or objective to systematically provide support on a sustained basis for the development of specific products with digital elements qualifying as free and open-source software that are intended for commercial activities, and ensures the viability of those products;
Can the older US-based foundations that qualified for tax exemption as charities under 501(c)(3) before IRS clamped down qualify for this exemption? Will declaring that they maintain software “intended for commercial activities” for EU purposes suggest they should be 501(c)(6)s?
Paragraph 40a
‘free and open-source software’ means software the source code of which is openly shared and which is made available under a free and open-source license which provides for all rights to make it freely accessible, usable, modifiable and redistributable
A definition of “FOSS”. Note the absence of any deferral to private organizations like OSI, FSF, or Debian, to say what’s in or out. Nobody familiar with how legislatures writes laws expects such a thing.
Chapter II
Article 10
Paragraph 4
For the purposes of complying with the obligation laid down in paragraph 1, manufacturers shall exercise due diligence when integrating components sourced from third parties in a manner that such components do not compromise the cybersecurity of the product with digital elements, including when integrating components of free and open-source software that have not been made available on the market in the course of a commercial activity.
Paragraph 4a
Manufacturers shall, upon identifying a vulnerability in a component, including in an open source-component, which is integrated in the product with digital elements, report the vulnerability to the person or entity manufacturing or maintaining the component, and address and remediate the vulnerability in accordance with the vulnerability handling requirements set out in Annex I, Section 2.
Where manufacturers have developed a software or hardware modification to address the vulnerability in that component, they shall share the relevant code or documentation with the person or entity manufacturing or maintaining the component, where appropriate in a machine-readable format.
Paragraph 16
In order to assess the dependency of Member States as well as the Union as a whole on software components and in particular on components qualifying as free and open- source software, the ADCO may decide to conduct a Union wide dependency assessment for specific categories of products with digital elements. For that purpose, market surveillance authorities may request manufacturers of such categories of products with digital elements to provide the relevant software bills of materials as referred to in point 1 of section 2 of Annex I. Based on such information, the market surveillance authorities may provide the ADCO with anonymised and aggregated information about software dependencies. The ADCO shall submit a report on the results of the dependency assessment to the Cooperation Group established under Article 14 of Directive (EU) 2022/2555.
Article 17a. Obligations of open-source software stewards
Open-source software stewards shall put in place and document in a verifiable manner a cybersecurity policy to foster the development of a secure product with digital elements as well as an effective handling of vulnerabilities by the developers of that product. It shall also foster the voluntary reporting of vulnerabilities as laid down in Article 11a by the developers of that product. The cybersecurity policy shall take into account the specific nature of the open-source software steward and the legal and organisational arrangements it is subject to. It shall in particular include aspects related to documenting, addressing and remediating vulnerabilities as well as promote the sharing of information concerning discovered vulnerabilities within the open-source community
Open-source software stewards shall cooperate with the market surveillance authorities, at their request, with a view to mitigating the cybersecurity risks posed by a product with digital elements qualifying as free and open-source software. Further to a reasoned request from a market surveillance authority, open-source software stewards shall provide that authority, in a language which can be easily understood by it, with the documentation referred to in the first paragraph, in paper or electronic form
The obligations laid down in Article 11, paragraph 1, shall apply to open-source software stewards to the extent that they are involved in the development of the products with digital elements. The obligations laid down in Article 11, paragraphs 3 and 8 shall apply to open-source software stewards to the extent that severe incidents having an impact on the security of products with digital elements affect network and information systems provided by the open-source software stewards for the development of such products.
Article 17b. Security attestation of free and open-source software
In order to facilitate the due diligence obligation set out in Article 10(4) of this Regulation, in particular as regards manufacturers that integrate free and open-source software components in their products with digital elements, the Commission is empowered to adopt delegated acts in accordance with Article 50 to supplement this Regulation by establishing voluntary security attestation programmes allowing the developers or users of products with digital elements qualifying as free and open-source software as well as other third-parties to assess the conformity of such products with all or certain essential requirements or other obligations laid down in this Regulation.
Article 17c. Guidance
In order to facilitate the implementation of this Regulation and ensure consistency, the Commission shall publish guidance to assist the economic operators in applying this Regulation, with a particular focus on how to facilitate compliance by microenterprises, small enterprises and medium-sized enterprises.
The Commission, where it intends to provide guidelines, shall address at least the following aspects:
(a) the scope of this Regulation, with a particular focus on remote data processing solutions and free and open-source software;
Commission guidance can further clarify how this law does and doesn’t apply to FOSS.
...
Article 24
3b. Manufacturers of products with digital elements qualifying as free and open-source software, which fall under the categories listed in Annex III to this Regulation, shall be able to demonstrate conformity with the essential requirements set out in Annex I by using one of the procedures referred to in paragraph 1, provided that the technical documentation referred to in Article 23 is made available to the public at the time of the placing on the market of those products.
Your thoughts and feedback are always welcome by e-mail.