Der Kauf von Standard-Software – Tipps für die Vertragsgestaltung
Standardsoftware rechtssicher gestalten: Von Lizenzmodellen bis zu Update- und Sicherheitsanforderungen – klare Verträge vermeiden teure Streitigkeiten. Leistungsumfang, Gewährleistung und Haftung sollten dabei sauber geregelt sein.
Inhaltsverzeichnis
- Vertragsgegenstand
- 1. Soll-Beschaffenheit und Gewährleistung
- 2. Dokumentation, Installation und Leistungsabgrenzung
- 2. Installation und Installationshinweise
- 2. Abgrenzung: Was nicht geschuldet ist
- Nutzungsrechtseinräumung (Lizenzmodell)
- 1. EULA und Einbeziehung in den Vertrag
- 2. Weitergabe und Erschöpfung
- Zahlung, Eigentumsvorbehalt und aufschiebende Rechteübertragung
- Regelungen zur Mangelhaftung (Gewährleistung)
- 1. Warum pauschale Disclaimer nicht tragen
- 2. Besser: Leistungsbild und Mängelprozess klar regeln
- Updates, Sicherheitsupdates und Wartung (seit 01.01.2022 besonders relevant)
- Haftung und Schadensersatz – Abgrenzung zur Gewährleistung
Vertragsgegenstand
Der Vertragsgegenstand – also die zu überlassende Software – sollte so präzise wie möglich beschrieben werden. Je weniger Interpretationsspielraum bleibt, desto geringer ist das Risiko, dass die Parteien später unterschiedliche Vorstellungen davon haben, was genau geschuldet war.
In der Praxis empfiehlt es sich, die Beschreibung nicht nur im Fließtext vorzunehmen, sondern ergänzend eine Anlage beizufügen, in der insbesondere Funktionsumfang, wesentliche Leistungsmerkmale sowie System- und Umgebungsanforderungen (Hardware, Betriebssysteme, Abhängigkeiten, Schnittstellen) festgehalten werden.
1. Soll-Beschaffenheit und Gewährleistung
Aus Gewährleistungssicht ist vor allem die präzise Festlegung der Soll-Beschaffenheit entscheidend.
Ob ein Mangel vorliegt, beurteilt sich danach, ob die Ist-Beschaffenheit von der vertraglich vereinbarten Soll-Beschaffenheit abweicht. Eine sauber definierte Soll-Beschaffenheit reduziert das Streitpotenzial erheblich und schafft eine belastbare Grundlage für die spätere Bewertung von Abweichungen.
Bei Standardsoftware wird die Software regelmäßig ausschließlich im Objektcode überlassen. Soll kein Quellcode geschuldet sein – was bei Standardprodukten typischerweise der Fall ist –, sollte dies vorsorglich ausdrücklich klargestellt werden. So wird verhindert, dass aus unklaren Formulierungen Erwartungen abgeleitet werden, die der Anbieter nicht erfüllen will und nicht kalkuliert hat.
2. Dokumentation, Installation und Leistungsabgrenzung
Zum Vertragsgegenstand gehört häufig auch eine Benutzerdokumentation. Fehlt sie vollständig oder ist sie in einer Weise unzureichend, dass eine vertragsgemäße Nutzung nicht möglich oder nur mit unverhältnismäßigem Aufwand möglich ist, kann dies einen Mangel begründen.
Im Vertrag sollte daher geregelt werden, in welcher Form die Dokumentation bereitgestellt wird (z. B. PDF, Online-Handbuch, integrierte Hilfe), in welcher Sprache sie verfügbar ist und wie der Käufer dauerhaft Zugriff erhält.
2. Installation und Installationshinweise
Auch Installationshinweise bzw. eine Installationsanleitung können zum geschuldeten Leistungsumfang gehören – jedenfalls dann, wenn eine Installation ohne Anleitung nicht zumutbar möglich ist oder besondere Systemvoraussetzungen zu beachten sind.
Ist die Software so gestaltet, dass sie sich typischerweise ohne weiteres Zutun installieren und in Betrieb nehmen lässt, kann eine ausführliche Installationsanleitung entbehrlich sein; auch das lässt sich klarstellend regeln.
2. Abgrenzung: Was nicht geschuldet ist
Ebenfalls wichtig ist die Abgrenzung dessen, was nicht geschuldet ist.
Die Hauptleistung des Verkäufers im Kaufvertrag besteht in der Verschaffung der Software zur vertragsgemäßen Nutzung.
Eine Verpflichtung, die Software beim Käufer zu installieren, Systeme einzurichten, Daten zu migrieren, Schulungen durchzuführen oder Anpassungen vorzunehmen, besteht grundsätzlich nicht, sofern dies nicht ausdrücklich vereinbart wurde.
Anbieter sollten daher transparent festhalten, welche Leistungen nicht vom Kaufpreis umfasst sind und – falls gewünscht – zu welchen Konditionen Zusatzleistungen gesondert beauftragt werden können.
Nutzungsrechtseinräumung (Lizenzmodell)
Zwar kann sich bereits aus dem Vertragszweck ergeben, dass der Käufer diejenigen Nutzungsrechte erhält, die zur vertragsgemäßen Nutzung erforderlich sind. Gleichwohl ist eine ausdrückliche Regelung zur Nutzungsrechtseinräumung in der Praxis dringend zu empfehlen. Sie schafft Rechtssicherheit, beugt Missverständnissen vor und ermöglicht es, das gewollte Lizenzmodell klar zu beschreiben.
Inhaltlich sollte geregelt werden, ob die Nutzung nur für eine bestimmte Anzahl von Arbeitsplätzen/Installationen zulässig ist, ob die Nutzung auf bestimmte Hardware, einen Standort oder eine juristische Person beschränkt ist und ob der Käufer Sicherungskopien erstellen darf.
Dabei ist stets zu prüfen, ob das gewählte Lizenzmodell – insbesondere in AGB – wirksam ausgestaltet werden kann; Regelungen müssen klar, transparent und für den typischen Vertragspartner nachvollziehbar sein.
1. EULA und Einbeziehung in den Vertrag
Soweit im Vertrieb mit zusätzlichen Endnutzerbedingungen gearbeitet wird (z. B. EULA – Endnutzer-Lizenzbedingungen), ist besondere Sorgfalt geboten.
Häufig scheitert die Wirksamkeit nicht an einzelnen Inhalten, sondern daran, dass solche Bedingungen nicht ordnungsgemäß in den Vertrag einbezogen werden oder mit den Vereinbarungen zwischen Verkäufer und Käufer kollidieren. Für ein rechtssicheres Setup sollte eindeutig festgelegt werden, welche Bedingungen gelten und wie diese wirksam Vertragsbestandteil werden.
2. Weitergabe und Erschöpfung
Besondere Aufmerksamkeit verdient außerdem die Frage der Weitergabe.
Pauschale Weitergabeverbote in AGB sind regelmäßig problematisch, weil sie mit dem urheberrechtlichen Erschöpfungsgrundsatz kollidieren können.
Praktikabel ist es daher häufig, statt eines Totalverbots zulässige Modalitäten zu regeln, etwa Pflichten zur Löschung eigener Kopien, Dokumentations- bzw. Mitteilungspflichten oder technische/organisatorische Vorgaben, ohne die Weitergabe faktisch zu vereiteln. Wenn ein weitergehendes Verbot im Einzelfall gewollt ist, ist sorgfältig zu prüfen, ob und in welcher Form dies individualvertraglich tragfähig vereinbart werden kann.
Zahlung, Eigentumsvorbehalt und aufschiebende Rechteübertragung
Ein klassischer Eigentumsvorbehalt eignet sich bei Software nur eingeschränkt.
Ein klassischer Eigentumsvorbehalt ist bei Software nur begrenzt tauglich. Er lässt sich allenfalls an körperlichen Bestandteilen festmachen, etwa an einem Datenträger oder einem gedruckten Handbuch.
Im Kern geht es beim Softwarekauf jedoch regelmäßig um die Berechtigung zur Nutzung. Deshalb arbeiten Verträge häufig mit der Konstruktion, dass die Einräumung der Nutzungsrechte unter der aufschiebenden Bedingung der vollständigen Kaufpreiszahlung steht.
Entsprechende Regelungen müssen klar und nachvollziehbar formuliert sein. Es sollte eindeutig erkennbar sein, ab wann welche Nutzung zulässig ist, welche Folgen ein Zahlungsverzug auslöst und ob bis zur vollständigen Zahlung zumindest eine vorläufige Nutzung gestattet wird.
Gerade in AGB darf die aufschiebende Rechteübertragung den Käufer nicht unangemessen benachteiligen. In der Praxis bedeutet das meist, dass dem Käufer zumindest eine Nutzung in dem Umfang ermöglicht werden sollte, der erforderlich ist, um die Software angemessen zu testen sowie etwaige Mängel festzustellen und zu dokumentieren.
Regelungen zur Mangelhaftung (Gewährleistung)
Bei der Überlassung von Standardsoftware werden Vertragsbedingungen häufig als AGB verwendet. Deshalb sind Abweichungen von den gesetzlichen Gewährleistungsvorschriften nur in engen Grenzen zulässig. Wer hier „zu viel“ regeln will, riskiert am Ende nicht nur die Unwirksamkeit einzelner Klauseln, sondern auch Folgeprobleme durch intransparente oder überraschende Bestimmungen.
1. Warum pauschale Disclaimer nicht tragen
In der Praxis sind pauschale Hinweise wie „Software ist nie fehlerfrei“ oder „as is“ kein geeignetes Mittel, um Gewährleistung auszuschließen oder zu reduzieren.
Entscheidend ist vielmehr, ob die Software die vertraglich vereinbarte Beschaffenheit aufweist und für die vorausgesetzte bzw. gewöhnliche Verwendung geeignet ist. Allgemeine Disclaimer ersetzen keine klare Leistungsbeschreibung und entbinden nicht von der Pflicht, eine vertragsgemäße Software zu liefern.
2. Besser: Leistungsbild und Mängelprozess klar regeln
Sinnvoll ist es, den Leistungsumfang sauber zu definieren, die maßgeblichen Einsatzbedingungen (Systemumgebung, Versionen, Schnittstellen) festzuhalten und – soweit zulässig – klare Prozesse für die Mängelbearbeitung zu regeln: etwa Ansprechpartner, Fehlerklassifizierung, Mitwirkungspflichten des Käufers bei der Analyse sowie eine strukturierte Nacherfüllung.
In AGB sollten dabei insbesondere Regelungen vermieden werden, die Mängelrechte faktisch entwerten oder überraschend einschränken. Praktikabel sind transparente Abläufe, die eine zügige Fehleranalyse ermöglichen, ohne gesetzliche Rechte abzukürzen.
Updates, Sicherheitsupdates und Wartung (seit 01.01.2022 besonders relevant)
In der Praxis entstehen Streitigkeiten besonders häufig bei der Frage, ob der Anbieter nach der Überlassung der Software auch Updates, Fehlerkorrekturen oder Sicherheits-Patches schuldet. Der Vertrag sollte daher klar trennen zwischen der Bereitstellung der Software in der vereinbarten Version und etwaigen Wartungs- bzw. Pflegeleistungen.
Seit dem 1. Januar 2022 enthält das BGB zudem besondere Vorschriften für digitale Produkte und Waren mit digitalen Elementen. Im B2C-Bereich trifft den Unternehmer eine gesetzliche Aktualisierungspflicht. Er muss dem Verbraucher die Aktualisierungen bereitstellen, die erforderlich sind, damit das Produkt vertragsgemäß bleibt – hierzu zählen regelmäßig auch Sicherheitsupdates – und den Verbraucher über Aktualisierungen informieren. Pauschale Ausschlüsse, insbesondere von Sicherheitsupdates, sind in B2C-AGB daher rechtlich besonders angreifbar.
Aber auch im B2B-Bereich ist eine klare Regelung dringend zu empfehlen, um Erwartungslücken und Haftungsrisiken zu vermeiden. Vertragspraktisch bewährt es sich insbesondere, die folgenden Punkte konkret festzulegen:
- Versionsbezug: Gilt der Vertrag für eine bestimmte Version (z. B. „Version 5.x“) oder auch für Upgrades auf neue Major-Releases?
- Fehlerkorrekturen: Werden Bugfixes bereitgestellt und nach welchen Prioritäten/Prozessen?
- Sicherheitsupdates: Werden Patches geliefert, und für welchen Zeitraum bzw. in welchem Umfang?
- Kompatibilität: Welche Systemumgebungen/Abhängigkeiten werden unterstützt (und wie lange)?
- Wartungsvertrag: Welche Leistungen sind nur im Rahmen eines Pflegevertrags geschuldet (Leistungsumfang, Laufzeit, Vergütung, Servicezeiten, Reaktions-/Behebungsprozesse)?
Haftung und Schadensersatz – Abgrenzung zur Gewährleistung
Neben der Gewährleistung sollten Verträge sauber zwischen den Mängelrechten (Nacherfüllung, Minderung, Rücktritt) und der Haftung für Schäden unterscheiden.
In der Praxis entzünden sich viele Streitigkeiten daran, ob ein Problem „nur“ einen Mangel darstellt oder ob darüber hinaus Schadensersatzansprüche entstehen, etwa wegen Datenverlust, Betriebsunterbrechung oder sonstiger Folgeschäden.
Gerade bei Standardsoftware und in AGB ist Zurückhaltung geboten. Wer die Haftung zu weitgehend beschränkt, riskiert die Unwirksamkeit der Klausel. Sinnvoll sind daher transparente Regelungen, die typische Schadensszenarien aufgreifen und zwingende Haftungstatbestände unberührt lassen.
Ergänzend sollte der Umgang mit Daten und Backups vertraglich geordnet werden – etwa durch Sicherungspflichten, Testumgebungen und Dokumentationsanforderungen. So lassen sich typische Schäden häufig bereits im Vorfeld vermeiden und Verantwortlichkeiten klar zuordnen.
Fragen zum Beitrag? Diskutieren Sie hierzu gerne mit uns in der Unternehmergruppe der IT-Recht Kanzlei auf Facebook.
Link kopieren
Als PDF exportieren
Per E-Mail verschicken
Zum Facebook-Account der Kanzlei
Zum Instagram-Account der Kanzlei

1 Kommentar
Kauft oder least man eine Datenbanksoftware werden Daten in einer Datenbank gespeichert.
Der Anwender hat nur über das lizensierte Programm Zugriff darauf.
Endet nun der Vertrag hat er keine Möglichkeit mehr auf seine Rohdaten (vorliegend in einer geschlossenen Datenbank) zuzugreifen.
Gibt es da eine Handhabe?