Pathway 4

Pathway 4: Sharing adapted interoperability solutions (Article 4(4))

< Pathway 3 Pathway 5 >

This pathway applies when:

a reusing entity adapts an interoperability solution to its own needs;
a third party lawfully reuses and adapts an interoperability solution, in cases where reuse and adaptation are permitted under the applicable licence or access conditions;
there is a question whether and how the adapted solution must be shared.

Related pathways:

where an adapted interoperability solution is made public under Article 4(3), the publication pathway in these Guidelines applies (Pathway 2);
where an adapted interoperability solution is made available upon request to another Union entity or public sector body, the direct-sharing pathway applies (Pathway 3);
where an adapted interoperability solution is accessible through the Interoperable Europe Portal, the conditions set out in Article 8(3) also apply (Pathway 2, Step 2).

Legal basis

Right to adapt: A Union entity or public sector body, or a third party reusing an interoperability solution, may adapt it to its own needs unless third-party intellectual property rights restrict adaptation (Article 4(4)).
Obligation to publish adapted solution in certain cases: If the interoperability solution is made public under Article 4(3), the adapted interoperability solution must be made public in the same way (Article 4(4)).

Implementation guidance

🧬 Step 1. Identify the upstream solution, the version used, and the purpose of adaptation

The reusing entity may first identify clearly what is being adapted and why. The key reference point is the upstream interoperability solution and the version, release, or other stable reference on which the adaptation is based.

Adaptation may concern software components, source code or configurations, technical specifications, interfaces or data models, documentation or implementation guidance, or a mixed package combining several of these elements.

The reusing entity may record the name and identifier of the upstream solutions, the version, release or stable reference used, the owner or maintainer, the purpose of the adaptation and the target context.

Output of this step: an adaptation initiation note by the reusing entity.

⚖️ Step 2. Check the legal and rights framework for the adaptation

In practice, identifying third-party intellectual property rights that may affect the reusing entity’s ability to adapt the solution may include checking:

whether any third-party code, libraries, components, specifications, documentation or other assets are embedded in, or necessary for, the solution;
whether those elements are subject to rights or terms that may restrict modification, redistribution or onward publication;
whether contractual arrangements affect the practical ability to adapt or make available the adapted solution;
whether any new components introduced through the adaptation create additional licensing or compatibility issues.

This review should focus on real constraints, and it does not require a complete intellectual property audit in every case.

Output of this step: a short rights and constraints note identifying any third-party intellectual property issues or other legal factors relevant to the adaptation and any onward sharing or publication.

🧾 Step 3. Carry out and document the adaptation in a way that preserves provenance

The reusing entity is recommended to document the relationship between the adapted solution and the upstream solution.

what was changed and why;
which upstream version or release was used;
whether the adaptation remains closely aligned or diverges more substantially;
any significant implications for interoperability, deployment, maintenance, compliance or security;
the entity responsible for the adapted version.

Clear versioning or references (e.g. release tags, forks, branches) help distinguish the adapted solution from the upstream one.

At minimum, public organisations may record the source and target terms or codes, the type of relationship, any transformation rule applied, any non-equivalent terms, and the version and date of the mapping.

Where an adaptation corrects a defect or introduces an improvement of broader value, informing the upstream maintainer or contributing the change back is a good practice.

When adapting an interoperability solution, reusing entities should consider whether a mandatory interoperability assessment is required under Article 3 of the Act.

Output of this step: documentation on the adaptation of the interoperability solution, with clear provenance and versioning.

For further details on carrying out and documenting adaptations, see Section 3.4.1.3 and Annex 6 in the extended version of the Guidelines.

🚦 Step 4. Decide whether publication of the adapted solution is mandatory

The reusing entity should identify how the upstream solution was shared:

The adapted solution must also be made public in the same way under Article 4(3). ‘Made public in the same way’ refers to the publication route under Article 4(3) (publication on the Interoperable Europe Portal or through a connected portal, catalogue or repository), it does not require the adapted solution to be hosted in the same repository.

Publication is not required. The adapted solution may be published voluntarily or shared upon request.

Pathway 2 Pathway 3

Output of this step: a recorded decision indicating whether publication of the adapted solution is mandatory or optional, with a brief reference to the upstream publication route.

📦 Step 5. Prepare the adaptation package for publication or sharing

As good practice, the adaptation package should enable another reusing entity to understand the adapted solution.

the title or identifier of the adapted solution;
a clear reference to the upstream solution and version or release used;
a short change log (what has been changed and why);
sufficient documentation to understand and assess the adapted solution;
where relevant, a semantic mapping or correspondence table showing how code lists, vocabularies, concepts or data fields have been aligned;
where applicable, version history, release identifiers, documented source code, and references to open standards or technical specifications used;
the applicable licence or other relevant rights information for the adapted solution;
the identity of the owner or maintainer of the adapted solution and a contact point, where appropriate;
any significant limitations, dependencies, or risks that a future reuser should know.

Where the adaptation is limited and remains very close to the upstream solution, the reusing entity should, where possible, rely on references or links to upstream materials instead of duplicating them.

Output of this step: a package ready for publication or direct sharing of the adapted solution, including the information necessary to understand its relationship to the upstream solution.

🌐 Step 6. Publish or choose the appropriate sharing route

If publication is mandatory under Article 4(4)

If Step 4 shows that publication is mandatory, the reusing entity should follow the publication pathway in these Guidelines (Pathway 2) and indicate:

the upstream solution and the version or release;
the adapting entity or other responsible entity;
the version, release or stable reference of the adapted solution.

When the adapted solution is made accessible through the Interoperable Europe Portal, the reusing entity should also ensure that the Article 8(3) conditions are met.

If publication is optional

If publication is optional, the sharing entity may:

keep the adapted solution internal;
publish it voluntarily; or
share it upon request (Pathway 3).

Output of this step: a published adapted solution or recorded decision.

🔄 Step 7. Manage maintenance, upstream alignment, and future evolution

The owner of the upstream solution is not responsible for maintaining adaptations developed by reusing entities.

To support sustainability and avoid unnecessary fragmentation, the reusing entity could define, in a proportionate manner:

who owns and maintains the adapted solution;
whether the adapted solution is intended to track upstream updates;
how upstream security patches, bug fixes and functional improvements will be monitored and assessed;
how changes to licensing, dependencies, or compliance requirements will be handled;
whether contributions back to the upstream solution are envisaged;
how the lifecycle status of the adapted solution will be communicated to future reusers.

Output of this step: a short maintenance and evolution note for the adapted solution.

For further details on this pathway, including legal context, implementation considerations and examples, see the corresponding Section (3.4) in the extended version of the Guidelines.

Download the extended version

For further guidance and clarification, please refer to the FAQ section available on the Portal.

Report abusive content Share