Revised EVB-IT: Open Source as the Default for Newly Developed Custom Software – What Providers Need to Know

I. Overview

The “Supplementary Terms and Conditions for the Procurement of IT Services” (Ergänzende Vertragsbedingungen für die Beschaffung von IT-Leistungen– EVB-IT) consist of standardised contract forms and general terms and conditions for public-sector IT procurement in Germany. They are used in a large number of procurement projects by the federal government, the federal states, municipalities and other public contracting authorities. For providers selling IT services to the public sector, they therefore frequently constitute the governing contractual framework.

On 20 March 2026, the Federal Ministry for Digital Affairs and State Modernisation (Bundesministerium für Digitales und Staatsmodernisierung)published the revised templates, which the IT Planning Council (IT-Planungsrat)had taken note of on 26 November 2025 and recommended to its members for use.The revision covers eight of the twelve contract types, including those most relevant to software providers: EVB-IT Erstellung (software development),Überlassung Typ A (software licensing), Pflege S (software maintenance),Dienstleistung (services), System, Systemlieferung (system delivery), Service, and the EVB-IT framework agreement. The stated objective is to facilitate the legally sound integration of OSS into public procurement and to contribute tothe digital sovereignty of the public sector.

For pure SaaS offerings, the immediate reach of the revision is limited for now: EVB-IT Cloud – whose scope expressly covers SaaS, PaaS, IaaS and managed cloud services – was, like EVB-IT Überlassung Typ B, not part of theOSS revision; it has, however, also been migrated to EVB-IT digital and is currently available as version 1.0.2 of 1 March 2026. The official overview indicates that corresponding negotiations were envisaged for 2026. The provisions now published may therefore offer indications of the possible direction of a future cloud revision; they do not, however, predetermine its content. SaaS providers may nevertheless already be affected today where, in addition to the cloud service itself, they provide customisation, development, implementation or support services under other EVB-IT contract types.

II. Open Source as the Default for Newly Developed Custom Software

The most significant change is the express integration of OSS into theEVB-IT. Until now, the contract forms and general terms were geared towardsproprietary software. Incorporating OSS was possible, but frequently requiredindividually negotiated provisions on usage rights, licence terms, source code, maintenance and liability – increasing the drafting and review burden on bothsides.

The revised EVB-IT can reduce this burden considerably. It is worth looking closely, however, at where OSS actually becomes the default: the newEVB-IT Erstellung terms provide that the contractor delivers custom software orcustom software components as OSS unless the contract stipulates otherwise. The same applies under the EVB-IT System contract to custom software newly developed there. For standard software, maintenance, services and support, bycontrast, the revision predominantly creates options that must be activated inthe individual contract. Procuring proprietary software remains expressly possible.

For providers, the standardisation can reduce the contractual review and drafting effort and ease access to public procurement projects for OSS-based offerings. In custom development, this may also shift the business model: theeconomic significance of exclusive usage rights decreases for components to be provided as OSS, while development, integration, maintenance, operations and support may gain in weight. At the same time, providers should distinguishclearly between newly developed custom software, pre-existing proprietarycomponents and third-party software. This delineation is decisive both for pricing and for subsequent OSS licensing and any publication on openCode – andshould be reflected transparently in the offer, the service specification and, where appropriate, a component or usage-rights matrix.

III. SBOM as an Optional Contractual Deliverable

Another new feature is the inclusion of the “Software Bill of Materials”(SBOM) – in simple terms, a structured list of components showing which libraries, frameworks and dependencies a piece of software consists of. Therevised EVB-IT make it possible to agree on the handover of an SBOM; for the maintenance of standard software, its ongoing updating can also be stipulated(EVB-IT Pflege S).

An SBOM does not thereby become mandatory by default; it becomes anoptional contractual deliverable. Public contracting authorities can, however, make its handover a binding requirement in the tender documents – for instanceto determine quickly, in the event of a vulnerability in a component, whether the deployed software is affected. Providers should therefore expect the option to be exercised.

Providers that have not yet automated SBOM generation should establish the necessary processes. The Cyber Resilience Act will likewise require manufacturers of products with digital elements within its scope to produce a machine-readable SBOM covering at least the top-level dependencies. CRA compliance and fulfilment of a specific EVB-IT SBOM clause are, however, not automatically congruent: format, granularity, update intervals and contractual responsibility in particular must be assessed separately.

IV. Optional Publication on openCode

Also new is the option to agree on the additional publication of developed software on the openCode platform. This is intended to facilitate thereuse of publicly funded software: other authorities can assess whether anexisting solution can be adopted or further developed instead of commissioning a comparable development anew.

Publication on openCode does not occur automatically. It is owed only where it has been agreed in the individual contract. Even then, it operates alongside the provision of the software under an open source licence and the contracting authority’s further usage rights; it does not replace the grant of rights.

For contractors, this creates additional requirements in preparing for publication. In particular, they must clarify which parts were newly developed, which pre-existing proprietary components are used and which third-party components are included. Also required are a robust chain of title – including the rights of employees and subcontractors – a review of licence compatibility, and a clean-up of the repository to remove credentials, personal data and confidential information.

V. Licence Lists as Guidance

The multitude of different open source licences has always been a challenge in practice. For the first time, the revised EVB-IT contain their own definition of open source software and rely, for the classification of licences, on an open source licence list reviewed by openCode. openCode additionally publishes a negative list of licences expressly not accepted. There view is based on whether the licence conforms to the Open Source Initiative’s open source definition and raises no identifiable difficulties for public administration.

The positive list comprises a large number of widely used and less common licences – permissive licences such as MIT, Apache-2.0 and BSD-3-Clause as well as copyleft licences such as GPL-3.0-only and GPL-3.0-or-later, AGPL-3.0-onlyand AGPL-3.0-or-later, MPL-2.0 and the EUPL-1.2. Not accepted are, among others, the Server Side Public License (SSPL-1.0), the Elastic License 2.0 and various Creative Commons licences with NC or ND restrictions.

For providers, the specific component and its licensing are therefore decisive. Current versions of the MongoDB Community Server are, as a rule, licensed under the SSPL. The position for Elasticsearch and Kibana is more nuanced, as substantial parts of the source code have additionally been offered under the AGPLv3 since 2024. A blanket assessment by product or vendor is therefore insufficient – another reason why a look at one’s own SBOM is worthwhile.

Moreover, inclusion in the licence list neither means that a licence is suitable for every project nor that it is compatible with all other licences inuse. The lists provide valuable guidance and can reduce the review effort for both parties; they do not replace an individual assessment of the specific licensing and usage situation – sound licence compliance remains essential.

VI. From Form to Legal Tech Solution

Finally, access to the EVB-IT themselves has been modernised: all current contract types are available in the contract-drafting tool “EVB-IT digital” as playbooks for interview-based drafting. The tool guides the user through the contract and generates an editable contract document based on the answers given; a reproducibility code additionally makes it possible to verify whether a generated document has subsequently been modified. The templates are available free of charge and in an accessible format.

The interview-based guidance may, however, create the impression that completing the playbook also completes the legal structuring of the procurement project. The tool supports the selection and compilation of contract provisions; it does not replace the assessment of whether the chosen contract type, the activated options and the supplementary annexes fit the specific project. Responsibility for the content remains with the user.

Conclusion

The revision of the EVB-IT is an important step for public-sector IT procurement. Open source software is systematically integrated into the contract templates for the first time. For newly developed custom software, provision as OSS is now, in principle, the contractual default unless otherwise agreed; in other service areas, additional selection and drafting options are available in particular. Contractual hurdles are thereby reduced – but the necessary legal and technical assessments are not rendered dispensable.

Software providers should in particular clarify which parts of their solutions are newly developed, pre-existing or sourced from third parties, whether the rights required for OSS licensing and, where applicable, publication on openCode are in place, and whether the licences used are compatible with one another. In addition, they should integrate the generation and version-specific maintenance of SBOMs into their development and release processes. For custom development, pricing and bidding strategy should moreover reflect that, for the components concerned, economic value creation may restless on exclusivity and more on development, integration, operations, maintenance and support.

For providers of pure cloud or SaaS services, a future substantive revision of EVB-IT Cloud remains particularly relevant. The current changes give indications of possible future requirements but do not predetermine their specific design.

The EVB-IT provide a standardised contractual structure for all of this.They do not replace a careful service specification or the legal, technical and, in particular, licence-related assessment of the individual project.

‍