Multiplexing in der Softwarelizenzierung: Was Sie wissen müssen

Dieser Beitrag erklärt Multiplexing in der Softwarelizenzierung. Wer eine Zwischenschicht wie Middleware, Portal oder Serviceaccount vor ein lizenziertes System stellt, spart keine Lizenzen, weil Microsoft, Oracle und SAP die Menschen am vorderen Ende der Kette zählen, nicht die technischen Verbindungen. Er zeigt die konkreten Regeln der drei Hersteller mit ihren dokumentierten Beispielen und Lücken, ordnet den Fall SAP gegen Diageo ein und leitet daraus praktische Konsequenzen für Architektur, Dokumentation und Wahl der Lizenzmetrik ab.

Microsoft definiert Multiplexing in seiner Lizenzierungs-Guidance als “jede Methode (zum Beispiel Hardware, Software oder Automatisierung), die eingesetzt wird, um Verbindungen zu bündeln oder die Anzahl der Betriebssystemumgebungen, Geräte oder Nutzer zu reduzieren, die ein Produkt direkt verwaltet” (Microsoft Licensing Guidance: Multiplexing). Microsoft stellt dort ausdrücklich klar: Multiplexing reduziert die Zahl der benötigten Lizenzen nicht.

Das Muster ist bei Multiplexing immer dasselbe. Zwischen dem Endanwender und dem lizenzierten System steht eine Schicht: ein Webserver, ein Integrationsbus, ein Reporting-Tool, ein Connection Pool, ein Serviceaccount. Aus Sicht des lizenzierten Systems greift genau ein technischer Nutzer zu. Aus Sicht des Herstellers greifen 4.000 Menschen zu.

Wichtig ist die Richtung der Argumentation: Der Hersteller interessiert sich nicht dafür, wie viele Verbindungen technisch aufgebaut werden. Er interessiert sich dafür, wie viele Menschen und Geräte am Ende einen Nutzen aus den Daten ziehen. Alles dazwischen ist Implementierungsdetail.

Verwandte Begriffe: Indirekte Nutzung, indirect access, indirect use, Digital Access (SAP), Multiplexing-Klausel, Frontend-Zählung.

Die betriebswirtschaftliche Logik hinter der Multiplexing-Klausel ist nicht böswillig, sondern schlicht: Nutzerbasierte Lizenzmodelle koppeln den Preis an den geschäftlichen Wert. Ein ERP-System, aus dem 4.000 Vertriebsmitarbeiter arbeiten, ist mehr wert als eines mit 40 Nutzern – unabhängig davon, über welchen technischen Weg die 4.000 zugreifen.

Ohne Multiplexing-Klausel wäre jedes nutzerbasierte Lizenzmodell trivial umgehbar. Man stellt einen Reverse Proxy davor, lizenziert einen Nutzer und ist fertig. Genau das verhindert die Klausel – und genau deshalb steht sie seit Jahrzehnten weitgehend unverändert in den Verträgen.

Microsoft unterscheidet feiner als Oracle und zieht eine Linie, die in der Praxis oft übersehen wird: zwischen automatisierter und manueller Weitergabe von Daten.

Automatisiert weitergegebene Daten sind CAL-pflichtig. Microsoft schreibt: “Any device/user that accesses or deploys files, content, and data that is made available in an automated way (for example, directly from a server or automatically posted to a server) requires a CAL.”
Manuell weitergegebene Daten sind es nicht. “If files, data, or content are available because of a manual activity (a person uploading a file onto a server or emailing the file), a CAL is not required for users or devices accessing those manually transmitted files.”

Konkret: Ein automatisch generierter und verteilter Report ist lizenzpflichtig. Derselbe Report, den ein Sachbearbeiter morgens händisch per Mail verschickt, ist es nicht. Das ist eine dünne Linie, aber sie ist real und wird in Microsoft-Audits auch so angewendet. Quelle: Microsoft Licensing Guidance: Multiplexing.

Die vertragliche Grundlage steht in Microsofts Universal License Terms: Jede Methode, mit der ein Kunde Verbindungen bündelt, die Zahl direkt oder indirekt zugreifender Nutzer reduziert “or access data a Product itself processes or generates”, reduziert die Zahl der benötigten Lizenzen nicht (Microsoft Product Terms). Für die Cloud-Produkte formuliert es der Power Platform Licensing Guide genauso: “Any user or device that inputs data into, queries, views data from or otherwise accesses Power Apps, Power Automate and Power Pages apps, directly or indirectly must be properly licensed” (Power Platform Licensing Guide).

Die folgenden Fälle hat Microsoft in seiner Multiplexing-Guidance und den Lizenzleitfäden durchgerechnet:

Drei Punkte aus dieser Tabelle sind in der Praxis teuer. Erstens: Nicht die Automatisierung löst die Lizenzpflicht aus, sondern der Kontakt weiterer Menschen mit der Zwischenschicht – reines Ansehen genügt. Microsoft formuliert dazu: “Since the colleagues are accessing Power Platform, they require an appropriate Power Platform license.”

Zweitens: Zusätzliche Abstraktionsebenen helfen nicht. “The number of tiers of hardware or software between Power Platform apps and the users or devices that ultimately use Power Platform indirectly does not affect the number of User SLs required.” Als häufigste Erscheinungsform nennt Microsoft das Connection Pooling.

Drittens: Eine eigene Power App vor Dynamics 365 senkt die Kosten nur, wenn sie ausschließlich auf unrestricted Tables zugreift. Berührt sie restricted Tables, bleibt die Dynamics-365-Lizenz fällig – die App ist dann eine reine Oberfläche ohne Lizenzeffekt. An dieser Stelle verlieren viele Power-Platform-Projekte ihre kalkulierte Ersparnis.

Die Lücken gehören zur Antwort: Für Windows Server nennt Microsoft nur die Grundregel – “Each user or device that accesses licensed servers requires a Windows Server CAL (Base CAL)” – und verweist für indirekten Zugriff auf den Multiplexing-Brief, ohne eigene Szenarien (Windows Server 2025 Licensing Guidance). Für Exchange Server, SharePoint, Active Directory und Microsoft 365 E3/E5 gibt es gar keine durchgerechneten Beispiele. Gerade bei Windows Server wird die CAL-Pflicht bei indirektem Zugriff in Audits trotzdem regelmäßig geltend gemacht – wer hier eine belastbare Position braucht, sollte die Auslegung schriftlich klären lassen.

Oracle formuliert die Multiplexing-Regel am knappsten. In den Oracle License Definitions and Rules heißt es zum Named-User-Plus-Modell wörtlich:

“If multiplexing hardware or software (e.g., a TP monitor or a web server product) is used, this number must be measured at the multiplexing front end.”

Gezählt wird bei Oracle also am Frontend, nicht an der Datenbank. Wer eine Oracle-Datenbank hinter eine Webanwendung stellt, lizenziert die Anwendungsnutzer – nicht die Datenbankverbindungen. In der Praxis ist das der Hauptgrund, warum Kunden bei öffentlich zugänglichen Anwendungen auf die Processor-Metrik wechseln: Named User Plus ist bei unbekannter Nutzerzahl schlicht nicht berechenbar.

SAP hatte historisch das größte Problem mit indirekter Nutzung, weil das klassische Named-User-Modell auf indirekte Zugriffe schlecht passt. Seit 2018 gibt es deshalb das dokumentenbasierte Modell SAP Digital Access.

Statt Nutzer zu zählen, zählt SAP dabei die Erzeugung von Dokumenten in neun definierten Kategorien: Verkaufs-, Einkaufs-, Rechnungs-, Fertigungs-, Material-, Qualitäts-, Service-, Finanz- und Zeitwirtschaftsdokumente. Gezählt wird nur die initiale Dokumenterzeugung durch ein Drittsystem; Lesezugriffe, Änderungen und automatisch erzeugte Folgedokumente bleiben außen vor. Verschiedene Dokumenttypen gehen mit unterschiedlichen Faktoren in die Rechnung ein.

Digital Access ist konzeptionell ehrlicher als der Versuch, Menschen hinter einer Schnittstelle zu zählen. Es verlagert das Risiko allerdings: Ein hochfrequenter IoT- oder E-Commerce-Datenstrom erzeugt Dokumentvolumen, das linear mit dem Geschäft wächst – und damit auch die Lizenzkosten.

Hinweis: Die Faktoren und Kategorien von SAP Digital Access sind vertragsabhängig und wurden seit Einführung mehrfach angepasst. Maßgeblich ist der jeweils gültige SAP-Preis- und Konditionenkatalog, nicht die allgemeine Beschreibung.

Im Februar 2017 entschied der englische High Court (Technology and Construction Court) in SAP UK Ltd v Diageo Great Britain Ltd, [2017] EWHC 189 (TCC), unter Richterin O’Farrell.

Der Sachverhalt: Diageo hatte zwei Salesforce-basierte Systeme – “Connect” für Kunden und “Gen2” für den Außendienst – über SAP PI an das mySAP-ERP angebunden. Die Endnutzer arbeiteten in Salesforce, nicht in SAP. Diageo argumentierte, die lizenzierte PI-Schnittstelle sei quasi ein Gatekeeper: Was dahinter passiert, sei abgedeckt.

Das Gericht folgte dem nicht. Entscheidend war die Definition der “Named Users” im Vertrag: Personen, die autorisiert sind, die Software “directly or indirectly” zu nutzen oder darauf zuzugreifen. Weil die Anmeldung der Nutzer in Salesforce Nachrichten und Daten über SAP PI an das mySAP-ERP auslöste, lag ein indirekter Zugriff vor – und damit ein Verstoß gegen die Lizenzbedingungen. SAP hatte 54.503.578 Pfund an Zusatzgebühren beziehungsweise Schadensersatz gefordert.

Wichtig für die Einordnung: Das Urteil entschied nur über die Haftung. Die Höhe des Betrags blieb offen und wurde einer späteren Entscheidung vorbehalten; der Fall wurde anschließend außergerichtlich beigelegt.

Parallel forderte SAP von Anheuser-Busch InBev rund 600 Millionen US-Dollar wegen direkter und indirekter Nutzung. Auch dieser Streit wurde außergerichtlich beigelegt, die tatsächlich gezahlte Summe wurde nie veröffentlicht.

Die Lehre aus beiden Fällen ist nicht “SAP ist gefährlich”. Sie ist: Die Vertragsklausel schlägt die Architekturannahme. Was technisch sauber gekapselt aussieht, ist lizenzrechtlich transparent.

Multiplexing entsteht praktisch nie durch eine bewusste Entscheidung. Typische Auslöser in Unternehmensarchitekturen:

Der eine Serviceaccount. Eine Anwendung verbindet sich mit einem technischen User zur Datenbank. Klassiker, sauber implementiert, lizenzrechtlich das Lehrbuchbeispiel für Multiplexing.
BI- und Reporting-Layer. Ein Data Warehouse zieht nachts Daten aus dem ERP, hunderte Nutzer arbeiten im Dashboard. Ob das lizenzpflichtig ist, hängt davon ab, wie granular und aktuell die Daten sind – aggregierte Kennzahlen werden anders bewertet als durchgereichte Einzelsätze.
Kunden- und Lieferantenportale. Externe Nutzer, die Bestellungen auslösen, sind aus Herstellersicht Nutzer des Backends.
RPA und Automatisierung. Ein Bot, der stellvertretend für 200 Sachbearbeiter Buchungen anlegt, ersetzt keine 200 Lizenzen.
IoT und Maschinendaten. Sensordaten, die automatisch Belege erzeugen, sind bei dokumentenbasierten Modellen wie SAP Digital Access direkt kostenrelevant.
KI-Agenten. Der aktuell offenste Punkt. Ein Agent, der im Namen eines Mitarbeiters im ERP arbeitet, ist lizenzrechtlich vermutlich dieser Mitarbeiter. Ein Agent, der autonom Vorgänge anlegt, ist etwas Neues – und die Vertragswerke sind hier noch nicht ausdefiniert. Wer heute Agenten in Kernsysteme integriert, sollte diesen Punkt aktiv im Vertrag klären, statt auf eine Auslegung zu hoffen.

Drei praktische Konsequenzen aus dem Thema Multiplexing.

Erstens: Multiplexing gehört in die Architekturbewertung, nicht in die Vertragsverhandlung. Wenn die Integration steht und produktiv läuft, ist die Verhandlungsposition denkbar schlecht. Die Frage “wer sind am Ende die menschlichen Nutzer dieser Daten?” kostet im Design fünf Minuten und später sechsstellige Beträge.

Zweitens: Dokumentieren Sie die Nutzerkette. In einem Lizenzaudit müssen Sie erklären können, wer über welchen Weg auf welche Daten zugreift. Wer das nicht kann, verhandelt gegen die Schätzung des Herstellers – und die fällt selten konservativ aus.

Drittens: Prüfen Sie die Metrik, nicht nur den Preis. Bei unbekannter oder stark wachsender Nutzerzahl sind kapazitätsbasierte Modelle (Processor, Core, Subscription) oft nicht teurer, aber deutlich berechenbarer. Der Wechsel der Metrik ist häufig die wirksamere Maßnahme als das Nachkaufen von Nutzern.

Multiplexing ist kein Schlupfloch, das man schließen muss. Es ist die Stelle, an der Lizenzverträge sichtbar machen, dass sie Geschäftswert bepreisen und nicht Technik. Wer das im Entwurf mitdenkt, hat später keine Diskussion. Wer es ignoriert, führt sie irgendwann – nur eben mit dem Auditor.

Was ist Multiplexing in der Softwarelizenzierung?
Multiplexing ist der Einsatz von Hardware, Software oder Automatisierung, um Verbindungen zu bündeln und so die Zahl der Nutzer oder Geräte zu reduzieren, die ein lizenziertes Produkt direkt verwaltet. Lizenzrechtlich reduziert das den Lizenzbedarf nicht – gezählt wird am vorderen Ende der Kette.

Ist indirekte Nutzung immer lizenzpflichtig?
In der Regel ja, wenn Menschen oder Geräte über eine Zwischenschicht Nutzen aus den Daten des lizenzierten Systems ziehen. Ausnahmen gibt es bei Microsoft für manuell weitergegebene Daten. Maßgeblich ist immer der konkrete Vertrag.

Brauchen Nutzer eine Power-Apps-Lizenz, wenn sie nur lesend zugreifen?
Ja. Microsoft stuft auch das reine Ansehen von Daten in der Power Platform als Multiplexing ein. Wer die Oberfläche öffnet, braucht eine Lizenz – unabhängig davon, ob er etwas verändert.

Senkt eine eigene Power App vor Dynamics 365 die Lizenzkosten?
Nur eingeschränkt. Greift die App auf unrestricted Tables zu, genügt eine Power-Apps- oder Power-Automate-Lizenz. Berührt sie restricted Tables, brauchen die Nutzer weiterhin eine Dynamics-365-Lizenz.

Für welche Microsoft-Produkte gibt es dokumentierte Multiplexing-Beispiele?
Durchgerechnete Beispiele veröffentlicht Microsoft für SQL Server, Project Server, Azure DevOps Server sowie Dynamics 365 und die Power Platform. Für Windows Server nennt Microsoft nur die allgemeine CAL-Regel, für Exchange Server, SharePoint, Active Directory und Microsoft 365 E3/E5 gar keine Szenarien – dort greift allein die Klausel der Universal License Terms.

Reduziert ein Serviceaccount die Anzahl benötigter Lizenzen?
Nein. Ein technischer Serviceaccount, über den eine Anwendung auf ein lizenziertes System zugreift, ist das Lehrbuchbeispiel für Multiplexing. Lizenziert werden die Endanwender der vorgelagerten Anwendung.

Gilt Multiplexing auch für KI-Agenten?
Das ist derzeit nicht abschließend geregelt. Ein Agent, der im Auftrag eines benannten Mitarbeiters arbeitet, wird lizenzrechtlich in der Regel diesem Mitarbeiter zugerechnet. Für autonom agierende Agenten fehlen in den meisten Vertragswerken noch klare Regeln – dieser Punkt sollte vertraglich ausdrücklich geklärt werden.

Wie hoch war die Forderung im Fall SAP gegen Diageo?
SAP forderte 54.503.578 Pfund an zusätzlichen Lizenzgebühren beziehungsweise Schadensersatz. Das Urteil von 2017 entschied nur über die Haftung; die Höhe blieb offen, der Fall wurde später außergerichtlich beigelegt.

Wie schützt man sich vor Multiplexing-Nachforderungen?
Durch drei Maßnahmen: Multiplexing bereits im Architekturentwurf bewerten, die vollständige Nutzerkette dokumentieren und bei unbekannter Nutzerzahl auf kapazitätsbasierte Metriken statt nutzerbasierter Modelle wechseln.

• Microsoft Licensing Guidance: Multiplexing
• Microsoft Product Terms: Universal License Terms For all Software
• Windows Server 2025 Licensing Guidance
• Power Platform Licensing Guide (PDF)
• Oracle License Definitions and Rules (PDF)
• SAP UK Ltd v Diageo Great Britain Ltd [2017] EWHC 189 (TCC), BAILII
• SAP v Diageo: Slicing the Salami – Fallbesprechung
• AB InBev settles out of court in $600m SAP licensing dispute, Computer Weekly