Pathway 6: Connecting portals, catalogues, and repositories to the Interoperable Europe Portal (Article 8(4))
This pathway applies when:
- a Union entity or public sector body provides a portal, catalogue, or repository with similar functions to the Interoperable Europe Portal;
- Article 8(4) requires it to ensure interoperability with the Interoperable Europe Portal through necessary and proportionate measures.
Legal basis
-
Interoperability obligation: Where a Union entity or public sector body provides a portal, catalogue or repository with similar functions, it must take the necessary and proportionate measures to ensure interoperability with the Interoperable Europe Portal (Article 8(4)).
-
EUPL support in open source portals: Where such portals collect open source solutions, they must allow for the use of the European Union Public Licence (Article 8(4)).
Implementation guidance
🎯 Step 1. Confirm whether the platform is in scope
To support the assessment of whether a platform is in scope of the Article 8(4), it may focus on the platform’s actual function. A platform is more likely to be in scope if it organises, describes, makes discoverable interoperability solutions.
In practice, the assessment may consider the following aspects:
-
function of the platform: is it primarily a catalogue, a repository, or a combination of both?
-
type of content hosted: does the platform host interoperability solutions?
-
intended audience and reuse purpose: is the platform intended to support reuse by other organisations and/or attract contributors?
-
content coverage: which content would be made accessible through the Interoperable Europe Portal (all entries or a curated subset)?
|
Output of this step: a short scope note by the platform owner confirming whether the platform is considered in scope of Article 8(4) and the reasoning supporting that conclusion. |
🔀 Step 2. Determine the appropriate interoperability approach
Article 8(4) requires the necessary and proportionate measures to ensure interoperability with the Interoperable Europe Portal and it does not prescribe a single integration model. The entity may consider:
- the size, maturity and complexity of the platform;
- the number and frequency of updates to the solutions concerned;
- the expected level of cross-border visibility and reuse;
- the resources and technical capacity available;
- whether federation with the EU OSS Catalogue is envisaged.
In practice, interoperability may take different forms, including:
-
linking and manual curation: each solution has a stable landing page, and a curated list of entries is shared with the Interoperable Europe Portal team. This approach is often sufficient for smaller or specialised catalogues;
-
federation: a structured and largely automated process in which a catalogue exports structured metadata that the EU OSS Catalogue ingests at scale with publiccode.yml.
The entity may also decide whether the Interoperable Europe Portal will expose all entries or a subset of the platform.
|
Output of this step: an interoperability objective note identifying the content scope, the intended level of interoperability, and the reasons why that level is considered necessary and proportionate. |
🛡️ Step 3. Check which entries can be exposed through the Interoperable Europe Portal
The review should cover the metadata and exchange layer. APIs, feeds, landing pages and exported records should not disclose personal data, confidential information, secrets, or other material that should not be made publicly accessible.
If some entries do not meet the Article 8(3) conditions, they cannot be made accessible through the Interoperable Europe Portal nor through the EU OSS Catalogue under this route. The entity may then:
- exclude those entries from the interoperable subset;
- adjust the exposed materials so that the conditions can be met; or
- reconsider the scope of the connection.
|
Output of this step: an Interoperable Europe Portal-conformance check confirming which entries can be made available through the Interoperable Europe Portal and on what basis. |
🗂️ Step 4. Establish baseline content, identifiers and descriptive information
Before implementing a technical connection, the platform owner may check that each exposed entry has:
- a stable landing page or equivalent durable public reference;
- a clear title and concise description;
- an identifiable owner or responsible organisation;
- licence information, where relevant;
- version or release information, where relevant;
- a clear indication of lifecycle or maintenance status, where available;
- links to the relevant repository, documentation, distribution, or other source materials.
The platform owner may also define how updates, deprecations, archiving and withdrawals will be reflected, so as to avoid broken links, unclear version references, or ambiguous solution status.
At this stage, the platform owner may identify the local descriptive fields and map them to those needed for cross-platform discoverability. No single metadata schema is mandated, though structured and machine-readable metadata may become increasingly useful in practice.
|
Output of this step: a baseline interoperability inventory for the entries of the platform to be exposed on the Interoperable Europe Portal. |
🔗 Step 5. Implement the chosen connection model
The platform owner may implement the connection model selected in Step 2 in a way that is maintainable over time. It may document the chosen approach and identify who is responsible for operating and maintaining it.
Different types of assets are best described using different metadata profiles. Selecting an approach that matches the content of the platform helps ensure interoperability while avoiding unnecessary complexity. Commonly used options are presented below.
DCAT-AP
Designed for the exchange of dataset and data service catalogues in Europe and maintained under SEMIC. This profile is particularly suitable where a platform primarily functions as a data catalogue.
ADMS/ADMS-AP
Designed to describe interoperability assets and solutions and used within the Interoperable Europe ecosystem for solution description and federation workflows.
CPSV-AP
Useful where a platform also describes public services in a structured way and where making that service layer machine-readable is relevant.
Publiccode.yml
A repository-level metadata format for public sector software, used by the EU OSS Catalogue as its reference model for discovering and filtering open source solutions.
Reference level interoperability (appropriate for a limited number of entries or with infrequent updates) may include:
-
stable public landing pages for each entry;
-
clear and consistent descriptive information;
-
manual or periodic synchronisation of selected entries;
-
machine-readable exports or feeds containing a defined subset of descriptive fields.
Federation of open source catalogues with the EU OSS Catalogue is based on conditions that include:
-
public git repositories for the solutions concerned;
-
a valid publiccode.yml file in each repository;
-
a publicly accessible API that allows the source catalogue or solution data to be retrieved and synchronised.
The EU OSS Catalogue uses publiccode.yml as its principal metadata specification for this purpose, and should therefore be treated as current practical conditions for that specific integration route, not as general legal requirements of Article 8(4) for all portals, catalogues or repositories.
|
Output of this step: a working connection mechanism, supported by a short technical note explaining the chosen interoperability model, the exposed content scope, and the maintenance approach. |
In focus
The EU OSS Catalogue exemplifies effective integration between repositories. It provides a curated selection of open source solutions, consolidating information on software packages and their use by European public administrations. Its value lies in aggregating data from multiple sources and presenting it in a standardised format. The catalogue is built on a federated architecture of public APIs, creating a central pool of open source solutions sourced from national, regional, and local open source software catalogues across EU Member States. As part of the Interoperable Europe Portal, the provisions of Article 8(3) apply.
📜 Step 6. Where open source solutions are collected, ensure that the use of the EUPL is not excluded
Where the platform collects open source solutions, it should not block, refuse, misrepresent, or otherwise prevent the use of the EUPL in practice. In practice, the entity may verify, where relevant, that:
-
the EUPL can be selected, declared or recorded wherever licence information is captured;
-
licence fields, metadata models, validation rules and onboarding workflows do not reject or distort EUPL-licensed entries;
-
landing pages and machine-readable outputs can display or transmit EUPL information clearly and consistently;
-
free-text or non-standard licence handling does not create ambiguity that effectively disadvantages EUPL-licensed solutions.
Where the platform does not itself assign licences but merely exposes externally maintained entries, the entity may still ensure that its platform logic and metadata handling can accommodate the EUPL without obstruction.
|
Output of this step: a record confirming that EUPL-licensed entries are not excluded by the platform. |
🧪 Step 7. Test end-to-end, assign responsibilities, and maintain interoperability over time
Before go-live, the platform owner may test a small and manageable subset of entries to confirm that:
- entries can be discovered through the Interoperable Europe Portal;
- links resolve reliably to the intended landing pages;
- licence, version and ownership information remains visible and consistent;
- machine-readable exports, feeds or APIs are accessible and behave as expected;
- duplicate, withdrawn or deprecated entries are handled in a predictable way.
The entity may also assign responsibilities for:
- technical maintenance of the connection;
- metadata quality and update handling;
- issue resolution and contact with the Interoperable Europe Portal team;
- lifecycle management for deprecated or withdrawn entries;
- review of schema, mapping or API changes that may affect interoperability.
The main objective is to ensure roles and updates are clear enough to prevent interoperability from gradually deteriorating. When entries remain accessible through the Interoperable Europe Portal, owners must regularly maintain the solution in accordance with Article 8(3).
|
Output of this step: a short test report and an operational governance note describing who maintains the connection, how updates are handled, and how interoperability issues are identified and resolved over time. |
For further details on this pathway, including legal context, implementation considerations and examples, see the corresponding Section (3.6) in the extended version of the Guidelines.
For further guidance and clarification, please refer to the FAQ section available on the Portal.