Anhang Preis Lizenzstruktur CAFM IT-Dienstleistungsvertrag

• Nach Nutzerzahl – hier kommen Konzepte wie Named User vs. Concurrent User ins Spiel, sowie Skaleneffekte bei vielen Nutzern.

• Nach Modulen/Funktionsbereichen – CAFM-Systeme sind modular aufgebaut, das Lizenzmodell kann pro Modul gestaltet sein, inklusive Bündelungsoptionen.

• Nach Speicherbedarf/verbrauchter Ressourcen – insbesondere bei Cloud-Modellen relevant, wo Datenmengen oder Transaktionen die Gebühren beeinflussen können.

• Named-User-Lizenzierung: Jeder Benutzer, der die Software nutzen soll, benötigt eine persönliche, namentlich zugewiesene Lizenz. Nur dieser bestimmte Benutzer darf die Software verwenden. Die Anzahl gleichzeitiger Zugriffe spielt keine Rolle; entscheidend ist, wie viele individuelle Nutzer berechtigt sind. Dieses Modell ist einfach zu verstehen: Für z.B. 50 Mitarbeiter mit Zugang benötigt man 50 Named-User-Lizenzen. Es eignet sich, wenn alle Nutzer regelmäßig Zugriff haben oder regulatorisch ein personalisiertes Nutzungsrecht nötig ist. Nachteilig ist, dass auch inaktiver oder selten nutzender Mitarbeiter einen vollen Lizenzplatz blockiert – es gibt also mögliche Ineffizienzen, wenn Nutzerkreis und tatsächliche Nutzung auseinanderfallen.

• Concurrent-User-Lizenzierung: Hier wird nicht pro namentlichem Nutzer lizenziert, sondern nach der maximal gleichzeitigen Nutzung. Es dürfen also insgesamt mehr Personen einen Account haben, aber nur eine bestimmte Anzahl zugleich darf aktiv sein. Die Software kann beispielsweise auf beliebig vielen Rechnern installiert sein, und ein Lizenzserver kontrolliert die parallelen Zugriffe. Beispiel: 50 mögliche Nutzer im Unternehmen, aber es sind nur 20 Concurrent-Lizenzen gekauft – dann können maximal 20 zur selben Zeit die Anwendung benutzen, ein 21. muss warten bis jemand ausloggt. Dieses Modell wird auch Floating License oder Netzwerklizenz genannt. Es ist effizient, wenn erfahrungsgemäß nie alle Nutzer gleichzeitig online sind (z.B. Schichtbetrieb, verschiedene Zeitfenster). Allerdings kann es zu Wartezeiten kommen, falls das Limit erreicht wird, und die Verwaltung via Lizenzserver ist etwas aufwändiger.

In Verträgen muss eindeutig festgelegt sein, welches Modell gilt. Oft wird auch eine Kombination gewählt: z.B. Named User für Kernanwender und konkurrierende (concurrent) Lizenzen für einen Pool seltener Nutzer. Wichtig ist, wie zusätzliche Nutzer abgerechnet werden: Ein Vertrag könnte Staffelpreise vorsehen, z.B. „1–10 Named User: Preis X pro User; 11–50: Preis Y pro User (Rabattstaffel)“. Skaleneffekte bedeuten, dass der Stückpreis je Lizenz sinkt bei größeren Volumina, um dem Kunden Mengenrabatte zu gewähren. In der Praxis sind Mengenrabatte üblich – etwa 10% ab 25 Lizenzen, 20% ab 50 Lizenzen etc., wie manche Preislisten zeigen. Diese Staffelung gehört in den Preisanhang, entweder als Tabelle oder als Formel.

• Skaleneffekte: Gerade bei CAFM-Systemen kann der Nutzerkreis von ein paar Admins bis zu hunderten Mitarbeitern (z.B. Techniker, die Tickets pflegen) reichen. Eine gestaffelte Preisstruktur soll sicherstellen, dass große Kunden nicht prohibitiv viel zahlen. Zum anderen kalkuliert der Anbieter so, dass Fixkosten gedeckt sind und ab einer bestimmten Nutzerzahl sinkende Margen noch akzeptabel sind. Aus Kundensicht sollte auf Transparenz der Rabattstaffeln geachtet werden – sie müssen so im Vertrag stehen, damit bei z.B. Erweiterung von 20 auf 30 Nutzer automatisch der neue (günstigere) Einheitspreis gilt.

• Vergleich der Modelle: Named-User-Modelle sind vorteilhaft, wenn Nutzungsintensität pro User hoch ist und man genau weiß, wer die Software verwendet – die Kosten sind linear mit der Nutzeranzahl. Concurrent-Modelle sind effizienter, wenn viele gelegentliche User da sind, da man „Überlizenzierung“ vermeidet. Allerdings verlangen einige Hersteller für Concurrent-Lizenzen einen höheren Einzelpreis (da eine Concurrent-Lizenz faktisch mehreren Personen Zugriff gewähren kann). So kann es sein, dass z.B. 1 Concurrent License ≈ Kosten von 1,5 Named Licenses. Die Vertragskonditionen müssen hier genau geprüft werden. In öffentlichen Ausschreibungen wird oft das Lizenzmodell vorgegeben oder zumindest erfragt, um Angebote vergleichbar zu machen.

• Darüber hinaus gibt es Sonderformen: Enterprise-Lizenzmodelle (unbegrenzte Nutzer innerhalb einer Organisation gegen Pauschalpreis) – bei sehr großen Unternehmen manchmal sinnvoll. Oder gleichzeitig angemeldete Geräte statt Nutzer (manche Software zählt Sessions). Für unsere Zwecke bleiben aber Named vs. Concurrent als wichtigste Unterscheidung.

• Vertraglich sollte im Preisanhang eine klare Definition stehen, z.B.: „Lizenzmodell: 100 Named User“ oder „Lizenzmodell: 50 gleichzeitige Benutzer (Concurrent User)“. Zudem die Referenzgröße: Bei Concurrent muss oft ein Lizenzmanager oder Monitoring am Server vorhanden sein – der Vertrag könnte festlegen, wie Nachlizenzierung erfolgt, falls das Limit überschritten wird (z.B. automatische Sperre vs. Nachberechnung von Übernutzung). Bei Named User sollte geregelt sein, ob Lizenzen übertragbar sind auf andere Personen (z.B. wenn ein Mitarbeiter ausscheidet, darf die Lizenz neu vergeben werden – üblich ja, aber manchmal beschränkt auf X Umlizenzierungen pro Jahr). All diese Details gewährleisten, dass das Preismodell langfristig handhabbar bleibt.

CAFM-Software ist typischerweise modular aufgebaut. Es gibt verschiedene Funktionsbereiche (Module) wie z.B. Flächenmanagement, Instandhaltungsmanagement, Reinigungsmanagement, Buchungsverwaltung, Energiemanagement, Vertragsverwaltung, etc. Nicht jeder Kunde benötigt alle Module – daher werden Lizenzmodelle nach Modulen angeboten. Dies bedeutet, der Kunde lizenziert (und bezahlt) nur die Funktionalität, die er tatsächlich einsetzt.

CAFM-Software ist typischerweise modular aufgebaut. Es gibt verschiedene Funktionsbereiche (Module) wie z.B. Flächenmanagement, Instandhaltungsmanagement, Reinigungsmanagement, Buchungsverwaltung, Energiemanagement, Vertragsverwaltung, etc. Nicht jeder Kunde benötigt alle Module – daher werden Lizenzmodelle nach Modulen angeboten. Dies bedeutet, der Kunde lizenziert (und bezahlt) nur die Funktionalität, die er tatsächlich einsetzt.

• Funktionslogik moderner CAFM-Systeme: Die Module spiegeln die fachlichen Bereiche im Facility Management wider. Moderne Systeme sind oft plattformbasiert: Es gibt ein Kernsystem (Basis-Modul) und darauf aufbauend zahlreiche optionale Module. Jedes Modul kann eigenständig Funktionen liefern, ist aber oft mit anderen verzahnt. Beispielsweise kann das Wartungsmanagement-Modul nur sinnvoll genutzt werden, wenn zumindest ein Stammdaten-Modul (für Anlagen und Räume) vorhanden ist; das Raumbuch-Modul hängt ggf. vom CAD-Modul ab, wenn es Zeichnungsintegration braucht. Diese Interdependenzen bedeuten, dass Module selten völlig isoliert lizenziert werden können – meist braucht man ein Basismodul und kann dann bestimmte Erweiterungsmodule wählen. Im Vertrag sollte daher genau stehen, welche Module in der Lizenz enthalten sind. Eine Liste der Module mit Namen und Versionsnummer gehört in den Anhang (oft als „Lizenzschein“ oder Produktauflistung). Damit wird klargestellt, welche Funktionen der Kunde erworben hat.

• Lizenzbündelung: Anbieter schnüren häufig Pakete oder Bundles aus mehreren Modulen, oft zu einem Vorteilspreis im Vergleich zum Einzelkauf. Zum Beispiel ein „Basis-Paket FM“ könnte Module A, B, C enthalten. Das hat zwei Effekte: Erstens erleichtert es den Verkauf (man verkauft eine Lösung für einen Anwendungsfall komplett), zweitens kann es Quersubventionierungen geben (wenig genutzte Module werden mit stark nachgefragten gebündelt). Aus Kundensicht muss man aufpassen, dass man nicht für unnötige Module mitzahlt. Umgekehrt können Bündel günstiger sein als alle Module einzeln zu lizenzieren. Im Vertragsanhang sollte eindeutig sein, ob der Preis pro Modul angegeben ist oder ob ein Gesamtpaketpreis für eine Modulkombination vereinbart wurde. Beispiel: „Modul Flächenmanagement: 10.000 € (Kauflizenz) bzw. 300 €/Monat (Miete); Modul Instandhaltung: 15.000 € bzw. 450 €/Monat; Bundle Flächen+Instandhaltung: 20.000 € bzw. 600 €/Monat“. So eine Darstellung ermöglicht es, optional Module hinzuzunehmen oder wegzulassen, auch in öffentlichen Ausschreibungen. Die Bündelung kann auch dazu dienen, Abhängigkeiten abzusichern: Der Anbieter könnte etwa rabattieren, wenn der Kunde mehrere Module nimmt, aber wenn der Kunde später eines kündigt, verfällt der Bundle-Rabatt. Solche Rabattbedingungen sollten ebenfalls dokumentiert sein.

• Interdependenzen und Wechselwirkungen: Wie erwähnt, können Module technisch aufeinander angewiesen sein. Vertraglich sollte man festhalten, dass der Kunde bestimmte Module als Voraussetzung haben muss, sonst erlischt der Support ggf. (z.B. „Lizenz X setzt Modul Y voraus“). Wenn der Kunde Module eigenmächtig deaktiviert, könnte dies als Vertragsänderung gelten. Im Preisgefüge kann eine skalierende Logik auch modulübergreifend wirken: Beispiel – Nutzerstaffel pro Modul. Vielleicht lizenziert man 50 Nutzer für Modul A, aber nur 10 davon benötigen auch Modul B, sodass Modul B nur für 10 Named User lizenziert wird. Das lässt sich staffeltechnisch verzahnen. Ein klarer Preisanhang würde z.B. zwei Dimensionen kombinieren: Zeilen = Module, Spalten = Preis pro Benutzer

So eine Tabelle zeigt, dass sich der Gesamtpreis nach der Anzahl der lizenzierten Nutzer und der gewählten Module berechnet (für Kauf plus Wartung oder Miete). Öffentliche Auftraggeber fragen oft solche Matrizen ab, um die Gesamtkosten bei unterschiedlicher Nutzer- und Modulkombination zu evaluieren.

• Lizenzmodelle moderner CAFM-Anbieter: In der Praxis bieten einige Hersteller heute „All-in-one“-Lizenzen an, d.h. alle Module für alle Nutzer für einen pauschalen Preis (oft bei SaaS). Andere bleiben bei modularem Pricing. In jedem Fall muss der Vertrag exakt definieren, was der Kunde nutzen darf. Dazu gehört auch, ob Module hinzugebucht werden können und zu welchem Preis (oft über Change Requests oder Nachträge dann entsprechend der Preisliste).

• Vertragsklauseln zu Modulen: Man findet manchmal Klauseln, dass der Kunde nicht genutzte Module stilllegen kann, aber ein Wieder-Aktivieren kostet wieder Gebühr. Oder dass Module versionsabhängig sind – z.B. bei einem Major-Upgrade können Module zusammengelegt oder neu aufgeteilt werden, was zu Anpassungen im Lizenzportfolio führt. Der Vertrag sollte regeln, wie in solchen Fällen verfahren wird (insbes. relevant bei SaaS, wo der Anbieter einseitig Module ändern könnte – idealerweise darf das nicht zu höheren Kosten ohne Zustimmung führen).

• Zusammengefasst: Die Preisstaffel nach Modulen ermöglicht granulare Funktionalitätskontrolle. Im Anhang sollte eine Auflistung aller lizenzierten Module mit Einzelpreisen stehen. Das erhöht auch die Transparenzpflicht : öffentliche Auftraggeber müssen oft detailliert begründen, welche Leistung zu welchen Kosten beschafft wurde. Die modulare Darstellung hilft dabei. Außerdem sollte jede Module-Lizenz auch inhaltlich kurz benannt sein, damit klar ist, welche Funktion gemeint ist (eine Referenz auf ein Leistungsbeschreibungs-Dokument ist sinnvoll, wo Module genau beschrieben sind).

Mit zunehmender Cloud-Nutzung gewinnt die verbrauchsabhängige Bepreisung von IT-Ressourcen an Bedeutung. Neben Nutzer- und Modulanzahl kann daher auch der Speicherbedarf oder ähnliche Ressourcen als Bemessungsgrundlage dienen. Insbesondere, wenn der Anbieter das System hostet, ist der Storageverbrauch ein relevanter Kostenfaktor – große Datenmengen belegen viel Speicherplatz, erfordern ggf. mehr Backup-Kapazität usw.

• Ressourcenmodellierung im Vertrag: Darunter versteht man, dass der Vertrag bestimmte Ressourcenkontingente festlegt, etwa Speicher, CPU, Arbeitsspeicher, die dem Kunden zustehen. Häufig wird im SaaS-Vertrag mindestens der Speicher limitiert oder in Paketen angeboten. Beispielsweise: „Im Grundpreis sind 50 GB Datenspeicher inkludiert; jeder weitere angefangene GB wird monatlich mit 0,20 € berechnet.“ So eine Klausel macht die Kosten transparent. Einige Verträge definieren auch Benutzerklassen mit Datenvolumen (z.B. ein power user darf X GB, ein normal user Y GB).

• Cloud-Architektur und Speicher: Bei Multi-Tenant-Clouds (viele Kunden teilen die Infrastruktur) wird das Volumen pro Kunde oft per soft limit geregelt – geht er darüber, wird aufgestockt (gegen Aufpreis). Bei Single-Tenant (dedizierte Instanz für Kunde) könnte man statt Speicher eine pauschale Infrastrukturgröße vereinbaren (z.B. VM mit 8 CPU, 16 GB RAM, 200 GB Disk, Preis X). D.h. die Architekturwahl (Multi vs. Single Tenant, dedizierte DB, etc.) hat Einfluss auf den Preis: Dedizierte Ressourcen sind teurer. Der Vertrag sollte festhalten, welche Architektur zugrunde liegt. In öffentlichen Vergaben wird manchmal gefordert: „Dedizierte Datenbank-Instanz, mindestens 500 GB initial, erweiterbar in 100-GB-Schritten“ – und der Anbieter macht dazu Preisangaben.

• Verbrauchsorientierung: Ein verbrauchsbasiertes Preismodell (Pay-per-use) ist flexibel, erfordert aber genaue Messung und Abrechnung. Der Vertrag sollte klar regeln, wie gemessen wird (z.B. monatliche Snapshot-Messung des belegten Speichers oder Durchschnitt). Ebenso die Abrechnungsperiode (monatl., quartalsweise). Für Cloud-Services sind auch andere Metriken denkbar: z.B. Zahl der Transaktionen (Ticketbuchungen, IoT-Sensor-Datenpunkte, generierte Berichte, API-Calls). Speicher ist aber greifbar und oft Proxy für Systemgröße.

• Anreize und strategische Überlegungen: Durch Speicher- oder Nutzungsabhängige Kosten entstehen Anreize, Daten zu bereinigen oder nicht unnötig lange vorzuhalten (Archivierung). Aus IT-Management-Sicht sollte man hier einen Spagat beachten: Einerseits will man alle FM-Daten historisch vorhalten (Pflichten, Nachweise etc.), andererseits könnte es kostenmäßig attraktiv sein, z.B. ältere Daten offline zu archivieren. Vertraglich könnte daher vorgesehen sein, dass der Kunde regelmäßig Daten löschen/archivieren darf und ggf. der Anbieter dafür Unterstützung bietet (Service, evtl. zu extra Kosten). Diese Governance-Aspekte sollte ein FM-Leiter kennen.

• Beispiel einer Speicherpreisstaffel: Oft werden Staffelpreise pro GB mit abnehmendem Preis bei großem Volumen vereinbart. Z.B.: 0–100 GB = 0,30 €/GB; 100–500 GB = 0,20 €/GB; >500 GB = 0,15 €/GB (alle pro Monat). So steigt die Rechnung linear, aber der Grenzpreis sinkt, was große Kunden entlastet. Solche Preise mögen in einem technischen Appendix oder in der Leistungsbeschreibung stehen.

• Vertragsrelevanz: Die Staffelung nach Speicher ist vor allem in SaaS-Verträgen relevant. In On-Premises-Szenarien trägt der Kunde seine Speicherhardware selbst, da taucht dies nicht als Vertragsposten auf (allenfalls in Form von Systemanforderungen). Bei SaaS jedoch gehört die Speichergrenze zum Serviceumfang. Daher gehört sie streng genommen auch ins SLA: Etwa „Performance garantiert bis 100 GB, darüber hinaus ggf. Performanceeinbußen oder Notwendigkeit, auf nächstgrößeres Paket zu wechseln“. Preislich sollte der Vertrag definieren, was passiert, wenn Limits überschritten werden: automatische Berechnung der Übermenge oder vorherige Abstimmung?

• Cloud-Kosten und IT-Sicherheit (Bezug herstellen): Eine interessante Facette: Wenn der Kunde aus Sicherheitsgründen viel länger Daten aufbewahren muss (Compliance), kann das den Speicherbedarf treiben. Oder wenn viele Dokumente (z.B. gescannte Wartungsnachweise) in hoher Auflösung hochgeladen werden, steigt Speicher. In der Planung muss man diese Verbrauchsfaktoren berücksichtigen.

Kurzum, in einem umfassenden Vertragsanhang sollte nach Möglichkeit jede preisrelevante Dimension abgebildet sein

• Nutzeranzahl,

• Module,

• Speicher/Verbrauch ,

• sowie ggf. weitere wie Standortanzahl, Concurrent Sessions etc., falls relevant.

Dadurch entsteht eine mehrdimensionale Preisformel, die aber idealerweise in tabellarischer Form verständlich aufbereitet wird. Das erhöht nicht nur die Klarheit, sondern ist auch vergaberechtlich oft Bedingung: öffentliche Auftraggeber wollen keine „Black Box“-Kosten, sondern nachvollziehbare Preise je Einheit (Unit Price), um Nachbestellungen oder Reduktionen fair handhaben zu können.

n diesem Abschnitt vergleichen wir die klassischen Lizenzmodelle – Kauf, Miete (Subscription) und SaaS – hinsichtlich ihrer juristischen und betriebswirtschaftlichen Implikationen. Dabei liegt der Fokus auf dem Gegensatz Eigentum vs. Nutzungsrecht sowie auf Misch- und Hybridmodellen, die in der Praxis auftreten (Kombinationen, Cross-Licensing, Vendor-Lock-in-Fallen und Exit-Strategien).

• Kauflizenz (On-Premises, unbefristet): Wie schon ausgeführt, erwirbt der Kunde hier ein dauerhaftes Nutzungsrecht gegen einmaliges Entgelt. Juristisch ist dies dem Eigentum nahe: Der Kunde ist wirtschaftlicher Eigentümer der Softwarekopie, darf sie zeitlich unbegrenzt nutzen und sogar weiterverkaufen (sofern es sich um Standardsoftware handelt und er seine eigene Nutzung einstellt, gemäß Urteilslage EuGH). Er trägt dafür aber auch das volle Risiko, dass die Software künftig technisch überholt oder unzureichend ist. Im Kaufmodell liegt die Verfügungsgewalt über Software und Daten beim Kunden: Er kann entscheiden, wann Updates eingespielt werden (solange er Wartung hat) und hostet die Software selbst (oder auf eigenen Wunsch bei einem Dienstleister). Rechtlich relevant: die Sachmängelhaftung gilt zum Zeitpunkt der Übergabe, nach Gewährleistungsablauf hat der Kunde ohne Wartungsvertrag keinen Anspruch auf Mängelbeseitigung. Er hat aber Besitz an einer Version der Software, die er prinzipiell ewig betreiben kann (theoretisch sogar weiter nutzen, ohne Wartung – praktisch begrenzt durch OS-Kompatibilität etc.). Diese Kontrolle ist Teil des Eigentumsvorteils. Aus Nutzerperspektive wird oft geschätzt, dass keine Verpflichtung zu künftigen Zahlungen besteht – Wartung ist freiwillig kündbar, man könnte z.B. aufhören zu zahlen und einfach mit der alten Version leben.

• Mietlizenz (Subscription, On-Premises oder ausgelagert): Hier erwirbt der Kunde kein dauerhaftes Recht, sondern ein Nutzungsrecht auf Zeit. Dieses ist an fortlaufende Zahlungen gebunden. Juristisch ist das ein Mietvertrag (bei Standardsoftware) oder unter Umständen ein sogenannter Leih- oder Leasingvertrag (der Begriff Softwareleasing wurde erwähnt, wo feste Raten über bestimmte Zeit vereinbart sind – dies ähnelt Miete, aber mit fester Laufzeit). Dem Kunden steht nur ein Gebrauch während der Vertragsdauer zu; ein Eigentum erwirbt er nicht. Konsequenzen: Der Anbieter hat während der Mietdauer die Pflicht, die Software funktionsfähig zu halten (kontinuierliche Gewährleistung), und der Kunde hat ein ordentliches Kündigungsrecht nach Ablauf von Mindestfristen. Aus Sicht des Kunden wird oft angeführt, dass Subscription „immer die neueste Version“ bedeutet – tatsächlich beinhalten Mietverträge in der Regel Upgrades automatisch (Nutzungsrecht bezieht sich immer auf die aktuelle Version). Steuerlich wie erwähnt, keine Aktivierung, sondern Aufwand. Wichtig: Wird die Zahlung eingestellt oder der Vertrag gekündigt, erlischt das Nutzungsrecht vollständig – der Kunde kann die Software dann nicht weiterverwenden. Es gibt also kein „Restwert“ oder Weiterverkaufsrecht. Viele Mietverträge untersagen auch die Abtretung an Dritte (was bei Miete zulässig ist, anders als beim Kauf: dort greift das Erschöpfungsprinzip, aber bei Miete kann vertraglich eine Unterlizenzierung oder Überlassung an Dritte verboten werden). Das Mietmodell kann On-Premises gestaltet sein (z.B. zeitlich befristeter Lizenzschlüssel, der regelmäßig verlängert wird bei Zahlung) oder es kann deckungsgleich mit dem SaaS-Modell sein, wenn Software in der Cloud gemietet wird. Juristisch wäre auch SaaS oft als Mietmodell qualifiziert, aber mit zusätzlichen Dienstleistungselementen.

• SaaS (Software as a Service, Cloud): SaaS ist streng genommen eine Unterform der Miete, jedoch mit dem Unterschied, dass die Software nicht beim Kunden installiert wird, sondern als Service über das Internet bereitgestellt wird. Juristisch wird SaaS häufig als Mietvertrag mit dienstvertraglichen Elementen gesehen. Denn der Anbieter überlässt dem Kunden die Nutzung seiner Software (Mietaspekt) und schuldet gleichzeitig laufende Betriebsleistungen wie Hosting, Wartung, Support (Dienstleistungsaspekt). Der Kunde erhält ein zeitlich beschränktes Nutzungsrecht genau wie bei Miete, jedoch ohne physischen Besitz einer Softwarekopie. Er „mietet“ funktionale Ergebnisse (z.B. FM-Funktionen via Webportal). Aus rechtlicher Bewertung: Der Kunde erwirbt keinerlei Eigentum oder Rechte an der Software selbst, lediglich vertragsgemäße Nutzungsrechte. Daher muss im SaaS-Vertrag sehr klar geregelt sein, welche Daten dem Kunden gehören (in aller Regel alle vom Kunden eingegebenen Daten bleiben Eigentum des Kunden) und was passiert bei Vertragsende (Datenrückgabe, siehe Exit-Strategie unten). Der SaaS-Anbieter behält typischerweise alle IP-Rechte an der Software; dem Kunden wird oft nicht mal eine Software übergeben, er kriegt nur Zugang. Daher werden SaaS-Verträge oft dem Dienstvertragsrecht nähergeordnet, weil kein dauerhafter Softwareliefergegenstand vorhanden ist. Die juristische Konsequenz: Schadensersatz bei Schlechtleistung richtet sich eher nach Dienstvertragsgrundsätzen (nur bei Verschulden), während bei Miete strengere Haftung für Mängel gelten kann.

• Eigentum vs. Nutzungsrecht zusammengefasst: Nur die Kauflizenz verschafft dem Kunden so etwas wie „dauerhaftes Eigentum am Nutzungsexemplar“. Mietmodelle und SaaS nur ein temporäres Nutzungsrecht. Dementsprechend liegen die Risiken verteilt: Beim Kauf trägt der Kunde nach Übergabe praktisch alle Risiken (außer Produkthaftung/Sachmängel anfänglich), bei SaaS trägt der Anbieter permanent eine Mitverantwortung, weil er die Leistung fortlaufend erbringen muss. Das spiegelt sich in vertraglichen Haftungs- und Gewährleistungsklauseln: Kaufverträge haben nach Abnahme/Warenübergabe begrenzte Haftung (Gewährleistung befristet), SaaS-Verträge haben während der ganzen Laufzeit Pflichten (z.B. Verfügbarkeit als Beschaffenheit, deren Unterschreiten einen Mangel darstellt, der auch nach 2 Jahren noch geltend gemacht werden kann, solange Vertrag läuft).

• Wirtschaftlich: Kunden müssen entscheiden, ob sie lieber CapEx (Kauf) oder OpEx (Miete/SaaS) einsetzen. Kauf bedeutet größere Investition heute, dafür eventuell niedrigere laufende Kosten; SaaS verteilt die Kosten, ermöglicht stets aktuelle Technologie, aber es gibt kein Ende der Zahlungen, solange man die Software nutzen will. Aus Anbietersicht: SaaS generiert kontinuierliche planbare Umsätze, während Verkäufe einmalige Peaks sind. Daher drängen viele Hersteller in Richtung SaaS/Abo. Für Kunden kann SaaS Vorteile bringen (Reduktion interner IT-Aufwände, stets aktuell, auslagern von Verantwortlichkeiten), aber die Abhängigkeit vom Anbieter ist größer – ein zentrales Kriterium, auf das wir jetzt eingehen.

• Hybridmodelle (On-Prem + Cloud): Ein Kunde könnte z.B. eine Kauflizenz erwerben, diese aber nicht selbst hosten, sondern vom Hersteller in der Cloud betreiben lassen (sogenanntes Managed Hosting). Das ist eine Mischung: Lizenz-Kaufvertrag + separater Betriebsvertrag. Einige Hersteller bieten an, bestehende Kauflizenzen in ein SaaS-Modell zu überführen (Konvertierung). Vertraglich muss dann geregelt werden, ob der Kunde im Tausch z.B. Rabatte auf SaaS bekommt, oder ob er seine Kauf-Lizenz „ruhen“ lässt. Auch hybride Betriebsmodelle sind denkbar: kritische Module on-premise, weniger kritische als Cloud-Service, mit Integration zwischen beiden – dann hat man ebenfalls Mischverträge. Für solche Modelle sind Cross-Licensing-Vereinbarungen manchmal nötig, wenn z.B. verschiedene Komponenten von verschiedenen Anbietern lizenziert werden müssen (z.B. CAFM-Kern vom Anbieter A, spezialisierte Ergänzung vom Anbieter B, aber B’s Software läuft integriert bei A). In solchen Fällen sollte im Vertrag geklärt sein, wer für welche Lizenz konditioniert ist und ob der Hauptanbieter Sub-Lizenzen dritter Komponenten erteilt (oft gibt es Abschnitt „Drittlizenzen“ im Vertrag, die Fremdsoftware regeln).

• Vendor Lock-in: Damit bezeichnet man die Situation, dass der Kunde sich durch Vertrag/Lizenzmodell so an den Anbieter bindet, dass ein Wechsel schwer oder teuer ist. Klassisch erhöht sich das Lock-in bei steigenden Datenmengen (wenn all Ihre FM-Daten in einer proprietären Cloud liegen, wird der Wechsel weh tun), bei starkem Customizing (kundenspezifische Anpassungen, die man beim neuen System verlieren würde), oder bei Vertragskonstruktionen, die Wechsel erschweren (z.B. langfristige Laufzeiten, Strafzahlungen bei vorzeitiger Kündigung). SaaS wird oft eine höhere Lock-in-Wirkung zugeschrieben, weil alle Prozesse auf den Anbieter zugeschnitten sind und Daten physisch bei ihm liegen. Der Vertrag sollte daher Exit-Klauseln vorsehen (siehe unten). Ein weiteres Lock-in-Element können proprietäre Schnittstellen sein: Wenn der Anbieter z.B. proprietäre Module hat (z.B. eigenes CAD-Format), hängt man an diesem Ökosystem. Cross-Licensing könnte hier bedeuten: Anbieter lizenziert dem Kunde z.B. eine Runtime-Version einer CAD-Engine von Drittanbieter – der Kunde kann diese Lizenz aber nur im Kontext des CAFM nutzen, nicht separat. Das schränkt die Portabilität ein. Im Vergabekontext wird Vendor Lock-in kritisch gesehen, öffentliche Auftraggeber versuchen oft, durch Standardformate und Datenherausgabeklauseln die Abhängigkeit zu mildern.

• Exit-Strategien: Ein guter Vertrag, insbesondere im öffentlichen Sektor, enthält Regelungen für das Vertragsende und den Umstieg auf eine andere Lösung. Dazu gehören: Datenrückgabe in definiertem Format (z.B. „Der Anbieter liefert alle gespeicherten Daten in einem gängigen maschinenlesbaren Format innerhalb 30 Tage nach Vertragsende aus.“), Mithilfe bei Migration (ggf. als optionale Dienstleistung zu vereinbarten Tagessätzen), Weiternutzungsklauseln: Falls z.B. SaaS abrupt endet (Insolvenz Anbieter), darf der Kunde eine letzte Datenkopie behalten und aus dieser lesen? Manchmal werden Escrow-Vereinbarungen getroffen – bei Kauf mehr als bei SaaS: Bei Kauf kann Source Code Escrow vereinbart sein, damit der Kunde im Falle der Anbieter-Pleite Zugang zum Quellcode bekommt und das System selbst weiter pflegen könnte. Bei reinem SaaS geht das nicht so leicht, da auch Infrastruktur & Know-how nötig wären; aber man könnte regeln, dass bei Anbieter-Insolvenz der Betrieb vom Treuhänder noch X Monate weitergeführt wird. Exit-Strategie betrifft auch Restlaufzeit: Was, wenn der Kunde kündigt, aber er hat noch 6 Monate bezahlt – bekommt er Geld zurück oder Service bis zum Ende? Bei Mietverträgen meist: keine Erstattung, Service bis Ende. Bei Kauf: keine Relevanz, man behält Lizenz.

• Beispiel für Hybrid: Einige Verträge erlauben, zwischen On-Premise und SaaS zu wechseln. SAP bspw. hatte Modelle, wo man bestehende Lizenzen gegen Cloud-Subskriptionen „tauschen“ konnte (RISE with SAP). Solche Cross-Licensing-Deals sind komplex und gehen meist über individuelle Vertragszusätze. Der Schlüssel aus Kundensicht ist, sich Flexibilität zu bewahren: Möglichst nicht doppelt zahlen beim Wechsel der Modellform. Ein verhandelbarer Punkt kann sein: „Wenn wir innerhalb der ersten 2 Jahre von Miet- auf Kauflizenz wechseln wollen, werden bereits gezahlte Mieten zu X% auf den Kaufpreis angerechnet.“ – So eine Klausel adressiert Unsicherheit, was das beste Modell ist.

• Juristische Mischung: Es kommt vor, dass Großverträge als Mischvertrag konstruiert sind mit Elementen von Kauf, Miete und Dienstvertrag. Beispielsweise: Kauf der Grundsoftware, Miete für Add-ons, plus Dienstvertrag für Support. Juristisch gelten dann alle einschlägigen Regelungen nebeneinander. Im Streitfall würde man den Schwerpunkt bestimmen oder jeden Teil separat betrachten. Daher ist es empfehlenswert, im Vertrag eine Präambel zu formulieren, die den Vertragszweck umreißt (IHK-Empfehlung), und ggf. festzuhalten „Für die Überlassung der Softwaremodule X, Y als Kauflizenzen gelten die Regelungen des Kaufrechts (§§ 433 BGB ff) entsprechend; für die zeitlich befristete Überlassung von Modul Z gelten Mietrecht (§§ 535 BGB ff); für die Erbringung von Customizing und Support gelten Werk- bzw. Dienstvertragsrecht (§ 631 bzw. § 611 BGB)“. Eine solche Klarstellung hilft im Zweifel.

• Beispiel Vendor-Lock-in und Daten: Der Handwerk.com-Artikel zitiert: „Den größten Nachteil von SaaS-Software sieht Werner in der Abhängigkeit vom Anbieter... Was passiert mit meinen Daten, wenn der Hersteller seinen Betrieb einstellt? Bei lokal installierten Anwendungen liegen die Daten auf der eigenen Festplatte. Bei SaaS häufig in irgendeinem Rechenzentrum.“. Dieses Zitat bringt es auf den Punkt: Im Exit-Fall muss für SaaS die Datenhoheit sichergestellt sein. Der Vertrag sollte also verpflichten, dass der Anbieter die Daten herausgibt in definiertem Format, und zwar vollständig. Evtl. auch, dass er Daten auf Wunsch zwischendurch in lesbarer Form bereitstellt (zur Kontr

Es müssen hybride Modelle sauber vertraglich abgebildet sein. Cross-Licensing-Aspekte (mehrere Hersteller, oder OEM-Teile in der Software) sollten in einem Anhang „Drittsoftware-Lizenzen“ mit aufgeführt werden, damit Lizenzauflagen Dritter (z.B. für eingebettete Geodaten, Karten, CAD-Viewer) auch dem Kunden bekannt sind. Vendor-Lock-in kann man vertraglich nie komplett ausschließen, aber durch Transparenz und Exit-Klauseln abmildern. Öffentliche Auftraggeber achten beispielsweise darauf, dass Verträge zeitlich befristet ausgeschrieben werden und dann neu tenderbar sind – damit man nicht für immer festhängt. Im privatwirtschaftlichen Bereich kann ein Unternehmen sich bewusst auf einen Vendor Lock-in einlassen, solange vertraglich genügend Schutzmechanismen vorhanden sind (z.B. Preisdeckelungen in der Zukunft, garantiertes Daten-Exportrecht, eventuelle Quellcode-Hinterlegung). Ein Stichwort ist auch „perpetual rights“ in Cloud: Manche Kunden verhandeln, dass sie im Falle einer Kündigung zumindest eine lesende On-Prem-Version der zuletzt genutzten Software erhalten, um weiter auf ihre Daten zugreifen zu können (auch ohne neue Eingaben). Ob Anbieter dem zustimmen, ist eine Frage der Marktmacht.

Abschließend richten wir den Blick auf einige allgemeine Vertragsklauseln, die speziell bei IT-Dienstleistungsverträgen mit Lizenzkomponenten von großer Bedeutung sind. Dazu zählen Mindestlaufzeiten und Kündigungsregelungen, Preisanpassungsmechanismen (Indexierung), die Übertragbarkeit von Verträgen/Lizenzen sowie – insbesondere bei öffentlichen Auftraggebern – die Transparenzpflichten im Vergabeverfahren. Diese Rahmenbedingungen bilden gewissermaßen den juristischen und kommerziellen Überbau des Vertrags und tragen wesentlich zur Risikoallokation bei.

• Mindestlaufzeit: Viele Softwareverträge – insbesondere Miet- und Cloud-Verträge – sehen eine Mindestvertragslaufzeit vor. Üblich sind 12 Monate, 24 Monate oder auch mehrjährige Bindungen, je nach Geschäftsmodell. Der Grund aus Anbietersicht: Die Anfangskosten (Onboarding, Rabatte) sollen sich für den Anbieter amortisieren, weshalb ein zu schneller Ausstieg des Kunden verhindert werden soll. Aus Kundensicht möchte man wiederum nicht ewig gebunden sein, falls die Leistung nicht zufriedenstellt. Daher resultieren Kompromisse: Oft sind 1 Jahr Mindestlaufzeit Standard, mit Verlängerungsklauseln. Im Vertrag sollte klipp und klar stehen: „Dieser Vertrag läuft zunächst bis zum DD.MM.YYYY (Mindestlaufzeit von X Monaten) und verlängert sich danach jeweils um 1 Jahr, sofern er nicht mit einer Frist von Y Monaten zum Laufzeitende gekündigt wird.“ Für die Lizensituation bedeutet das, dass auch die Lizenznutzung befristet ist – bei SaaS sowieso. Bei Kauf + Wartung gilt: Die Lizenz selbst ist unbefristet, aber der Wartungsvertrag kann eine Mindestlaufzeit haben (z.B. erste 12 Monate obligatorisch). Öffentliche Auftraggeber sind oft vorsichtig mit zu langen Mindestlaufzeiten, da sie haushaltsrechtlich selten länger als 4 Jahre Verträge abschließen dürfen ohne Neuausschreibung (in EU-Vergaben sind >4 Jahre Laufzeit ausnahmsbedürftig). Deshalb sieht man in öffentlichen CAFM-Verträgen häufig max. 4 Jahre + Verlängerungsoption.

• Kündigungsregelungen: Hier ist zu unterscheiden: Ordentliche Kündigung und außerordentliche (wichtiger Grund). Ordentliches Kündigungsrecht wird meist zum Ablauf der (Mindest-)Laufzeit eingeräumt mit bestimmter Frist (z.B. 3 Monate vorher). Bei Mietverträgen, die sich auf unbestimmte Zeit verlängert haben, gilt im B2B zwar nicht automatisch das BGB-Kündigungsrecht (§ 542 BGB, Machte bei Softwaremiete analog anwendbar?), aber es wird üblicherweise vertraglich fixiert. Außerordentliche Kündigung sollte im Vertrag für bestimmte Fälle definiert sein: z.B. wiederholte SLA-Verletzungen, schwerer Mangel, Insolvenz des Anbieters, Verletzung von Datenschutzregeln, etc. Insbesondere öffentliche Kunden verlangen außerordentliches Kündigungsrecht, falls z.B. Haushaltsmittel wegfallen (Kündigung aus wichtigem Grund „Wegfall der Geschäftsgrundlage“). Bei Kaufverträgen ist eine Kündigung eigentlich kein Thema, da es ein einmaliger Akt ist – hier kann höchstens ein Rücktrittsrecht bei Nichterfüllung relevant sein. Bei Dienstleistungsverträgen (Implementierung) gilt § 648 BGB (jederzeitiges Kündigungsrecht des Bestellers gegen Vergütung der bis dahin erbrachten Leistung). In Softwareprojekten wird dieses Recht manchmal vertraglich modifiziert, aber es ist ein gesetzliches Auffangnetz.

• Vertragsbeendigung und Folgen: Der Vertrag sollte regeln, was bei Vertragsende passiert. Relevant hier: Rückgabe oder Vernichtung von Kopien (bei On-Prem: Kunde muss evtl. alle Softwarekopien vernichten bei Mietende; bei Kauf hingegen darf er sie behalten, aber wenn Wartung endet, darf er nur keine Updates mehr nutzen). Bei SaaS: Abschaltung des Zugangs am Enddatum, aber mit Möglichkeit, Daten zu exportieren (oft wird eine Nachlaufzeit vereinbart, z.B. Zugang read-only für 30 Tage, um Daten zu ziehen). Auch Kündigungsfristen für Teilkündigungen könnten relevant sein: z.B. kann der Kunde bestimmte Module oder Nutzer reduzieren? Meist erlaubt der Vertrag das nur zum Gesamtvertragsende oder im Rahmen von vertraglich festgelegten Reduktionsrechten (z.B. „Nach 1 Jahr darf der Kunde bis zu 10% der Lizenzen zurückgeben“ – eher selten, aber denkbar). Umgekehrt achten Anbieter darauf, dass bei On-Prem-Kauf der Wartungsvertrag synchron mit Lizenzen läuft – oft steht drin, dass eine Teilkündigung der Wartung (für einige Lizenzen) unzulässig ist (all or nothing).

• Rolle der Vergabe/Kündigung: Im öffentlichen Bereich kann auch die vorzeitige Kündigung aus Vergabegründen relevant sein – etwa wenn der Vertrag verlängert werden soll, muss man prüfen, ob das vergaberechtskonform ist (Verlängerungsoptionen müssen im ursprünglichen Verfahren vorgesehen sein). Im Vertragstext spiegelt sich das in sauber formulierten Laufzeit- und Kündigungsklauseln.

• Beispielklausel ordentliche Kündigung (Mietvertrag): „Nach Ablauf der initialen Festlaufzeit kann der Vertrag von jeder Partei mit einer Frist von 3 Monaten zum Ende eines Vertragsjahres schriftlich gekündigt werden.“ – Das gibt Planungssicherheit für beide.

• Außerordentliche Kündigung (wichtiger Grund): Hier sollten einige Punkte explizit genannt sein: z.B. Vertragsverletzungen (wesentliche Pflichten werden verletzt trotz Fristsetzung), Insolvenz (Eröffnung eines Insolvenzverfahrens berechtigt zur Kündigung oft, zumindest den Kunden, falls er Datenverlust fürchtet), Verstoß gegen Geheimhaltung oder Datenschutz, etc. Der Anbieter könnte für sich außerordentliches Kündigungsrecht vorsehen bei z.B. Zahlungsverzug des Kunden (üblich: wenn Kunde trotz Mahnung und Frist weiterhin nicht zahlt, darf Anbieter den Vertrag kündigen und Dienst abschalten).

• Lizenzkündigung bei Vertragsbruch: In manchen Lizenzverträgen steht: Bei Verstoß gegen Lizenzbedingungen (z.B. unbefugte Weitergabe, Überschreiten Nutzerzahl ohne Lizenz) kann der Anbieter den Lizenzvertrag kündigen (entziehen). Das ist heikel, weil beim Kauf erlöschen Lizenzen nicht ohne weiteres – aber vertraglich kann man ein Vertragsstrafe- oder Kündigungsrecht definieren bei schwerem Verstoß (z.B. Piraterie). Bei Mietsoftware kann der Anbieter natürlich bei Vertragsbruch Zugänge sperren, was quasi einer Kündigung gleichkommt.

• Fazit: Laufzeit und Kündigung regeln Flexibilität vs. Bindung. Aus Kundensicht wünscht man kurze Bindung, aus Anbietersicht lange. Der Vertragsanhang selbst enthält dazu meist keine Zahlen, außer eventuell Enddatum oder Verlängerungsoption. Aber im Hauptvertrag stehen diese Klauseln. Dennoch müssen sie in Einklang mit der Preisstruktur im Anhang sein (z.B. wenn Preisstaffeln für 5 Jahre kalkuliert sind, sollte der Vertrag nicht nach 1 Jahr gekündigt werden können ohne Folgekosten – sonst würde Anbieter Verlust machen).

Bei Verträgen mit öffentlichen Auftraggebern gelten besondere Transparenz- und Wettbewerbsgebote. § 97 Abs.1 GWB verlangt ein transparentes Vergabeverfahren. Für unseren Kontext relevant ist vor allem: Alle preisrelevanten Aspekte der Leistung müssen klar und vollständig in den Vergabeunterlagen (und damit später im Vertrag) beschrieben sein. Intransparente oder nachträglich variable Preisgestaltung kann nicht akzeptiert werden, da sonst der Wettbewerb verzerrt würde.

• Transparenzgebot in der Preisstruktur: In der Ausschreibung muss der öffentliche Auftraggeber z.B. angeben, wie die Angebote preislich vergleichbar gemacht werden. Das führt dazu, dass Bieter eine Preisstruktur liefern müssen, die alle geforderten Leistungen abdeckt. Im Vertragsanhang wird dann oft das vom Bieter ausgefüllte Preisblatt übernommen. Dieses enthält die aufgeschlüsselten Preise (siehe vorherige Abschnitte: getrennt nach Lizenzkosten, Wartung, Dienstleistungen, optionalen Posten etc.). Eine unvollständige Auflistung könnte später als Vergabeverstoß gewertet werden, wenn z.B. Leistungen abgerufen werden, die nicht vorher bepreist waren (Stichwort: keine nachträglichen Vergütungsansprüche ohne im Vertrag vorgesehen zu sein). Ein Beispiel aus der Vergaberechtsprechung: Unklare Angaben zu Mehrvergütungsansprüchen wurden von einer Vergabekammer als Verstoß gegen das Transparenzgebot gewertet, da Bieter nicht wussten, wie sie kalkulieren sollen. Übertragen heißt das: Wenn im Vertrag in einem Absatz steht "Änderungen werden zusätzlich nach Aufwand vergütet", an anderer Stelle aber "Mehrvergütung ist ausgeschlossen", entsteht ein Widerspruch – solcher Mangel an Klarheit führt zur Unwirksamkeit/Aufhebung des Vergabeverfahrens. Daher ist es extrem wichtig, dass der endgültige Vertrag (insb. Preis- und Leistungsanhänge) widerspruchsfrei und eindeutig ist.

• Herausforderung der Vollständigkeit: Im Facility Management und IT können während der Nutzung weitere Bedarfe auftauchen (z.B. zusätzliche Module, mehr Nutzer, Änderungen). Öffentliche Auftraggeber versuchen, diese soweit möglich im Vorfeld zu antizipieren und im Vertrag zu regeln, um später nicht gegen Vergaberecht zu verstoßen, wenn sie mehr kaufen. Beispielsweise könnten im Vertrag Optionen formuliert sein: „Der Auftraggeber kann bis zu 20 weitere Named User zum selben Stückpreis hinzukaufen“ oder „weitere Module laut Preisliste des Angebots können bis Vertragsende abgerufen werden“. Solche Optionen machen das späteres Hinzukaufen transparent, ohne erneute Ausschreibung. Das Vergaberecht erlaubt bestimmte Vertragsänderungen nach Zuschlag nur, wenn sie von vornherein angelegt waren oder unter klar definierte Ausnahmetatbestände fallen (siehe § 132 GWB). Daher sollte im Vertrag ein Preisgerüst für Erweiterungen enthalten sein. Fehlt das und der Kunde kauft später ad hoc mehr, könnte ein unterlegener Bieter rügen, man habe einen verdeckten Mehrauftrag außerhalb des Wettbewerbs vergeben.

• Indexierung und Preisänderungen (siehe 5.3) sind ebenfalls im Vergabeumfeld kritisch: Sie müssen genau beschrieben sein. Die VgV verlangt in § 29, dass Auftragsänderungen und Preisänderungsklauseln transparent und eindeutig sein müssen (z.B. eine klare Indexformel). Unklare Klauseln (z.B. „Preise können bei gestiegenen Kosten einvernehmlich angepasst werden“) genügen dem Transparenzgebot nicht, weil Bieter nicht wissen, wie konkurrenzfähig ihr Angebot über die Laufzeit ist.

• Dokumentations- und Bekanntmachungspflichten: Die Transparenzpflicht erstreckt sich auch darauf, dass z.B. Bewertungskriterien für die Wirtschaftlichkeit offen gelegt werden. Das tangiert unseren Bereich, wenn z.B. verschiedene Preismodelle angeboten werden konnten – der AG muss dann transparent machen, wie er die Kosten über x Jahre vergleicht. Nach Zuschlag kommt diese Thematik ins Vertragsmanagement: Der Vertrag sollte so ausgestaltet sein, dass keine Überraschungen auftreten, die man nicht veröffentlicht hatte.

• Praxisbeispiel CAFM-Vergabe: In Ausschreibungen für CAFM verlangen Auftraggeber oft einen ausgefüllten Kostenplan, der genau die Themen abdeckt: Lizenzkosten (einmalig oder laufend), Implementierung (oft als Werkleistung mit Festpreis), Schulung (Tagessätze oder Paketpreise), Wartung (als % oder als fixes Jahresentgelt) und ggf. Cloud-Betrieb (monatlich) – und dies über einen definierten Zeitraum (z.B. 4 Jahre TCO). Der Bieter füllt das aus; dieses Dokument wird Bestandteil des Vertrags (so ähnlich wie oben beschrieben). Damit ist vertraglich transparent festgelegt, wofür wie viel zu zahlen ist. Braucht der Auftraggeber später etwas Zusätzliches, was nicht im Vertrag stand, müsste er ggf. neu ausschreiben. Daher lieber initial einen „Preis für eventuelle weitere Schulungstage“ oder „Stundensatz für Zusatzleistungen außerhalb des definierten Umfangs“ aufnehmen – so hat man eine Preisgrundlage drin.

• Für öffentliche Auftraggeber ist die vollständige, eindeutige Benennung aller relevanten Preise im Vertrag nicht nur gut für die Zusammenarbeit, sondern auch rechtlich zwingend. Intransparenz kann zur Nichtigkeit des Vertrages führen oder zu erheblichen Problemen bei der Prüfung (etwa Rechnungshof etc.). Aber auch für private Verträge ist Transparenz von Vorteil: Sie beugt Missverständnissen vor und reduziert Streitigkeiten. Gerade komplexe Softwareverträge mit vielen Positionen profitieren davon, wenn der Kunde genau sieht, was er wofür bezahlt.

• Aus Sicht eines öffentlichen AG muss im Vertrag auch die Nachprüfbarkeit gegeben sein: also z.B. dass der Anbieter bei variablen Kosten (wie Nutzeranzahl) Abrechnungen vorlegt, die der AG nachprüfen kann. Etwa ein Bericht, wie viele Concurrent User im Peak genutzt wurden. Das gehört zwar eher ins SLA/Procedere, aber hat mit Transparenz zu tun.

Unter Indexierung versteht man vertragliche Klauseln, die eine Preisänderung über die Laufzeit hinweg an einen objektiven Index oder Parameter koppeln. Dies ist relevant für mehrjährige Verträge, um Inflation oder Kostensteigerungen abzubilden. Im IT-Bereich sind Indexklauseln gängig, da Verträge oft über mehrere Jahre laufen.

• Typische Indexklauseln: Häufig wird ein anerkannter Wirtschaftsindex verwendet, z.B. der Verbraucherpreisindex (VPI) oder ein spezieller Lohnindex (z.B. im IT-Bereich ist manchmal der „Index der Tariflöhne der IT-Branche“ o.ä. relevant) oder schlicht die allgemeine Inflationsrate in EU oder US$. Eine Standardformulierung könnte lauten: „Die jährlichen Wartungsgebühren erhöhen sich jeweils zum 1. Januar entsprechend der prozentualen Veränderung des Verbraucherpreisindex gegenüber dem Vorjahr, mindestens jedoch um 2% und höchstens um 5%.“ – Hier sind Deckelungen eingebaut. Ohne solche Deckelungen sieht man auch „gemäß Index, ohne Obergrenze“, was Risiko zum Kunden schiebt.

• Warum Indexierung? Anbieter wollen sich gegen Kaufkraftverluste schützen, gerade wenn z.B. Wartungsgebühren über lange Zeit konstant blieben, würde real weniger Geld ankommen. Kunden akzeptieren Indexierung meist, solange sie fair und symmetrisch ist (d.h. auch nach unten, falls Deflation – oft aber wird Deflation nicht berücksichtigt, was unsauber wäre). In öffentlichen Verträgen ist Indexierung oft erlaubt, aber die Klausel muss klar und eindeutig sein (im IHK-Text war erwähnt, dass flexible Preisanpassungen bei Miete möglich sind, sofern klar formuliert). Vergaberechtlich muss man Indexklauseln vollständig spezifizieren, damit alle Bieter damit rechnen konnten.

• Index vs. fester Satz: Manche Verträge schreiben stattdessen einen festen Staffelbetrag: z.B. "ab Jahr 3 +5% auf Gebühren". Das ist simpler, aber indexgebundene sind marktüblicher, da sie realitätsnaher (variabel) sind. Für den Kunden ist ein Fixprozentsatz vorteilhaft, wenn die tatsächliche Inflation höher ausfällt – er zahlt dann weniger als Index. Für den Anbieter umgekehrt. Index-Klauseln sind also ein Kompromiss.

• Vertragsgestaltung: Die Indexklausel sollte im Preisanhang oder im Hauptteil eindeutig verortet sein. Sie betrifft primär laufende Kosten: Wartung, Cloud-Miete, Supportverträge. Einmalige Kosten indexiert man nicht im Nachhinein – die werden einmal vereinbart. Höchstens wenn ein Roll-out über Jahre passiert (z.B. Jahr 1 Lizenzen X €, in Jahr 3 kauft man weitere, dann evtl. teurer). Dann könnte man auch sagen: "Zusatzlizenzen kosten in Zukunft den aktuellen Listenpreis, welcher jährlich indexiert wird."

• Praxis: Viele Standardsoftware-Wartungsverträge enthalten Sätze wie: „Die Wartungsgebühr kann vom Hersteller einmal jährlich angepasst werden. In den letzten Jahren betrug die Erhöhung typischerweise 3-4%.“ – Was vage ist. Besser ist, konkret an Verbraucherpreisindex zu koppeln. Es gab in der Vergangenheit Fälle, wo Wartung quasi automatisch jedes Jahr 5% stieg (de facto Preiserhöhungsmodi großer Hersteller). Solche Erhöhungen summieren sich über 5-10 Jahre dramatisch. Kunden versuchen, bei Vertragsverhandlung entweder einen Cap (Obergrenze) einzubauen oder zumindest einen zeitweisen Verzicht (z.B. „für die ersten 2 Jahre keine Erhöhung“). SoftwareOne rät z.B., einen fixen Supportpreis für ein paar Jahre zu verhandeln.

• Vergaberecht: In öffentlichen Verträgen ist es unproblematisch, wenn die Indexklausel drin stand im Angebot. Problematisch wäre, wenn der Anbieter später einseitig erhöhen will ohne Klausel – das geht nicht. Also alles, was an Preisänderungsmechanik besteht, muss ursprünglich im Vertrag fixiert sein. Und es muss sich automatisch oder zumindest ohne Neuaushandlung vollziehen, um nicht als neuer Vertrag zu gelten. Daher: „Der Preis ändert sich gemäß Index“ besser als "darf neu verhandelt werden". Letzteres wäre unbestimmt.

• Übertragbarkeit bezieht sich auf die Frage: Können die Vertragsrechte und -pflichten oder die Lizenzen auf Dritte übertragen werden? Sowohl aus Sicht des Kunden als auch des Anbieters ist das ein Thema.

• Übertragbarkeit auf Kundenseite (Lizenztransfer): Bei Kauflizenzen ist die Weiterveräußerung grundsätzlich erlaubt (siehe UsedSoft-Entscheidung und IHK-Hinweis: Weiterverkaufsverbote in AGB sind unwirksam). Allerdings kann der Vertrag dennoch bestimmte Voraussetzungen definieren: z.B. der Kunde muss alle eigenen Kopien löschen und dem neuen Erwerber mitteilen. Oft wird gewünscht, dass der Anbieter zustimmen muss – aber nach EU-Recht darf er das bei unbefristeten Lizenzen nicht verhindern. Anders bei Miet-/SaaS-Lizenzen: Hier besteht kein Erschöpfungsgrundsatz, da nichts "verkauft" wurde, sondern nur ein befristetes Nutzungsrecht. In Mietverträgen kann man daher Verbot der Abtretung der Nutzungsrechte an Dritte vereinbaren, und das wird auch gemacht. So soll verhindert werden, dass z.B. ein Kunde seine SaaS-Zugangsdaten an ein anderes Unternehmen weitergibt. Wenn ein Unternehmen restrukturiert (Fusion, Spin-off), ist relevant, ob die Lizenzen mit übergehen können. Verträge haben hier oft Klauseln, z.B.: „Ein Transfer der Softwarelizenzen an ein mit dem Kunden konzernverbundenes Unternehmen bedarf der schriftlichen Zustimmung des Anbieters, die nicht unbillig verweigert werden darf.“ oder „im Falle von Verschmelzung oder Spaltung des Kunden darf der Vertrag auf den Rechtsnachfolger übertragen werden.“ Fehlt so etwas, kann es in M&A-Fällen kompliziert werden. Im öffentlichen Bereich ist die Übertragung des Vertrags auf Rechtsnachfolger ebenfalls Thema, z.B. wenn eine Behörde umorganisiert wird. Das Vergaberecht lässt Vertragsübernahmen unter bestimmten Bedingungen zu (§ 132 GWB), typischerweise wenn ein Rechtsnachfolger den Auftraggeber ersetzt (Fusion etc.) oder den Auftragnehmer (Firmenkauf). Eine entsprechende Klausel im Vertrag (Change-of-Control Klausel) kann das proaktiv regeln: Etwa dass der Anbieter im Falle seines Firmenwechsels die Verpflichtungen an einen geeigneten Dritten übertragen darf, sofern dieser alle Vertragsbedingungen erfüllt, und der Kunde dem nicht binnen Frist widerspricht.

• Übertragbarkeit auf Anbieterseite: Der Anbieter könnte den Vertrag z.B. an ein Partnerunternehmen übertragen (outsourcen) – Kundenverträge haben häufig eine Klausel: „Ohne Zustimmung des Kunden darf der Anbieter den Vertrag nicht auf Dritte übertragen, ausgenommen an Konzerngesellschaften oder im Rahmen eines Unternehmensverkaufs.“ Das schützt Kunden vor plötzlichem Wechsel des Vertragspartners. Umgekehrt, der Anbieter will vermeiden, dass der Kunde seine Lizenz einem Wettbewerber gibt. Daher könnte im Vertrag stehen, dass bei Fusion mit Konkurrenten der Anbieter ein Sonderkündigungsrecht hat – aber das ist selten.

• Lizenztechnisch: Die meisten EULAs (End User License Agreements) von Standardsoftware sagen: Lizenz ist für Endanwender XY, nicht übertragbar außer nach den Gesetzen. In unserem Vertragskontext (B2B) wird es individualvertraglich aber geregelt sein. Bei SaaS-Konten ist klar: man gibt die Zugangsdaten nicht einfach weiter. Bei On-Prem-Lizenzen: theoretisch könnte man sie verkaufen wie man gebrauchte Maschinen verkauft. Das ist aber in der Praxis bei branchenspezifischer Software selten (weil oft customizing, Daten etc. dranhängen).

• Übertragbarkeit vs. Subunternehmer: Hier auch ein Aspekt: Darf der Auftragnehmer Subunternehmer einsetzen (z.B. ein anderes Rechenzentrum)? Falls ja, muss der Vertrag sicherstellen, dass der Sub dieselben Pflichten einhält (SLA, Datenschutz). Das fällt ebenfalls unter „Vertragsübertragung“ im weiteren Sinne (Delegation von Leistungspflichten). Öffentliche AG fordern meist Anzeige und Zustimmung bei wesentlichen Subunternehmen.

• Im Lizenzanhang selbst steht Übertragbarkeit selten, das ist eher in AGB oder Lizenzbedingungen. Aber es kann relevant werden, wenn man z.B. definieren will: „Named User Lizenzen sind personengebunden, aber übertragbar, wenn Person wechselt (z.B. beim Ausscheiden eines Mitarbeiters darf dessen Lizenz auf Nachfolger übertragen werden).“ Das ist eine kleine, aber wichtige Regelung. Sie verhindert, dass bei hoher Fluktuation ständig neue Lizenzen gekauft werden müssen. Concurrent-Lizenzen umgehen das Problem, Named-User-Lizenzen sollten das erlauben.

• Beispiel: Wenn ein öffentlicher Auftraggeber eine Lizenz kauft und nach 3 Jahren wird die Behörde reorganisiert – die Lizenzen müssen dann evtl. auf eine neue Behörde übergehen. Das muss klappen. Der Vertrag sollte so etwas erlauben und definieren, ob dies formal einer Zustimmung bedarf oder automatisch gilt (im Behördenbereich meist automatisch kraft Gesetz, aber gut wenn im Vertrag vermerkt).

• Zusammengefasst: Übertragbarkeit ist ein juristischer Parameter, der sicherstellt, dass die Nutzung der Software nicht unnötig rigide auf die ursprünglichen Vertragsparteien begrenzt ist. Gute Verträge enthalten:

• Klausel zur Abtretung/Übertragung des Vertrags als Ganzes (benötigt Zustimmung? Ausnahmen?).

• Regelung zur Lizenzübertragung an verbundene Unternehmen oder Rechtsnachfolger.

• Bei Named User evtl. explizite Regel zu personellen Wechseln.

• Hinweis, dass Weiterverkauf von Kauflizenzen im Rahmen der gesetzlichen Bestimmungen zulässig ist (oder zumindest kein Verbot).

• Bei öffentlichen Verträgen evtl. Klausel: "Der Auftragnehmer erklärt sich einverstanden, dass im Falle organisatorischer Änderungen der Auftraggeber den Vertrag auf Nachfolgeorganisationen übertragen kann."

his avoids disputes later on if the company or authority structure changes.