Softwarelizenz-Compliance Verteidigungsverträge: COTS, Audit, DFARS

Software-Lizenzkonformität wird in den meisten Organisationen als Formalität im Beschaffungsprozess behandelt. Im Verteidigungsgeschäft ist sie etwas, das einer regulatorischen Pflicht näherkommt, mit finanziellen, rechtlichen und sicherheitsrelevanten Folgen, die sich über jedes Programm aufsummieren, das ein Auftragnehmer gleichzeitig betreibt. Eine einzige Unternehmenslizenz, die fehlerhaft über ein klassifiziertes und ein nicht klassifiziertes Netz angewendet wird, eine GPL-lizenzierte Bibliothek, die ohne Quelloffenlegung in ein Lieferobjekt eingebettet wird, oder eine Serverlizenz, die nach Sockets statt nach Kernen abgerechnet wird – jeder dieser Fälle kann sechs- oder siebenstellige True-up-Forderungen eines prüfenden Anbieters auslösen, eine Korrekturmaßnahmenanforderung der DCSA oder eine nachteilige geistige Eigentumsentscheidung, die die Rechtestufe eines Lieferobjekts zurücksetzt.

Die Komplexität ist strukturell. Verteidigungsauftragnehmer arbeiten über mehrere Sicherheitsdomänen hinweg, unterstützen Dutzende von Programmen unter unterschiedlichen Verträgen und stellen COTS-Software in Konfigurationen bereit – virtualisierte Cluster, Regierungs-Cloud-Enklaven, Missionssysteme im Ausland – für die die Lizenzanbieter ihre Abrechnungsmetriken nicht sauber ausgelegt haben. Das DFARS-Rechte-Software-Framework legt eine Schicht regierungsspezifischer Pflichten über die kommerziellen Standardlizenzbedingungen. Die Aufnahme von Open Source in Lieferobjekte löst Offenlegungsanforderungen aus, die die meisten Software-Teams erst dann kennenlernen, wenn ein Programmsicherheitsbeauftragter sie vor einer Lieferung beanstandet.

Dieser Artikel behandelt die gesamte technische und regulatorische Landschaft: Lizenzrisikomuster, die nur Verteidigungsprogramme aufweisen, COTS-Inventararchitektur, DFARS-Rechteklauseln, Vorbereitung von Prüfnachweisen, Open-Source-Konformitätswerkzeuge, Methoden der Lizenzoptimierung und Software-Escrow-Anforderungen für einsatzkritische Systeme.

Software-Lizenzrisiken in Verteidigungsprogrammen

Verteidigungsauftragnehmer unterschätzen Software-Lizenzrisiken systematisch, weil Programmbudgets die Kosten für den Lizenzkauf ausweisen, selten aber die Kosten für die Einhaltung der Bedingungen, unter denen diese Lizenzen eingeräumt werden. Die Lücke zwischen Kauf und Konformität wächst mit jedem Programm, das ein COTS-Werkzeug in einem neuen Vertrag wiederverwendet, ohne zu prüfen, ob die bestehende Lizenz diese Nutzung zulässt.

Muster der Unterschätzung des Umfangs

Das häufigste Unterschätzungsmuster betrifft Server- und Prozessor-Lizenzmetriken. Unternehmenssoftware-Anbieter sind über Produktgenerationen hinweg von pro Server zu pro Prozessor zu pro Kern gewechselt. Ein Auftragnehmer, der 2018 eine Datenbanklizenz pro Server gekauft und die Last 2024 auf einen neuen Mehrsockel-Server migriert hat, kann heute nicht konform sein, ohne die Software überhaupt geändert zu haben – die Hardwareänderung hat die Prozessoranzahl erhöht und damit die Lizenzpflicht nach modernen Core-Factor-Abrechnungsregeln geändert. Wenige Programmmanager verfolgen diese Verknüpfung zwischen Infrastruktur-Erneuerungszyklen und Änderungen der Lizenzmetrik.

Die benutzerbezogene Lizenzabrechnung zeigt ein anderes Unterschätzungsmuster. Lizenzen für benannte Benutzer sind in klassifizierten Umgebungen häufig überbereitgestellt, weil Inhaber von Sicherheitsfreigaben zwischen Programmen rotieren. Ein Benutzer, der die Arbeit an Programm A beendet und zu Programm B wechselt, hat sein Konto in den Softwaresystemen von Programm A weiterhin aktiv, bis es jemand administrativ entfernt. SAM-Werkzeuge, die aktive Benutzerkonten zählen statt authentifizierte aktive Benutzer, weisen mehr bereitgestellte Arbeitsplätze aus als tatsächlich genutzt werden, was die scheinbare Konformitätslücke vergrößert – Organisationen dagegen, die nur gleichzeitige Sitzungen zählen, können feststellen, dass sie in Spitzenzeiten mit gestiegener Benutzerzahl nicht konform sind.

Cloud-Lizenzen in der Regierungs-Cloud

Cloud-Lizenzen in GovCloud-Umgebungen (IL4-, IL5-, IL6-Enklaven) erzeugen eine Lizenzrisikokategorie, die die meisten On-Premises-Beschaffungsteams nicht zu bewältigen in der Lage sind. Standardmäßige kommerzielle COTS-Lizenzen erlauben die Bereitstellung in einer gehosteten Umgebung eines Drittanbieters häufig nicht ohne Cloud-Zusatz. Anbieter, die eine Bereitstellung in einem Regierungs-Cloud-Mandanten feststellen – über IP-Telemetrie, im Rahmen einer Prüfung eingereichte Nutzungsprotokolle oder Reseller-Berichte – behandeln die Bereitstellung als separaten Lizenzbedarf neben dem On-Premises-Anspruch. Verteidigungsauftragnehmer, die On-Premises-Lasten mit bestehenden Dauerlizenzen in IL5-Cloud-Umgebungen migriert haben, ohne Cloud-Bereitstellungsrechte zu prüfen, tragen in jedem betroffenen Programm ein nicht offengelegtes Konformitätsrisiko.

Für einen breiteren Blick darauf, wie Software-Supply-Chain-Steuerungen mit der Lizenzierung zusammenwirken, siehe unsere Analyse zu SBOM-Durchsetzung in Verteidigungs-Pipelines, die die nachgelagerten Anforderungen an Komponententransparenz behandelt, die aus derselben Konformitätshaltung folgen.

COTS-Lizenzinventarmanagement

Ein COTS-Lizenzinventar ist die Grundlage jedes Software-Konformitätsprogramms. Es hat zwei Komponenten, die synchron gepflegt werden müssen: die Berechtigungsdatenbank (welche Lizenzen der Auftragnehmer gekauft hat) und die Bereitstellungsdatenbank (welche Software tatsächlich installiert und im Einsatz ist). Die Konformitätslücke ist die Differenz zwischen beiden. Das Management dieser Lücke erfordert sowohl genaue Daten als auch einen Prozess zur Klärung von Abweichungen.

Auswahl von SAM-Werkzeugen für Verteidigungsumgebungen

Software-Asset-Management-Werkzeuge müssen Anforderungen erfüllen, die die meisten Consumer-Produkte oder reinen SaaS-Produkte von vornherein ausschließen. Für klassifizierte Netze muss das SAM-Werkzeug:

• vollständig On-Premises arbeiten, ohne Call-Home-Telemetrie an externe Endpunkte
• agentenbasierte Discovery auf Windows- und Linux-Endpunkten unterstützen, ohne Internetzugang für Agenten-Updates zu benötigen
• das gefundene Inventar in exportierbaren Formaten (CSV, SPDX oder XML) ohne Cloud-Intermediäre bereitstellen
• getrennte Discovery-Instanzen für jede Sicherheitsdomäne (nicht klassifiziert, CUI, klassifiziert) ohne domänenübergreifende Datenabflüsse unterhalten
• Produktnamen und Versionen gegen eine Offline-Lizenzbibliothek normalisieren, die über kontrollierte Medien aktualisiert werden kann

Werkzeuge, die diese Anforderungen erfüllen, sind im Allgemeinen On-Premises-Bereitstellungen von Unternehmens-SAM-Plattformen. Die Normalisierungsfähigkeit der Lizenzbibliothek ist besonders wichtig: Die Rohausgabe der Discovery listet Hunderte von Produktvarianten und Versionszeichenketten auf, die auf kanonische Produktidentitäten aufgelöst werden müssen, bevor ein Berechtigungsabgleich sinnvoll ist.

Automatisierte Discovery gegenüber manuellem Inventar

Automatisierte Discovery ist für Endpunktsoftware genauer und konsistenter als manuelle Inventur, hat aber in Verteidigungsumgebungen blinde Flecken: Software auf Systemen ohne Netzwerkanbindung (autarke klassifizierte Arbeitsplätze, eingesetzte Systeme, Testaufbauten), Software im Firmware oder als Teil einer Plattformintegration geliefert, sowie Software, die nur in bestimmten Missionsphasen läuft und bei Discovery-Scans nicht aktiv ist. Manuelle Inventur ergänzt die automatisierte Discovery für diese Kategorien, mit dokumentierten Prüfverfahren und periodischen körperlichen Begehungen nicht vernetzter Systeme.

Architektur der Lizenzberechtigungsdatenbank

Die Berechtigungsdatenbank muss für jeden Lizenzdatensatz speichern:

• Produktname und Version (normalisiert auf die kanonische Form des Anbieters)
• Lizenzmetrik (pro Arbeitsplatz, pro Kern, pro Server, gleichzeitig, Abonnement-Einheit)
• Anzahl der Lizenzberechtigungen und die zur Metrik passende Maßeinheit
• Berechtigungsnachweise: Bestellnummer, Rechnungsnummer, Seriennummer der Lizenzurkunde, Referenz auf den ELA-Plan
• Programm und Vertrag, die die Lizenz stützt (für Kostenzuordnung und Prüfungsrückverfolgung)
• Einschränkungen des Bereitstellungsumfangs (nur On-Premises, Cloud-Zusatz enthalten, klassifiziertes Netz zulässig)
• Verlängerungsdatum oder Dauerstatus
• Regierungsnutzungs-Zusätze oder besondere föderale Zusatzbedingungen

Die Abgleichsabfrage, die den Konformitätslückenbericht erzeugt, muss die Berechtigungsdatenbank über die normalisierte Produktidentität mit der Discovery-Datenbank verknüpfen und die Bereitstellungen gegen die Berechtigungen nach Maßeinheit summieren. Abweichungen, bei denen die Bereitstellungen die Berechtigungen übersteigen, erfordern eine sofortige Triage: erst die Genauigkeit der Bereitstellungszahl bestätigen, dann entweder zusätzliche Berechtigungen kaufen oder nicht autorisierte Installationen entfernen.

DFARS-Software-Rechteklauseln

DFARS Part 227 legt den Rahmen fest, unter dem die US-Regierung Rechte an Software erwirbt, die im Rahmen von Verteidigungsverträgen entwickelt oder bei ihrer Erfüllung genutzt wird. Für Verteidigungsauftragnehmer unterscheiden sich die zutreffenden Klauseln je nachdem, ob die Software kommerziell ist (geregelt durch DFARS 227.7202) oder nicht kommerziell (geregelt durch DFARS 227.7103 und die zugehörige Vertragsklausel DFARS 252.227-7014).

DFARS 252.227-7014: Rechte an nicht kommerzieller Software

DFARS 252.227-7014 gilt für Software, die eigens im Rahmen eines Verteidigungsvertrags mit Regierungsmitteln entwickelt wurde, ganz oder teilweise. Die Klausel legt vier Standard-Rechtestufen fest:

• Unlimited Rights: Die Regierung darf die Software ohne Einschränkung nutzen, vervielfältigen, ändern, freigeben oder offenlegen. Gilt für Software, die vollständig auf Kosten der Regierung entwickelt wurde.
• Government Purpose Rights (GPR): Eine Übergangsstufe für Software mit gemischter Finanzierung. Die Regierung darf die Software für jeden Regierungszweck nutzen, sie während der GPR-Frist (typischerweise fünf Jahre) aber nicht an kommerzielle Parteien freigeben. Nach Ablauf der GPR-Frist wandeln sich die Rechte in Unlimited Rights um.
• Limited Rights: Gilt für Software, die vollständig zu privaten Kosten entwickelt wurde. Die Regierung darf die Software nur zu innerstaatlichen Regierungszwecken nutzen und ohne Zustimmung des Auftragnehmers nicht an Dritte freigeben.
• Specially Negotiated License Rights: Jede Rechteregelung, die außerhalb der Standardstufen liegt, festgehalten in einem vertragsspezifischen Lizenz-Zusatz. Wird für hybride Sachverhalte verwendet, die die Standardstufen nicht sauber auflösen.

Die Finanzierungsbestimmung – ob die Entwicklung auf Kosten der Regierung, zu privaten Kosten oder gemischt erfolgte – ist der umstrittenste Aspekt von Rechtebehauptungen. Auftragnehmer müssen zum Zeitpunkt der Entwicklung detaillierte Finanzierungsunterlagen für jede Software-Komponente führen, um ihre Rechtebehauptungen bei einer Prüfung der technischen Datenrechte zu stützen.

Weitergabe kommerzieller Software-Lizenzen

Bei COTS-Software verpflichtet DFARS 227.7202-1 die Regierung, nur die Rechte zu erwerben, die im kommerziellen Standardlizenzvertrag des Anbieters eingeräumt werden, sofern diese Bedingungen mit dem Bundesrecht vereinbar und nicht anderweitig verboten sind. Das bedeutet, dass der Lizenzvertrag des COTS-Anbieters unverändert durch das DFARS-Rechte-Regime an den Regierungskunden weitergegeben wird – die Regierung kann Unlimited-Rights-Bestimmungen nicht gegen einen COTS-Anbieter anrufen, dessen Standardbedingungen die Regierungsnutzung einschränken.

Für Hauptauftragnehmer entsteht daraus eine Weitergabepflicht: Wenn COTS-Software in ein Lieferobjekt-System eingebettet wird, muss der Hauptauftragnehmer die COTS-Komponenten benennen, ihre kommerziellen Lizenzbedingungen beifügen oder darauf verweisen und sicherstellen, dass die Regierung versteht, dass sie die Bedingungen des Anbieters erhält und keinen aus DFARS-Rechten abgeleiteten Anspruch. Das Versäumnis, COTS-Komponenten zu benennen und ihren kommerziellen Lizenzstatus während der Vertragserfüllung geltend zu machen, kann dazu führen, dass die Regierung später auf Basis des DFARS-Standardfalls Unlimited Rights beansprucht – ein Streit, dessen gerichtliche Austragung teuer ist.

Das Verständnis dafür, wie Software-Rechte mit dem breiteren Rahmen des vollständigen Leitfadens zur Verteidigungsbeschaffung zusammenwirken, hilft Auftragnehmern, ihre Strategie zum geistigen Eigentum vor der Auftragserteilung zu strukturieren, wenn der Verhandlungshebel am größten ist.

Prüfungsbereitschaft für Anbieter- und DCSA-Prüfungen

Eine Software-Lizenzprüfung kann von einem kommerziellen Anbieter eingeleitet werden, der seine Prüfrechte aus einem Unternehmenslizenzvertrag wahrnimmt, oder von der DCSA im Rahmen einer Anlagenüberprüfung, die die Bewertung von Informationssicherheitskontrollen umfasst. Die beiden Prüfungsarten unterscheiden sich in Umfang und Befugnis, verlangen aber dasselbe Grundlagennachweispaket.

Vorbereitung des Prüfnachweispakets

Das Prüfnachweispaket muss im Voraus vorbereitet und in einem Zustand gehalten werden, dass es innerhalb der im Lizenzvertrag genannten Ankündigungsfrist vorgelegt werden kann – häufig 30 Tage, manchmal auch nur 10 Arbeitstage. Das Paket muss enthalten:

• Lizenzurkunden für alle Produkte im Prüfumfang
• Bestellungen und Rechnungen mit Querverweisen auf jedes Produkt und jede Version, die alle Lizenzkäufe für den vom Prüfer genannten nachträglichen Zeitraum abdecken (typischerweise drei bis fünf Jahre)
• Pläne zum Unternehmenslizenzvertrag (ELA) mit Inkrafttretsdaten, abgedeckten Produktlisten und autorisierten Benutzerzahlen
• Discovery-Berichte des SAM-Werkzeugs, die höchstens 30 Tage vor der Prüfungsanforderung datiert sind und die bereitgestellten Produktversionen und Stückzahlen zeigen
• Abgleichsblatt, das für jedes Produkt im Prüfumfang Berechtigungen und Bereitstellungen gegenüberstellt
• Regierungsnutzungs-Zusätze oder föderale Ergänzungen, die die kommerziellen Standardbedingungen ändern
• Außerbetriebnahmeprotokolle für Software, die im Prüfzeitraum aus dem Betrieb genommen wurde

Methodik des Lizenzabgleichs

Die Methodik, mit der Prüfnachweise erstellt werden, muss konsistent und dokumentierbar sein. Bei Lizenzen pro Arbeitsplatz sollte die Methodik die authentifizierten aktiven Benutzerzahlen über einen definierten Messzeitraum verwenden (typischerweise der 90-tägige Spitzennutzungszeitraum vor der Prüfung) und keine Momentaufnahme an einem einzigen Stichtag. Bei Lizenzen pro Kern muss die Methodik die physische Kernanzahl jedes Servers oder virtuellen Maschinen-Clusters dokumentieren, der die Software ausführt, und die vom Anbieter veröffentlichte Core-Factor-Tabelle anwenden, soweit einschlägig. Bei Abonnement-Lizenzen muss die Methodik den Zeitraum aktiver Nutzung erfassen und nicht nur die aktuelle Momentaufnahme, weil nachträgliche True-ups auf die historische Nutzung Anwendung finden, die während der Abonnementlaufzeit die Berechtigungszahlen überstieg.

Häufige Prüfungsbefunde in Verteidigungsumgebungen

Prüfungen bei Verteidigungsauftragnehmern decken regelmäßig einen Satz wiederkehrender Befunde auf, die ein gut gestaltetes Konformitätsprogramm aktiv beseitigt:

• Nicht lizenzierte Installationen: Software, die auf Endpunkten ohne zugehörigen Berechtigungsnachweis gefunden wird – typischerweise von einzelnen Benutzern zur Bequemlichkeit ohne Beschaffungsfreigabe installiert.
• Fehlerhafte Anwendung der Lizenzmetrik: Lizenzen pro Benutzer in prozessorbezogenen Umgebungen eingesetzt, oder Gleichzeitig-Lizenzen so abgerechnet, als wären es Lizenzen für benannte Benutzer.
• Upgrade-Lücken: Software auf eine neue Hauptversion gehoben, ohne Upgrade-Rechte unter einem abgelaufenen Wartungsvertrag erworben zu haben.
• Cloud-Bereitstellung ohne Cloud-Zusatz: On-Premises-Lizenzen auf Regierungs-Cloud-Bereitstellungen angewendet, obwohl die Bedingungen des Anbieters ein gesondertes Cloud-Nutzungsrecht verlangen.
• Fehlende Berechtigungsdokumentation: Lizenzen, die vor Jahren gekauft und installiert wurden, ohne dass Lizenzurkunde oder Bestellung aufbewahrt wurden, sodass der Auftragnehmer seinen Anspruch nicht belegen kann.

Die Supply-Chain-Dimension der Software-Lizenzkonformität greift direkt in die breiteren Kontrollen der Supply-Chain-Risikosteuerung in der Verteidigung ein, die Verteidigungsprogramme umsetzen müssen – nicht autorisierte Software ist zugleich ein Konformitätsversagen und ein Sicherheitsrisiko.

Open-Source-Lizenzkonformität

Open-Source-Software (OSS), die in Verteidigungslieferobjekte aufgenommen wird, erzeugt Konformitätspflichten, die der Art nach von COTS-Lizenzpflichten abweichen. COTS-Nichteinhaltung erzeugt eine finanzielle Haftung gegenüber dem Anbieter. OSS-Nichteinhaltung – insbesondere die Verletzung von Copyleft-Lizenzbedingungen – kann die Pflicht erzeugen, proprietären Quellcode an jeden Empfänger der Software offenzulegen, auch an die Regierung, die dann möglicherweise nicht in der Lage ist, eine weitere Offenlegung einzuschränken.

GPL-/LGPL-Copyleft-Risiko in Verteidigungslieferobjekten

Die Lizenzen GPL Version 2 und GPL Version 3 schreiben eine Copyleft-Anforderung vor: Jedes abgeleitete oder zusammengeführte Werk, das an Dritte weitergegeben wird, muss unter denselben GPL-Bedingungen lizenziert und mit dem vollständigen zugehörigen Quellcode begleitet werden (oder mit dem Angebot, ihn bereitzustellen). Für einen Verteidigungsauftragnehmer, der ein Softwaresystem an die Regierung liefert, ist die Lieferung ein Weitergabeereignis, das die GPL-Offenlegungspflicht für jede GPL-lizenzierte Komponente im Lieferobjekt auslöst.

Das praktische Risiko ist nicht die Offenlegung harmloser Hilfsprogramme – es ist die Offenlegung proprietärer algorithmischer Implementierungen, die zufällig statisch mit einer GPL-Bibliothek verknüpft sind. Wenn das Zielalgorithmenmodul eines Auftragnehmers in denselben Binärcode kompiliert ist wie eine GPL-lizenzierte Datenverarbeitungsbibliothek, können die Copyleft-Bestimmungen der GPL bei der Lieferung des Binärcodes die Offenlegung des gesamten zusammengeführten Werks verlangen, einschließlich des Zielalgorithmus. Ob dieses Ergebnis erforderlich ist, hängt von der konkreten GPL-Version, der Integrationsmethode (statische gegenüber dynamischer Verknüpfung) und den Tatsachen der Nutzung der GPL-Komponente ab – das Risiko muss aber vor der Lieferung bewertet werden und nicht erst in einer späteren Sicherheitsprüfung.

LGPL (Lesser GPL) enthält eine schwächere Copyleft-Regel, die proprietäre Software erlaubt, dynamisch gegen eine LGPL-Bibliothek zu binden, ohne Copyleft auf den proprietären Code auszulösen. Statische Verknüpfung mit einer LGPL-Bibliothek trägt weiterhin Risiko. Die Grenze zwischen sicherer dynamischer Bindung und riskanter statischer Einbindung muss auf Ebene der Build-Konfiguration bewertet werden und nicht auf Ebene des Quellcodes.

Integration des Lizenz-Scanners

Lizenz-Scanner – FOSSA, Black Duck (Synopsys), SCANOSS und vergleichbare On-Premises-Werkzeuge – automatisieren die OSS-Identifikation und Lizenzermittlung über Code-Repositories, Build-Artefakte und Container-Images. Die Integration in die CI/CD-Pipeline setzt die Lizenzrichtlinie genau dort durch, wo OSS eingeführt wird: Wenn ein Entwickler eine neue Abhängigkeit hinzufügt, erkennt der Scanner die Lizenz, prüft sie gegen die freigegebene Lizenzrichtlinie und blockiert den Build, wenn die Lizenz ohne dokumentierte Ausnahme als hochriskant eingestuft ist.

Bei klassifizierten Repositories muss der Scanner im luftgetrennten Modus gegen eine lokal gepflegte Komponentendatenbank arbeiten – cloudbasierte Lizenz-Lookup-APIs stehen in klassifizierten Netzen nicht zur Verfügung. Die lokale Datenbank muss im kontrollierten Wartungszyklus aktualisiert und versioniert werden, damit Scan-Ergebnisse reproduzierbar und prüfbar sind. Die Scanner-Ausgabe jeder Lieferung muss als Teil der technischen Basislinie des Programms archiviert werden, weil OSS-Offenlegungspflichten anhand der Komponenten der jeweiligen Lieferung bewertet werden und nicht am aktuellen Zustand des Codebestands.

OSS-Offenlegungspflichten

Wenn ein Verteidigungsvertrag die Lieferung eines SBOM (Software Bill of Materials) verlangt, speist sich die vom Lizenz-Scanner erzeugte OSS-Bestandsaufnahme direkt in die SBOM-Ausgabe. Das NTIA-Mindestelementformat und die SPDX-Spezifikation verlangen beide eine lizenzbezogene Kennzeichnung auf Komponentenebene, die der Scanner liefert. Das SBOM ist aber ein Offenlegungsdokument und kein Konformitätszertifikat – der Auftragnehmer muss zusätzlich sicherstellen, dass alle Copyleft-Offenlegungspflichten als eigener Schritt neben der SBOM-Erstellung erfüllt sind. Ein genaues SBOM, das eine GPL-Komponente aufführt, ohne den Quellcode offenzulegen, erfüllt die Transparenzanforderung, aber nicht die Lizenzpflicht.

Lizenzoptimierungsstrategien

Lizenzkonformität ist die Untergrenze. Lizenzoptimierung ist die Obergrenze – der systematische Aufwand, Lizenzkosten durch Vermeidung von Verschwendung zu senken, Berechtigungen effizienter umzuschichten und wo die technischen Anforderungen es zulassen, günstigere Alternativen zu substituieren. In Verteidigungsumgebungen mit großen, langlaufenden Programmen und langsamen Beschaffungszyklen summieren sich erhebliche Einsparungen aus Optimierungen, die in der Einzelprogrammbetrachtung nie sichtbar würden.

Rückführung ungenutzter Lizenzen

Lizenzrückführung ist der Prozess, Lizenzen einzuziehen, die Benutzern oder Systemen zugeordnet sind, die keine aktiven Verbraucher mehr sind. SAM-Werkzeuge, die die Nutzungshäufigkeit verfolgen – nicht nur die Installationszahl – identifizieren Lizenzen, die zugeordnet, aber in einem definierten Zeitraum (typischerweise 60 bis 90 Tage) nicht genutzt wurden. Diese Lizenzen sind Kandidaten für Rückführung und Umverteilung an aktive Benutzer, die sie benötigen. In großen Verteidigungsauftragnehmer-Umgebungen führen Rückführungsaktionen regelmäßig dazu, dass 15 bis 25 Prozent der bereitgestellten Arbeitsplatzlizenzen in den Produktivitäts- und Engineering-Werkzeugkategorien zurückgewonnen werden – eine materielle Kostenvermeidung bei der Verlängerung.

Lizenzfolgen der Virtualisierung

Virtualisierung schafft Lizenzoptimierungschancen und -risiken zugleich. Die Chance: Die Konsolidierung physischer Server senkt die physische Kernanzahl, auf die pro Kern abgerechnete Lizenzen anzuwenden sind, und kann so die Lizenzpflicht reduzieren. Das Risiko: Migrationsfunktionen virtueller Maschinen (Live-Migration, Hochverfügbarkeits-Cluster) können dazu führen, dass eine VM mit lizenzierter Software auf einen Host mit mehr physischen Kernen umzieht und die Lizenzpflicht ohne jedes menschliche Handeln steigt. Das Management dieses Risikos erfordert entweder VM-Migrationsrichtlinien, die die Bewegung auf vorlizenzierte Host-Pools beschränken, oder den Kauf ausreichender Lizenzen für die gesamte Migrationsdomäne – einen Ansatz, den Anbieter bevorzugen, weil er den Verwaltungsaufwand für Migrationsrichtlinien entfallen lässt.

Hybride Substitutionsanalyse kommerziell gegenüber Open Source

Bei nicht klassifizierten, nicht einsatzkritischen Werkzeugkategorien – Entwicklungsumgebungen, Dokumentationswerkzeuge, Projektverfolgungssysteme, Datenanalyseplattformen – erfüllen Open-Source-Alternativen zu kommerziellen Produkten die funktionalen Anforderungen häufig zu deutlich geringeren Kosten. Eine Substitutionsanalyse vergleicht die Gesamtbetriebskosten der aktuellen COTS-Lizenz (Lizenzgebühren, Unterstützungskosten, Schulungskosten, Integrationskosten) mit den Gesamtbetriebskosten einer OSS-Alternative (Implementierungskosten, Unterstützungvertrag falls erforderlich, Schulung, Integration). Die Analyse muss außerdem die Lizenzbedingungen der OSS-Alternative bewerten, um zu bestätigen, dass die Substitution keine neue Copyleft-Konformitätspflicht einführt.

Substitutionsentscheidungen in Verteidigungsumgebungen erfordern eine zusätzliche Sicherheitsbewertung: In klassifizierten Umgebungen eingesetzte OSS-Produkte müssen über das zutreffende Akkreditierungsverfahren für die Nutzung auf klassifizierten Systemen freigegeben werden, was dem Substitutionsprojekt Vorlaufzeit und Kosten hinzufügt, die der reine Lizenzkostenvergleich nicht abbildet.

Software-Escrow und Kontinuität

Software-Escrow ist ein Kontinuitätsmechanismus, der die Fähigkeit der Regierung – und des Auftragnehmers – schützt, kundenspezifische Software weiterzuwarten und zu ändern, wenn der ursprüngliche Entwickler sie nicht mehr unterstützen kann. Bei Verteidigungsprogrammen mit langen Einsatzlebenszyklen (15 bis 30 Jahre für viele Plattformprogramme) ist die Wahrscheinlichkeit nicht hoch, dass der ursprüngliche Softwareentwickler über die volle Programmlaufzeit verfügbar und bereit bleibt, die Software zu unterstützen. Escrow adressiert dieses Risiko, indem es den Zugriff auf Quellcode und Build-Materialien sicherstellt, sobald definierte Auslöser eintreten.

Escrow-Anforderungen für kundenspezifische Verteidigungssoftware

Verteidigungsverträge für kundenspezifische einsatzkritische Software enthalten zunehmend Escrow-Klauseln, die festlegen:

• den Escrow-Bevollmächtigten (einen benannten kommerziellen Escrow-Dienstleister, keine Regierungseinrichtung)
• den Hinterlegungsplan – typischerweise bei Auftragserteilung für die Ersthinterlegung, dann aktualisiert bei jedem Meilenstein einer größeren Version und danach jährlich
• die Anforderungen an den Hinterlegungsinhalt: Quellcode aller kundenspezifischen Komponenten, Build-Skripte, Spezifikationen der Drittanbieter-Abhängigkeiten, Dokumentation der Build-Umgebung (Compiler-Versionen, Versionen der Build-Werkzeuge, Konfigurationsdateien)
• Anforderungen an Verifikationstests – das Recht des Begünstigten, die Hinterlegung zu testen, um zu bestätigen, dass sie vollständig ist und sich bauen lässt
• Freigabe auslösende Ereignisse: Insolvenz des Anbieters, Einstellung der Software-Unterstützung, wesentliche Verletzung des Wartungsvertrags oder Vertragsverstoß des Auftragnehmers

Verifikationstests von Escrow-Hinterlegungen

Eine Escrow-Hinterlegung, die nie getestet wurde, ist ein Rechtsdokument und kein nutzbares Vermögensgut. Verifikationstests bestätigen, dass die hinterlegten Materialien vollständig sind und ausreichen, die Software ohne Rückgriff auf die internen Systeme des Entwicklers neu zu bauen. Ein aussagekräftiger Verifikationstest rekonstruiert die Build-Umgebung aus den hinterlegten Spezifikationen, installiert die hinterlegten Abhängigkeiten, führt die Build-Skripte gegen den hinterlegten Quellcode aus und führt eine funktionale Testsuite gegen das entstandene Build-Artefakt aus. Jede Lücke in der Hinterlegung – eine fehlende Abhängigkeit, eine undokumentierte Version eines Build-Werkzeugs, ein fest codierter Pfad auf ein internes System des Entwicklers – tritt bei Verifikationstests zutage und kann durch eine ergänzende Hinterlegung bereinigt werden, bevor Escrow in einem echten Kontinuitätsszenario gebraucht wird.

Freigabe auslösende Ereignisse

Die Escrow-Freigabe richtet sich nach den Auslöserdefinitionen in der Escrow-Vereinbarung und muss über ein formales Antragsverfahren eingeleitet werden. Die häufigsten Auslöser in Escrow-Vereinbarungen für Verteidigungssoftware sind Insolvenz des Anbieters (Insolvenzantrag oder Bestellung eines Verwalters), Übernahme des Anbieters durch einen Wettbewerber, der das Produkt einstellt, Einstellung der Wartungsunterstützung sowie wesentliche Verletzung des Software-Wartungsvertrags, die nach Ablauf der Ankündigungs- und Nachbesserungsfrist ungeheilt bleibt. Das Freigabeverfahren umfasst typischerweise eine schriftliche Mitteilung an den Escrow-Bevollmächtigten mit Benennung des Auslösers, eine Wartefrist, in der der Entwickler die Freigabe bestreiten kann, und eine neutrale Entscheidung, wenn die Freigabe strittig ist. Auftragnehmer sollten ihre Escrow-Vereinbarungen prüfen und sicherstellen, dass die Auslöserdefinitionen präzise genug sind, um ohne Rechtsstreit angerufen zu werden – vage Definitionen erzeugen Unklarheiten, die den Zugriff auf die hinterlegten Materialien genau dann verzögern, wenn Geschwindigkeit am wichtigsten ist.