Testsysteme richtig lizenzieren: Trennung von Produktion

Einleitung: Lizenzfallen im Alltag – warum Testsysteme so gefährlich sind

Testsysteme gelten in vielen Unternehmen als technische Nebensache – sie werden spontan aufgesetzt, mehrfach gespiegelt oder mit Originaldaten gefüttert, ohne dass jemand die Lizenzfolgen mitdenkt. Doch aus juristischer Sicht ist die Sache brisant: Viele Hersteller setzen in ihren Lizenzbedingungen klare Abgrenzungen zwischen Test-, Entwicklungs- und Produktivumgebungen voraus. Wer diese Grenzen missachtet oder unklar dokumentiert, riskiert im Audit schnell hohe Nachforderungen. Als Anwalt für Softwarelizenzrecht erlebe ich regelmäßig, wie solche Fälle zum Mandat werden – weil Unternehmen Testsysteme nicht ernst genug nehmen.

Testsystem, Sandbox oder Schattenproduktion? – Begriffsklärung vorab

Der Begriff „Testsystem“ ist kein fest umrissener rechtlicher Begriff – und genau das ist das Problem. In der Praxis fallen darunter:

• Technische Kopien produktiver Systeme zur Fehlerdiagnose
• Sandbox-Umgebungen für Release-Tests oder Updates
• Staging-Umgebungen mit identischer Datenstruktur
• Trainings-Instanzen, auf denen neue Mitarbeitende geschult werden
• Parallelbetrieb für Migrationszwecke

Alle diese Systeme können als „nicht-produktiv“ verstanden werden – müssen es aber nicht. Hersteller wie Microsoft, Oracle oder SAP interpretieren diese Abgrenzung regelmäßig zu ihren Gunsten – und das ist auditrelevant.

Lizenzrechtlicher Ausgangspunkt: Nutzung vs. Vervielfältigung

Juristisch ist klar: Bereits die Installation einer Software kann eine lizenzpflichtige Vervielfältigung darstellen (§ 69c Nr. 1 UrhG). Das gilt auch für Testsysteme, wenn:

• Die Software in lauffähiger Form vorliegt
• Zugriff durch Nutzer möglich ist
• Verarbeitung realer Daten erfolgt

Hersteller argumentieren regelmäßig: Wenn ein Testsystem die Funktion einer Live-Umgebung erfüllt, liegt eine produktive Nutzung vor. Entscheidend ist daher nicht die interne Bezeichnung, sondern die tatsächliche technische Struktur.

Herstellerpraxis: So bewerten Microsoft, SAP & Co. Testsysteme

Microsoft verlangt in vielen Lizenzprogrammen (z. B. Enterprise Agreements, SPLA, CSP) eine explizite Lizenz auch für Test- oder Staging-Systeme – es sei denn, es handelt sich um dedizierte „Developer Network“-Umgebungen (MSDN). Dabei muss jede VM, jeder Zugriff, jede parallele Instanz erfasst werden.

Oracle setzt auf besonders strenge Regelungen: Laut Oracle Licensing Policy ist jede Kopie, auch zu Testzwecken, lizenzpflichtig – unabhängig vom produktiven Charakter. In VM-Umgebungen gilt zusätzlich das sogenannte „Soft Partitioning“-Verbot, das bedeutet: Auch abgeschottete Testsysteme innerhalb eines Clusters können Lizenzbedarf auslösen.

SAP unterscheidet zwischen „Test & Development“ und „Productive Use“, verlangt aber in beiden Fällen eine Lizenz – sofern keine dedizierte Testlizenz im Vertrag vereinbart wurde. Die Abgrenzung erfolgt dort über Nutzerrollen, Funktionsumfang und Datenstruktur.

Typische Irrtümer: So entstehen verdeckte Lizenzpflichten

1. „Wir haben das System nur intern gespiegelt“

Ein beliebter Irrtum. Unternehmen spiegeln ihre Produktivsysteme 1:1 für Tests oder Migrationszwecke – inklusive Datenbank, Konfiguration und Benutzerkonten. Wird dieses System produktiv erreichbar gemacht oder mit realen Geschäftsdaten befüllt, sehen Hersteller darin eine lizenzpflichtige Zweitinstallation.

2. „Testsysteme brauchen keine Nutzerlizenzen“

Viele denken: Solange kein produktiver Mitarbeiter aktiv mit dem System arbeitet, ist keine Lizenz notwendig. Falsch. Schon der systemseitige Zugriff eines technischen Dienstleisters oder der Start eines Servers kann lizenzrelevant sein – insbesondere bei Device- oder Core-basierten Modellen.

3. „Die Systeme waren nie produktiv geschaltet“

Auch inaktive oder zeitweise abgeschaltete Testumgebungen können lizenzrelevant sein – z. B. wenn ein Snapshot aktiv war, ein Scheduler gelaufen ist oder Zugriffspfade bestehen. Audittools wie der Microsoft Assessment and Planning Toolkit erkennen diese Konfigurationen.

4. „Wir haben das nur für Schulungszwecke genutzt“

Auch Schulungssysteme gelten bei vielen Herstellern als voll lizenzpflichtig – es sei denn, im Vertrag steht ausdrücklich etwas anderes (z. B. EDU-Lizenz, Not-for-Resale).

Trennung von Produktion und Testsystem: So muss sie aussehen

Rechtssicher ist nur, was technisch, vertraglich und organisatorisch klar abgrenzbar ist. Dazu gehören:

• Separate Netzwerksegmente mit Firewalls, VLANs oder Subnetzen
• Gespiegelte Systeme ohne Echtzeitdaten oder produktiven Zugriff
• Technische Zugriffsbeschränkungen (User, Device, IP, Zeitfenster)
• Lizenzmarkierungen in Asset-Management-Systemen
• Verträge mit expliziten Klauseln zur Nutzung für Testzwecke

Besonders wichtig ist die Nachvollziehbarkeit im Auditfall: Ein Unternehmen muss beweisen können, dass das betreffende System nicht produktiv genutzt wurde. Je näher das System an der Produktionsumgebung liegt (z. B. bei Failover- oder Redundanzsystemen), desto höher die Anforderungen an Trennung und Dokumentation.

So dokumentieren Sie Testsysteme auditfest

1. Systembeschreibung pro Instanz: Wofür ist das System vorgesehen, wie wird es technisch abgegrenzt?
2. Nutzerverzeichnis: Wer hatte Zugriff, mit welcher Berechtigung?
3. Logfiles und Nutzungsberichte: Wie oft wurde das System gestartet, genutzt oder verändert?
4. Vertragsdokumente: Enthält der Lizenzvertrag eine explizite Regelung zu Testumgebungen?
5. Asset-Vermerk: Im Lizenzinventar sollte das System als „non-productive“ markiert sein.

Wer diese Informationen nicht vorlegen kann, riskiert, dass das Testsystem rückwirkend als „produktive Nutzung“ bewertet wird – mit Lizenzpflicht für Software, Add-Ons und Datenbankkomponenten.

Strategien für die Lizenzierung von Testumgebungen

A) Vertraglich definierte Testnutzung aushandeln

Viele Hersteller bieten separate „Not for Resale“- oder „Test and Evaluation“-Lizenzen an. Diese müssen jedoch aktiv vereinbart und getrennt dokumentiert werden. Ohne Vertragsregelung gilt das Standardmodell – also volle Lizenzpflicht.

B) Entwicklerplattformen nutzen

Bei Microsoft können Unternehmen über das Visual Studio Subscription mit MSDN dedizierte Test- und Entwicklungsrechte erhalten – allerdings nur im Rahmen der dort zugelassenen Szenarien. Diese Option wird oft übersehen.

C) Dedizierte Schulungssysteme lizensieren

Einige Hersteller bieten separate EDU- oder Schulungslizenzen an – meist günstiger, aber funktional eingeschränkt. Ideal für HR, Onboarding und Technikschulungen – sofern nicht mit Produktivdaten gearbeitet wird.

D) Virtualisierung strategisch nutzen

Durch Virtualisierung lassen sich physische Installationen minimieren – aber Achtung: Lizenzmetriken gelten häufig pro VM, nicht pro Host. Testsysteme müssen daher auch in virtuellen Strukturen korrekt benannt, zugeordnet und lizenziert werden.

Besondere Risikozonen: Schatten-IT und agile Teams

Testsysteme entstehen oft spontan – etwa in agilen Projekten, bei Cloud-basierten Prototypen oder durch eigenmächtige IT-Admins. Genau hier liegt die größte Gefahr: Lizenzmanagement greift nicht, Compliance ist lückenhaft, und Auditbeweise fehlen.

Besonders kritisch:

• Cloud-Tests auf AWS, Azure oder Google Cloud ohne zentrale Steuerung
• SaaS-Testaccounts, die später in Produktivumgebungen überführt werden
• „Hackathons“ oder interne Innovation Days mit produktiv lizenzierter Software

Unternehmen müssen Richtlinien schaffen, wie und wo Testsysteme aufgebaut werden dürfen – und wer dafür verantwortlich ist.

Fazit & Call-to-Action

Testsysteme sind kein lizenzfreier Raum. Wer nicht zwischen Produktion und Simulation unterscheidet – oder dies nicht nachweisen kann – riskiert Vertragsverstöße, Nachzahlungen und sogar Rückabwicklungen von Auditvereinbarungen. Die korrekte Trennung ist nicht nur technisch, sondern auch juristisch zwingend notwendig.

Ich unterstütze Sie als Anwalt dabei, Ihre Lizenzstruktur zu analysieren, testbezogene Risiken zu identifizieren und rechtssicher aufzustellen – bevor das Audit kommt.

👉 Jetzt unverbindlich Beratung sichern: hortmannlaw.com/contact

• Lizenzmetriken verstehen: User-, Device- und Core-Modelle
• Unterlizenzierung erkennen und vermeiden
• Installation vs. Nutzung: Wann greift das Lizenzrecht?
• Lizenzketten im Unternehmen richtig managen
• Überlizenzierung: Wie Sie unnötige Kosten vermeiden
• EULA-Konflikte: Risiken in Lizenzbedingungen
• Software-Compliance-Scan: Was geprüft wird – und warum
• Software-Inventarisierung und Lizenzprüfung
• Schatten-IT: Lizenzverstöße durch unerlaubte Software-Nutzung
• Softwarelizenzrecht, Audits & Verteidigung: Grundlagen
• Microsoft-Lizenzaudit: Verteidigung & Strategien
• Open-Source-Lizenzen verstehen: Mit GPL, Copyleft & Unternehmensfehlern umgehen

‍