This certificate applies to software projects that are not externally distributed or have not yet declared a licence. It confirms that all third-party dependencies, including transitive ones, have been identified and externally verified for mutual licence compatibility, and for critical vulnerabilities. It is suitable for internal tools or services, unlicensed or unpublished code, and projects seeking external validation before choosing a licence. It also requires that other third-party intellectual property is reviewed and documented.

The certificate does not grant distribution rights or replace licence selection and compliance, as it does not assess the project’s own licensing. It builds upon the Self-Assessed Dependencies Certificate, providing stronger assurance of third-party legal and security risks by extending the scope to transitive dependencies and introducing verification by the Licence Management Team, after the software team has internally evaluated key points about dependencies, licences, and security, and prepared verification materials.

A full specification of software licensing certificates is also available for GÉANT participants.

Prerequisites

Ensure your software project:

• Has all direct and transitive dependencies identified and documented (an internal list is mandatory)

• Has identified licences for all direct and transitive dependencies

• Has confirmed that all dependency licences are mutually compatible for use in the software

• Contains no known critical vulnerabilities in dependencies
• Lists any other third-party intellectual property included in the project (source code, components, content, designs, models, and similar assets that may be recorded in the NOTICE file)

• Is registered in the GÉANT Software Catalogue

Step-by-Step Process

Identify Dependencies

Compile a comprehensive list of all direct and transitive third-party dependencies used in your software project. You may use a Software Composition Analysis (SCA) tool or the GÉANT SCA service.

Document licence and vulnerability information for each dependency. Having an internal list of all included third-party libraries and code is mandatory. It should list all third-party components, their versions, licences, and known vulnerabilities.

If the project contains multiple repositories, separately list dependencies for each component and its respective repository. Include all standalone modules developed for joint use, even if loosely coupled (for example, internal services).

Verify Compatibility and Compliance

Confirm that every dependency is under a valid open source or proprietary licence. Ensure that all dependency licences are mutually compatible for use in your software.

Manually review all other third-party intellectual property, including source code, components, content, designs, models, and similar assets. Identify, assess, and document their inclusion, as SCA tools may not detect them. These records may be included in the project’s NOTICE file with attribution or licence notices if required by their terms of use.

Address Known Issues

Address all critical vulnerabilities in dependencies, typically by upgrading to secure versions.

Resolve any known licence incompatibilities and instances of improper use of third-party intellectual property.

Prepare Required Documentation

Prepare and make the following available to your team:

• A list of all direct and transitive dependencies, including name, version, licence, and known vulnerabilities
• Records of other third-party intellectual property included in the project, if any
• Evidence of dependency assessment and vulnerability checks

Optional README and NOTICE files 

Consider preparing project artefacts containing dependency information (excluding vulnerability details; use available templates). Having these documents early makes the software more accessible and supports future licence declaration:

• README – Optional, but useful to capture basic information about the software early; it is the starting point for documented and licensed software
• NOTICE – Optional, but required if legal notices or attributions for third-party components are mandated by dependency licences

Consult with the Licence Management Team if you need clarifications or support during preparation.

Submit Request

Send a request to the Licence Management Team, including:

• Detailed dependency list with licences, SCA results, or reference to the GÉANT SCA service performed
• Third-party intellectual property details, if any
• Supporting documentation, such as descriptions of third-party components, README, NOTICE, or internal reports on dependencies, licences, and vulnerabilities

Refer to Contact Us for instructions on communicating with the team.

Respond to Review Feedback

Cooperate with the Licence Management Team to:

• Provide requested clarifications
• Remediate identified incompatibilities or vulnerabilities
• Update dependency records and documentation as needed

Use Certificate

Upon approval, your project will receive the Verified Dependencies Certificate, visible at certificates.software.geant.org and in the GÉANT Software Catalogue.

Reference the certificate in documentation, metadata, project pages, or communications. The Licence Management Team will provide guidance on how to do this.

After Certification

Maintain Compliance

To keep the certificate valid:

• Keep dependency, licence, and vulnerability data accurate and up to date.
• Monitor for new vulnerabilities or licence conflicts, which may be newly discovered or introduced by dependency and licence changes.
• Address identified issues promptly.

• Update documentation as needed.

If issues arise, your team may be asked to provide additional information, address identified licence or vulnerability issues, or update dependency records.

Certificate Validity

The certificate is valid for five years, covering all versions released within that period, provided vulnerabilities and licence incompatibilities are promptly addressed.

Renewal

Reassess and submit a renewal request before the five-year validity period ends, or sooner if there are significant changes (e.g. component replacement or inclusion of a new component under a novel licence).

Avoiding Revocation

The certificate may be revoked if:

• Direct or transitive dependencies are missing or undocumented
• Incompatible licences of dependencies are introduced or discovered
• Non-compliance between component licences remains unresolved
• Critical vulnerabilities in dependencies remain unresolved
• The team fails to respond to enquiries during investigations or reviews
• The development team requests revocation

Optional: Continuous Dependency and Licence Scanning

Integrate SCA scanning into the CI/CD pipeline to detect licence or vulnerability issues early, and maintain long-term compliance.