Summary Under Article 41 of the proposed Cloud and AI Development Act (CADA), the phrase "facilitate the reuse" imposes a proactive, structural obligation on the Union and Member States. It requires them to actively remove legal, technical, and organizational barriers that prevent public sector bodies from using and reusing open standards and open-source components in their cloud and AI ecosystems. This is not a passive permission to share code; it is a mandate to build the infrastructureβ€”such as the EU Open Source Solutions Catalogue and the Open Source Programme Office (OSPO) networkβ€”that makes reuse the path of least resistance. While the provision mandates "encouragement" of use, "facilitation" of reuse demands concrete measures to ensure open-source solutions are viable, findable, and interoperable alternatives to proprietary software, subject to objective criteria like security and total cost.

Detail

Article 41 of the Cloud and AI Development Act (CADA) establishes a foundational policy for the public sector's digital sovereignty. The full text of the article states:

"The Union and Member States shall take the necessary measures to encourage Union entities and public sector bodies to use and facilitate the reuse of open standards and components released under an open source licence when building their cloud and AI ecosystem or stack, taking into account functionalities, including security, total cost, and other relevant, duly justified objective criteria."

To understand the legal weight of this provision, one must distinguish between the two distinct verbs employed by the legislator: "encourage" and "facilitate."

The Distinction: "Encourage" vs. "Facilitate"

The article imposes a dual-layered duty on the Union and Member States.

1. "Encourage use" (The Strategic Layer) The obligation to encourage use implies a promotional and incentivizing role. This involves shifting the default mindset of public procurement and development away from proprietary reliance. It suggests that Member States should adopt policies, guidelines, or procurement criteria that favor open-source solutions where they meet technical requirements. It signals a strategic intent to diversify the software supply chain.

2. "Facilitate the reuse" (The Operational Layer) The obligation to facilitate reuse is the more operationally demanding component. In legal and administrative contexts, "facilitate" means to make an action easier or less burdensome. It implies active enablement. A Member State does not merely "allow" a public body to reuse open-source code; it must actively dismantle the friction that typically prevents such reuse.

This friction often manifests as:

  • Legal Uncertainty: Ambiguous licensing terms, unclear liability frameworks, or fear of non-compliance.
  • Technical Barriers: Lack of integration tools, poor documentation, or incompatible formats that make code unusable by other agencies.
  • Organizational Silos: The absence of standardized processes for sharing code between different ministries, regions, or public entities.

Therefore, "facilitate" requires the creation of an environment where reuse is the path of least resistance. It transforms the public sector from a collection of isolated software consumers into a collaborative ecosystem. This is not a passive permission but an active structural requirement to build the necessary infrastructure.

The Role of Objective Criteria

Article 41 explicitly qualifies these obligations by stating that the Union and Member States must take measures "taking into account functionalities, including security, total cost, and other relevant, duly justified objective criteria."

This clause prevents the mandate from being interpreted as a blind ideological push for open source at the expense of public service delivery. Public bodies retain the discretion to choose proprietary solutions if they demonstrably offer superior security, functionality, or cost-efficiency. However, the requirement to facilitate reuse ensures that open-source options are evaluated on an equal footing. It prohibits the automatic exclusion of open-source solutions due to legacy vendor lock-in, lack of internal expertise, or procedural inertia. The "facilitation" duty ensures that the process of evaluation is open and that the infrastructure to support open-source adoption exists.

The Infrastructure of Facilitation: Catalogues and OSPOs

Article 41 does not exist in a vacuum; it serves as the policy engine for the specific mechanisms established in Articles 42, 43, and 44 of CADA. The "facilitation" of reuse is achieved through concrete, mandated infrastructure:

  1. The EU Open Source Solutions Catalogue (Article 43): To facilitate reuse, software must be findable. Article 43 mandates the Commission to establish and maintain a centralized EU Open Source Solutions Catalogue. Without a central repository, "reuse" is theoretically possible but practically impossible due to discoverability issues. Article 41's obligation to facilitate reuse is the legal driver that necessitates this catalogue. It ensures that public bodies can search for existing solutions before commissioning new ones.

  2. Mandatory Sharing and Reuse (Article 42): Article 42 operationalizes the "facilitation" mandate by requiring that when Union entities and public sector bodies make software available for reuse, they must do so via a catalogue connected to the EU OSS Catalogue. This ensures the infrastructure is populated with reusable assets. It transforms the abstract concept of "facilitation" into a concrete requirement for data flow and standardization.

  3. The OSPO Network (Article 44): Article 44 establishes a network of Open Source Programme Offices (OSPOs). These offices are the organizational embodiment of the "facilitate" mandate. Their tasks include facilitating the exchange of information, best practices, and guidance on licensing, security, and procurement challenges. The OSPO network provides the human expertise and coordination necessary to overcome the legal and technical barriers that Article 41 seeks to remove.

Strategic Context: Sovereignty and Transparency

The explanatory memorandum reinforces this interpretation. Recital 81 states that open source plays an important role in ensuring transparency, security, and efficiency. It notes that "access to the source code enables auditability, fosters collaboration and reuse and reduces dependency on a single vendor."

Therefore, the obligation in Article 41 is not merely about software licensing; it is a strategic measure to enhance technological sovereignty. By "facilitating reuse," the EU aims to build a collaborative, sovereign digital infrastructure that reduces vendor lock-in and ensures that public investments in software generate public value through shared assets.

What this means for you

For in-house counsel, compliance officers, and IT strategists in the public sector or entities interacting with it, Article 41 signals a fundamental shift in procurement and software development strategy.

1. Policy Alignment and "Necessary Measures" Member States are required to take "necessary measures." This will likely translate into national implementation guidelines, decrees, or updated procurement frameworks. Compliance officers must monitor for these transpositions to understand what "necessary measures" look like in their specific jurisdiction. This may include mandatory open-source assessments before a public body can procure proprietary software, ensuring that open alternatives were genuinely considered and facilitated.

2. Procurement Criteria and Evaluation When building cloud and AI ecosystems, public bodies must ensure that procurement documents include objective criteria (security, total cost of ownership, functionality) that allow open-source solutions to compete fairly. Excluding open-source solutions without a "duly justified objective criterion" may violate the spirit of Article 41. The "facilitation" duty implies that the procurement process itself must be designed to lower the barrier to entry for open-source vendors.

3. Engagement with the Ecosystem Article 41's facilitation mandate relies on the infrastructure in Articles 43 and 44. Public bodies should:

  • Register Reusable Software: Ensure that any software developed by the entity is made available for reuse via the EU Open Source Solutions Catalogue (as required by Article 42).
  • Engage with OSPOs: Actively participate in the national Open Source Programme Office (OSPO) network. These offices will provide the guidance on licensing, security audits, and best practices needed to overcome the barriers to reuse.
  • Search Before Building: Actively search the catalogue for existing solutions before commissioning new software development, aligning with the "reuse" objective.

4. Risk Management and Due Diligence "Facilitating reuse" does not mean ignoring risks. The reference to "security" and "total cost" in Article 41 means that compliance officers must maintain robust due diligence processes for open-source components. This includes license compatibility checks, security vulnerability assessments, and supply chain transparency. The OSPO network will likely provide templates and guidance for these assessments to ensure that "facilitation" does not compromise security.

Common misconceptions

Misconception 1: "Article 41 mandates that all public software must be open source." No. Article 41 requires entities to encourage use and facilitate reuse, taking into account objective criteria. Proprietary software remains a valid option if it better meets security, functionality, or cost criteria. The obligation is to ensure open source is a viable, accessible option, not the exclusive one.

Misconception 2: "Facilitate reuse just means we aren't legally prohibited from sharing code." No. "Facilitate" implies active removal of barriers. If a public body has code that could be reused but lacks the documentation, licensing clarity, or platform access to make it usable by others, it is not facilitating reuse. It requires proactive steps to make software findable and usable, hence the linked requirements for catalogues (Article 43) and OSPOs (Article 44).

Misconception 3: "This only applies to new software development." No. The article applies to building the "cloud and AI ecosystem or stack." This includes existing infrastructure upgrades and new deployments. Furthermore, the "reuse" component applies to software already developed by public bodies, encouraging the sharing of legacy or existing code bases where appropriate.

Related

This is general information about a draft EU regulation, not legal advice.