Pathway 1: Prioritising solutions without restrictive licensing terms (Article 4(6))
This pathway applies when a public organisation:
- is deciding whether to implement an interoperability solution;
- is comparing candidate interoperability solutions and one or more options may be available without restrictive licensing terms;
- is determining the licensing approach for an interoperability solution that it intends to make available for reuse, where that choice forms part of a decision on the implementation of the solution.
In the context of the Act, solutions without restrictive licensing terms will in practice most often be open source solutions. Their licences generally permit use, reuse, modification and redistribution, subject, where applicable, to conditions such as attribution or copyleft. This provides the legal clarity and predictability needed for reuse, adaptation, integration and redistribution across different administrative, legal and technical contexts. For this reason, Article 4(6) requires Union entities and public sector bodies to prioritise such solutions where they are equivalent against objective criteria laid down in the Act.
Solutions without restrictive licensing terms are not limited to software and may also include documentation, semantic assets, reference architectures or other reusable artefacts. Conversely, an interoperability solution may still fall within the scope of the Act even if it carries restrictive licensing terms, as the definition is functional and not dependent on licensing. Where restrictive terms or service dependence cannot be avoided, the assessment should consider exit, dependency management and, where relevant, data portability.
Interoperability solutions can be shared through different delivery models, including on-premise and as-a-service. Reuse and integration are typically governed by the applicable licence terms and/or service contracts.
Legal basis
-
Prioritisation rule: When deciding on the implementation of interoperability solutions, Union entities and public sector bodies must prioritise solutions that do not carry restrictive licensing terms, such as open source solutions, where solutions are equivalent in terms of functionalities, total cost, user-centricity, cybersecurity, or other relevant objective criteria (Article 4(6)).
-
Commission support: The Commission shall provide support in identifying such interoperability solutions, as provided for in Article 9 (Article 4(6)).
Implementation guidance
🧭 Step 1. Identify the relevant implementation decision under Article 4(6)
The public organisation may first clarify which implementation accompanied by requirements decision falls within Article 4(6). This may concern not only the selection, development, replacement or adaptation of an interoperability solution, but also architectural, governance or design choices within an existing or mandated system, such as choosing a data model, interface standard, semantic asset or reference architecture performing an interoperability function, or determining the licensing terms under which the solution will be made available.
This clarification should be integrated into ordinary IT governance, procurement and software development processes. It should include the relevant functional, technical and organisational requirements, key constraints, and consideration from the outset of whether an equivalent solution exists under a non-restrictive licence or whether a new solution could be developed and made available as open source.
|
Output of this step: a clearly formulated implementation decision, accompanied by a requirements list against which candidate interoperability solutions can be assessed. |
In focus
The OSOR Handbook is a practical guidance document developed to support public administrations in working with open source software.
The handbook provides concise, experience‑based guidance for administrations seeking to adopt or strengthen open source practices based on extensive experience and community consultation. It addresses the full lifecycle of open source use in the public sector, including identifying and evaluating solutions, development and procurement, participation in open source communities, funding, licensing, and organisational structures.
🔍 Step 2. Identify candidate solutions, starting with reusable solutions already available, and establish a shortlist for further assessment
Candidate solutions may include:
- internal interoperability solutions already in use or under development;
- interoperability solutions made available by other public sector bodies, including through the Portal or connected portals, catalogues or repositories;
- other publicly available solutions.
The Commission supports this identification process through the Portal and related discovery tools, including the EU OSS Catalogue. Further support may also be provided through the measures and services referred to in Article 9. This support is intended to facilitate discovery and comparison, without prescribing a specific source or tool.
Where a potentially suitable solution is known to exist but is not publicly accessible, the public organisation may consider seeking it through direct sharing arrangements described in Pathway 3; where a solution is or will be made publicly accessible for reuse, the publication guidance described in Pathway 2 of these Guidelines may be relevant.
At this stage, the entity may also exclude options that are manifestly unsuitable and establish a shortlist.
|
Output of this step: a shortlist of candidate solutions, including any reusable solutions already identified. |
In focus
The EU OSS Catalogue federates national and local catalogues that meet specific technical and governance criteria. Open source solutions can be displayed and filtered through the advanced search available.
In focus
Support or endorsement by a recognised entity, such as an Open Source Programme Office (OSPO) or a national or EU institutional body, can enhance the credibility of an open source solution and facilitate cross-border sharing and adoption. Code managed within such frameworks is typically developed under high standards of quality, transparency, usability, privacy and societal value.
For instance, the European Commission OSPO supports the adoption and governance of open source solutions within the European Commission. Public sector bodies are encouraged to engage with established OSPOs.
⚖️ Step 3. Assess equivalence and operational feasibility against objective criteria
Equivalence does not require that solutions be identical. It requires a level of functional and operational comparability that is sufficient to meet the stated needs of the public organisation.
Before taking a final decision, the entity should assess both operational feasibility and equivalence of shortlisted candidate solutions using objective, transparent, and proportionate criteria, such as functionality, total cost user‑centricity, cybersecurity and other relevant objective criteria. Under the latter, public organisations may assess standards compliance, portability, interoperability maturity, architectural fit, long-term operational autonomy, or vendor lock-in risks.
When one or more shortlisted solutions are available, the organisation may confirm that it can implement, operate, maintain, and secure that solution in a sustainable manner before making the final selection. For non-software solutions, equivalent questions of stewardship, update handling, documentation, access and governance should be considered proportionately.
Operational feasibility may, where appropriate, also be supported through contractual arrangements with external providers responsible for installation, operation or maintenance of the solution. Architectural choices may, where feasible, support reuse and adaptation, for example through modular components that can be shared or reused independently.
|
Output of this step: a documented equivalence assessment and operational adoption plan, saved as part of the decision record. |
In focus
When public organisations assess standards or technical specifications as part of this equivalence assessment, structured methodologies such as Common Assessment Method for Standards and Specifications (CAMSS) may be used to support transparent and comparable evaluation that supports interoperability and helps preventing vendor lock-in. Where a complete CAMSS assessment is already available, it can be reused as documented justification when preparing a solution for sharing. If no prior assessment exists, public organisations may conduct their own evaluation using the EIF Scenario or request assistance from the CAMSS team.
Selecting standards already assessed through CAMSS not only supports compliance but also facilitates maintenance, adaptation and evolution of solutions over time. Including the CAMSS assessment in the sharing package provides concrete evidence that the solution is based on objectively evaluated standards, offering assurance to reusing public organisations. For long-term sustainability, CAMSS assessments should be revised whenever standards or APIs are updated.
✅ Step 4. Apply the prioritisation rule, take the selection decision, and record the rationale
If the solutions are equivalent, prioritise the use of interoperability solutions that do not carry restrictive licensing terms. Once the prioritisation rule is applied, the public organisation may record:
- a brief explanation of why the solutions were assessed as equivalent or not equivalent;
- how licensing restrictiveness was assessed;
where relevant, the reasons why the selected solution was considered operationally suitable.
|
Output of this step: a decision record documenting the application (or non‑application) of the prioritisation rule under Article 4(6). |
📜 Step 5. Choose a licence and manage compatibility
Where a public organisation develops or adapts an interoperability solution for reuse, it may consider whether it can be made available without restrictive licensing terms. If broad reuse across public organisation is intended, this may include, in particular:
- identify third-party rights, dependencies, or contractual arrangements;
- select an appropriate licence;
- document any licence compatibility considerations and obligations;
- clarify, where relevant, how external contributions are handled.
The European Union Public Licence (EUPL), developed by the European Commission as the first EU-created open source licence, is widely used within the EU public sector and is designed to support sharing and reuse across public organisations operating under different national legal frameworks.
Where a Union entity or public sector body operates a portal, catalogue or repository with similar functions to the Interoperable Europe Portal and that platform collects open source solutions, it must allow for the use of the EUPL. This requirement concerns the operation of the platform and does not establish the EUPL as a default or mandatory licence for all open source software.
|
Output of this step: a documented licensing approach, including the licence or licensing terms selected and any key compatibility considerations. |
In focus
To support the licence assessment, the Licensing Assistant, including its licence compatibility checker, is available on the Interoperable Europe Portal.
For further details on this pathway, including legal context, implementation considerations and examples, see the corresponding Section (3.1) in the extended version of the Guidelines.
For further guidance and clarification, please refer to the FAQ section available on the Portal.