Pathway 3: Direct sharing of interoperability solutions upon request (Article 4(1))
This pathway applies when:
- a Union entity or public sector body receives a request from another Union entity or public sector body;
- the sharing entity decides to fulfil the obligation through direct sharing, not by publication under Article 4(3).
Legal basis
-
Obligation to make available upon request: A Union entity or public sector body must make available to any other Union entity or public sector body that requests it an interoperability solution supporting a trans-European digital public service, including technical documentation and, where applicable, version history, documented source code, and references to open standards or technical specifications used (Article 4(1)).
-
Exceptions: The Article 4(1) obligation does not apply if the solution:
-
falls outside the scope of the sharing entity’s public task (subject to transparency and reviewability);
-
is constrained by third-party intellectual property rights restricting sharing for reuse;
-
is excluded or restricted on specified security grounds (Article 4(1)(a) to (c)).
-
-
Reuse conditions and support stance: To enable autonomous management by the reusing entity, the sharing entity must specify any conditions applying to reuse, including any guarantees regarding cooperation, support and maintenance. Those conditions may include exclusion of the sharing entity’s liability in case of misuse by the reusing entity (Article 4(2)).
-
Cybersecurity and evolution autonomy assessment: Before adoption, the reusing entity must, upon request, provide an assessment covering its ability to manage autonomously the cybersecurity and the evolution of the reused interoperability solution (Article 4(2)).
Requesting entity
The requesting entity may indicate:
- who is requesting the solution;
- what solution is requested;
- why the solution is needed;
- which artefacts are needed;
- any constraints relevant to handling the reuses;
- any information‑handling requirements.
Sharing entity
Upon receipt of a request, the sharing entity may:
- acknowledge receipt and indicate next steps;
- verify that the requester is within the scope of Article 4;
- seek clarification, if needed;
- log the request in an appropriate register or ticketing system.
If the requester does not fall within the scope of Article 4(1), the obligation does not apply, though voluntary cooperation may be possible, where lawful.
|
Output of this step: a registered request with a unique reference identifier. |
📐 Step 2. Confirm the scope and the solution boundary
The sharing entity may confirm what has been requested, what form of reuse is envisaged, and whether the request can realistically proceed.
At practical level, this may clarify:
- what asset and which version or release are requested;
- whether the request concerns the whole solution or specific components;
- whether the requester seeks artefacts for independent deployment;
- which high-level artefacts are in scope;
- whether effective reuse depends on external services;
- the intended operational or organisational context of reuse.
Where useful, the sharing entity may indicate any baseline conditions or constraints (e.g. support, onboarding, licensing basis, likely mode of reuse).
If, following this this clarification, the requesting entity no longer wishes to proceed, the request may be closed. If it remains open, the sharing entity should then carry out the formal exception screening under Step 3. Final reuse conditions, support stance and any liability wording are set out under Step 5.
|
Output of this step: a short scope note, summarising what will be shared, at which version, and for which intended use. |
🛡️ Step 3. Carry out exception screening and confirm whether sharing can proceed
Once the request scope is sufficiently clear, the sharing entity should determine whether any of the exceptions in Article 4(1) prevent sharing in whole or in part. The screening may be carried out by addressing the following questions and recording the outcome:
Is the requested interoperability solution linked to activities that fall outside the scope of the sharing entity’s public task?
If so, the sharing entity may identify the legal basis and indicate how this determination is transparent and subject to review. This issue may be especially relevant where the requested reuse would, in practice, require the sharing entity to operate or extend a live service for users outside its existing mandate, territorial scope or administrative context.
Does the sharing entity hold the rights necessary to share the solution and allow its reuse?
If not, the sharing entity may indicate whether the restriction affects the solution as a whole or only certain components.
Would sharing the solution, or parts of it, disclose information to which access is restricted on grounds of critical infrastructure protection, defence interests, or public security?
If so, the sharing entity may identify whether, and to what extent, the sensitivity prevents or restricts sharing of the solution.
If an exception applies and the request cannot be fulfilled in full or in part, the sharing entity may communicate a reasoned explanation to the requesting entity and record the decision for traceability.
Partial sharing may be considered if clearly separable and reusable components exist and can be shared (e.g. building blocks, libraries, vocabularies). In such case, the sharing entity may confirm with the requesting entity whether it still wishes to proceed on that basis before preparing the shareable package.
|
Output of this step: an exception screening record, indicating the share/cannot share outcome, together with the applicable exception category and a brief justification. |
📦 Step 4. Assemble the shareable package
Once the request has been accepted and scoped, the sharing entity should prepare a practical and proportionate package.
Beyond the legal minimum, the sharing entity may consider adding additional orienting materials where these already exist such as:
- a short README
- brief installation or integration notes;
- a list of dependencies and relevant runtime assumptions;
- a basic architecture overview.
The Act does not require upgrading, adapting, or improving the solution as part of sharing.
References to standards and specifications
Where the solution relies on standards or specifications, the sharing entity should provide references to those used. Examples include, where relevant:
- technical specifications;
- data and semantic standards;
- API and interoperability standards;
- security standards and specifications;
- document and exchange formats;
- European interoperability specifications.
Typical elements of technical documentation
Where available and relevant, the technical documentation and accompanying information may include:
- architecture and design information;
- source code or documented software components;
- testing and validation documentation;
- operational documentation (including deployment instructions, configuration, maintenance, and update procedures);
- reuse and integration guides;
- where relevant, a Software Bill of Materials.
These elements are illustrative only. The materials shared should remain proportionate to the complexity of the solution and its intended reuse.
For non-software assets, the shareable package may consist primarily of legal documentation, organisational rules, semantic artefacts, data models, interfaces, specifications, governance materials or service-operating documentation, rather than deployable code.
- if the solution is already accessible (for example via an existing repository), it may be shared by providing a link;
- documentation may be shared in the language in which it is maintained; where feasible, summaries in English can facilitate cross‑border reuse;
- artefacts could be provided in machine‑readable and accessible formats, to the extent reasonable.
|
Output of this step: a shareable package identified by a clear version or release tag and ready for delivery to the requesting entity. |
📜 Step 5. Set reuse conditions and support stance
A reuse conditions statement may cover:
- legal or licensing conditions;
- the mode of reuse;
- the responsibilities of the sharing entity and the reusing entity;
- the support stance, if any;
- the maintenance stance;
- any specific constraints or cautions relevant to reuse;
- any applicable disclaimer or limitation of liability.
Where the interoperability solution or its documentation is subject to licensing terms, the sharing entity should provide the relevant licensing information for the materials being made available.
Where additional onboarding, deployment, training, maintenance, support, hosting or managed-operation services are envisaged in connection with reuse, the conditions applicable to those services may be stated clearly and transparently. Such services, however, are separate from the core sharing obligation.
Where public organisations wish to organise joint evolution of a solution, they may explore separate arrangements, such as those described in the cost‑sharing pathway.
|
Output of this step: a reuse conditions statement, shared together with the interoperability solution and stored as part of the request record. |
For further details on implementation considerations, including maintenance and support, see Annex 3 of the extended version of the Guidelines.
🔍 Step 6. Decide whether to request an autonomy assessment
Requesting an autonomy assessment is optional. It may be proportionate where:
- the interoperability solution is security‑sensitive;
- the interoperability solution is complex to operate, maintain or patch;
- the reusing entity intends to adapt or fork the solution.
Where an autonomy assessment is requested, it may briefly describe the reusing entity’s arrangements concerning:
- internal ownership and governance;
- cybersecurity arrangements;
- maintenance, adaptation and evolution plans;
- technical capacity needed to operate the solution in its own environment;
- understanding of external dependencies.
If an autonomy assessment cannot be provided, or reveals limitations, the sharing entity may consider appropriate risk‑mitigation measures, particularly in relation to cybersecurity. This does not affect the obligation to make the solution available under Article 4(1).
|
Output of this step: where requested, an autonomy assessment, received from the reusing entity and recorded as part of the request record. |
📤 Step 7. Deliver the interoperability solution and accompanying materials
The sharing entity may use an appropriate delivery channel (e.g. repository access, secure file transfer, controlled download link).
Where the interoperability solution is delivered through a centrally operated or browser-based service, reuse may, where appropriate, consist in granting access rights to the reusing entity, support to onboarding, providing access to a test or pilot environment, or making available the relevant interfaces and administration tools, rather than handing over source code for parallel deployment.
Where the sharing entity has requested an autonomy assessment under Article 4(2), it may clarify whether final operational delivery or adoption is sequenced after receipt of that assessment, and which information has already been provided to enable the assessment to be carried out.
The level of security applied may be proportionate to the nature of the solution and consistent with applicable internal policies and should not create unnecessary barriers to sharing.
|
Output of this step: a delivery confirmation, together with a brief list of the artefacts delivered, recorded as part of the request. |
🧾 Step 8. Close the request and keep a minimal audit trail
The sharing entity may retain a concise record of how the request was handled, including:
-
the original request,
-
the outcome of the exception screening (where applicable),
-
a reference to the version or release shared,
-
the reuse conditions statement provided,
-
any autonomy assessment received, if one was requested,
-
the delivery confirmation and list of artefacts made available,
-
where relevant, a brief reasoned explanation for refusal.
Repeated requests for the same interoperability solution may indicate that publication under the publication pathway could be considered in future.
|
Output of this step: a request record, confirming that the direct-sharing process has been completed and its outcome documented for internal traceability purposes. |
For further details on this pathway, including legal context, implementation considerations and examples, see the corresponding Section (3.3) in the extended version of the Guidelines.
For further guidance and clarification, please refer to the FAQ section available on the Portal.