Beauftragen Sie Individualsoftware oder SaaS?

Entscheidungsrahmen: Kaufen Sie ein Ergebnis oder eine Dienstleistung?

Die erste Frage ist nicht juristisch, sondern betrieblich. Individualsoftware bedeutet, dass Sie für die Entwicklung von etwas bisher nicht Existierendem bezahlen und es behalten möchten. SaaS bedeutet, dass Sie den Zugang zu einer fertigen Lösung mieten, die der Anbieter betreibt und für alle Kunden weiterentwickelt.

Der Unterschied hat drei praktische Konsequenzen. Bei der Individualentwicklung geht es um Rechte am Code und um die Dokumentation, bei SaaS um Verfügbarkeit, Daten und Ausstiegsbedingungen. Bei der Entwicklung sind Sie im Moment der Übergabe verwundbar, bei SaaS während der gesamten Betriebsdauer. Und bei der Entwicklung besteht das größte Risiko darin, etwas zu erhalten, das niemand sonst übernehmen kann, bei SaaS darin, dass der Anbieter die Bedingungen einseitig ändert.

Die meisten realen Projekte sind hybrid: eine fertige Plattform plus individuelle Anpassungen, und gerade bei diesen Anpassungen stellt sich dann heraus, dass der Vertrag nur einen der beiden Teile regelt. Die praktische Lösung besteht darin, beide Ebenen getrennt zu beschreiben und für jede einzeln festzulegen, wer die Rechte hält, wer für die Funktionalität verantwortlich ist und was nach Vertragsende gilt. Der Betriebsebene von SaaS widmen wir uns ausführlich im Artikel Vertragliche Absicherung von Verfügbarkeit und Qualität von Cloud-Diensten (SLA).

Eine vierte Variante, auf die Unternehmen erst später stoßen, ist die Entwicklung mit generativen Werkzeugen. Dabei ist entscheidend zu wissen, womit der Anbieter den Code erstellt hat, denn das beeinflusst, was er Ihnen überhaupt übergeben kann. Diese Frage behandeln wir im Artikel Softwareentwicklung mit künstlicher Intelligenz – wem gehört der Code.

Schritt-für-Schritt-Vorgehen

Die Reihenfolge der Schritte folgt den Verhandlungsphasen. Wer sie überspringt, zahlt später im Betrieb dafür drauf.

Der erste Schritt besteht darin, das Ergebnis so zu beschreiben, dass es messbar ist. Zur Spezifikation gehören Funktionen, Leistungsparameter und Testszenarien. Eine Formulierung wie „das System wird benutzerfreundlich sein“ hält im Abnahmeprotokoll nicht stand, eine Formulierung wie „Antwortzeit unter zwei Sekunden bei fünfzig gleichzeitigen Nutzern“ dagegen schon.

Der zweite Schritt besteht darin, die Rechte am Code zu klären, und zwar schriftlich und vor Unterzeichnung des Hauptvertrags. Entscheiden Sie, ob Sie die vermögensrechtlichen Urheberrechte am Code ausüben müssen oder ob Ihnen eine ausreichend breite Lizenz genügt, und wenn Lizenz, in welchem Umfang: für wie viele Nutzer, für wie viele Installationen, mit dem Recht, den Code an einen Dritten weiterzugeben, der das System anstelle des Anbieters weiterentwickelt.

Der dritte Schritt ist die Abnahme. In den Vertrag gehört, wer den Test durchführt, wie lange er dauert, was bei einem Teilfehler geschieht und wann das Werk auch ohne Unterschrift als abgenommen gilt. Ohne das entsteht ein Streit darüber, ob das Werk fertiggestellt und übergeben wurde und ob der entsprechende Teil des Preises fällig ist. Das Gesetz macht die Unterschrift unter das Protokoll nicht zur Zahlungsvoraussetzung, aber der Vertrag kann sie daran knüpfen.

Der vierte Schritt ist der Betrieb: Verfügbarkeit, Reaktionszeiten, Wartungsfenster und Sanktionen bei deren Nichteinhaltung. Hier lohnt es sich, die Sanktionen als automatische Gutschriften auszugestalten, nicht als Schadensersatz, den der Auftraggeber erst nachweisen müsste.

Der fünfte Schritt ist die Absicherung für den Fall, dass der Anbieter ausfällt. Das klassische Instrument ist die Hinterlegung des Quellcodes bei einem Dritten mit festgelegten Herausgabebedingungen. Eine Hinterlegung ohne aktuelle Dokumentation ist nutzlos, daher gehört auch die Pflicht zur Hinterlegung der Dokumentation und des aktuellen Builds in den Vertrag.

Der sechste Schritt ist der Exit. In den Vertrag gehören das Format, in dem Sie die Daten erhalten, die Frist für deren Herausgabe, die Dauer der Mitwirkungspflicht nach Vertragsende und der Preis für die Unterstützung bei der Migration. Bei der Individualentwicklung ist der Exit reine Vertragssache, und ohne vereinbarten Preis wird daraus eine Verhandlung unter Druck.

Bei Cloud- und SaaS-Diensten bestimmt aber nicht mehr allein der Vertrag über den Exit. Seit dem 12.9.2025 gilt Kapitel VI der EU-Datenverordnung, die Anbieter von Datenverarbeitungsdiensten verpflichtet, Hindernisse für den Wechsel zu einem anderen Anbieter zu beseitigen und den Datenexport zu ermöglichen. Die Wechselgebühren sind übergangsweise auf die damit unmittelbar verbundenen Kosten begrenzt und sollen ab dem 12.1.2027 vollständig entfallen. Bei Verhandlungen lohnt es sich daher zu prüfen, ob der Vertragsentwurf diese Regeln beachtet oder ihnen widerspricht.

Der siebte Schritt ist der Änderungsprozess. Ohne beschriebenes Verfahren für Änderungsanforderungen werden Änderungen per E-Mail geregelt, und ein Streit darüber, was im Preis enthalten war, ist vorprogrammiert. In den Vertrag gehört daher, wer eine Änderung genehmigt, innerhalb welcher Frist der Anbieter eine Aufwandsschätzung liefert und was mit dem Termin geschieht, wenn der Auftraggeber die Schätzung nicht genehmigt.

Was ist Marktstandard und was ein Warnsignal

Bei gesunden Projekten ist es üblich, dass der Entwicklungspreis in Phasen unterteilt wird, die an Teilabnahmen geknüpft sind, und der letzte Teil erst nach der Übernahme in den Betrieb bezahlt wird. Ebenso üblich ist, dass der Anbieter während der Gewährleistungsfrist für Mängel haftet und parallel dazu kostenpflichtigen Support anbietet – das sind zwei unterschiedliche Dinge, die nicht miteinander vermischt werden sollten.

Bei SaaS ist es Standard, dass die Verfügbarkeit durch eine einzige Zahl pro Monat beschrieben wird, eine geplante Ausfallzeit definiert ist, die nicht in die Verfügbarkeit eingerechnet wird, und Gutschriften bei Nichteinhaltung gewährt werden. Ebenfalls Standard ist, dass der Anbieter Funktionen ändern, aber das vereinbarte Serviceniveau nicht absenken darf, und dass er über Änderungen im Voraus informiert.

Es gibt drei Warnsignale, die Sie schon beim Lesen des Vertragsentwurfs erkennen. Das erste ist ein Vertrag, der kein Wort über den Quellcode oder die Dokumentation enthält, denn das bedeutet, dass die Übernahme des Systems durch einen anderen Anbieter technisch nicht möglich sein wird. Das zweite ist eine auf die Höhe der Monatszahlung begrenzte Haftung des Anbieters, was bei einem Jahresbetrieb bedeutet, dass er für verursachte Schäden praktisch nicht haftet.

Das dritte Warnsignal ist die Bindung der Daten an ein Format, das anderswo nicht lesbar ist. Die Formulierung „die Daten werden in dem vom Anbieter verwendeten Format herausgegeben“ bedeutet in der Praxis einen Export, dessen Aufbereitung Sie zweimal bezahlen. Mit derselben Logik sind auch die Bestimmungen zur Verarbeitung personenbezogener Daten zu lesen; wir behandeln sie im Artikel SaaS-Plattform in der EU.

Wo liegt die rechtliche Grenze

Die gesetzliche Regelung ist bei Software strenger, als Unternehmen erwarten, und in einem Punkt dagegen entgegenkommender.

Nach § 58 Abs. 7 des tschechischen Urheberrechtsgesetzes gelten Computerprogramme und Datenbanken auch dann als Arbeitnehmerwerke, wenn sie vom Urheber im Auftrag geschaffen wurden, wobei der Auftraggeber in diesem Fall als Arbeitgeber gilt. Das bedeutet, dass Sie bei einem freiberuflichen Programmierer, der den Code in Ihrem Auftrag geschrieben hat, die vermögensrechtlichen Rechte ausüben, sofern Sie nichts anderes vereinbart haben.

Die Situation ändert sich jedoch, wenn der Anbieter eine Softwarefirma ist. Schreiben deren Angestellte den Code, übt nach derselben Bestimmung sie als Arbeitgeberin die vermögensrechtlichen Rechte aus, und zu Ihnen gelangen die Rechte nur in dem Umfang, den der Vertrag festlegt.

In der Praxis kombiniert der Anbieter zudem oft die Arbeit von Angestellten, freien Mitarbeitern, Subunternehmern, Open-Source-Bibliotheken und Komponenten Dritter, sodass die gesamte Rechtekette überprüft werden muss, nicht nur die Erklärung des Anbieters. Auch bei einem freiberuflichen Programmierer gehören daher die Übergabe des Quellcodes, der Dokumentation, der Bearbeitungsrechte und ein Verzeichnis der verwendeten Komponenten Dritter in den Vertrag.

Für Werke, auf die diese Regel nicht zutrifft, gilt nach § 61 des Urheberrechtsgesetzes, dass der Urheber die Lizenz nur für den sich aus dem Vertrag ergebenden Zweck erteilt hat. Eine darüber hinausgehende Nutzung erfordert einen Lizenzvertrag. Bei Grafiken, Texten oder Oberflächenentwürfen, die zusammen mit der Software geliefert werden, ist das oft ein übersehenes Detail.

Der Lizenzvertrag selbst hat ein gesetzliches Minimum. Nach § 2358 erteilt der Lizenzgeber die Lizenz im vereinbarten beschränkten oder unbeschränkten Umfang, und der Lizenznehmer verpflichtet sich zur Zahlung einer Vergütung, sofern nichts anderes vereinbart ist; bei einer ausschließlichen Lizenz verlangt der Vertrag die Schriftform. Der Umfang muss daher beschrieben werden, sonst wird darüber gestritten.

Auch die Regel zur Abtretung der Lizenz wirkt sich auf den Exit aus. Nach § 2364 des tschechischen Bürgerlichen Gesetzbuchs (Gesetz Nr. 89/2012 Slg., im Folgenden „OZ“) kann der Lizenznehmer die Lizenz nur mit Zustimmung des Lizenzgebers an einen Dritten abtreten, wofür Schriftform erforderlich ist. Bei der Übertragung eines Unternehmens oder eines selbständigen Unternehmensteils ist nach § 2365 OZ eine Zustimmung nur erforderlich, wenn dies gesondert vereinbart wurde. Wer den Verkauf des Unternehmens oder die Ausgliederung einer Sparte plant, sollte diesen Punkt bereits bei Unterzeichnung des IT-Vertrags regeln.

Bei der Abnahme gelten dann die Regeln zum Werkvertrag. Nach § 2610 OZ entsteht der Anspruch auf Zahlung des Werkpreises mit dessen Ausführung, und wird das Werk in Teilen übernommen, entsteht der Zahlungsanspruch für jeden Teil bei dessen Ausführung. Nach § 2605 OZ gilt das Werk dabei als fertiggestellt, wenn seine Eignung zur Erfüllung seines Zwecks nachgewiesen wurde, und übernimmt der Auftraggeber das Werk vorbehaltlos, spricht ihm das Gericht kein Recht aus einem offensichtlichen Mangel zu, wenn der Anbieter die verspätete Geltendmachung einwendet. Die Unterschrift unter das Abnahmeprotokoll ist also keine gesetzliche Voraussetzung für die Entstehung des Preisanspruchs, aber der Vertrag kann die Fälligkeit daran knüpfen, weshalb über seine Ausgestaltung verhandelt wird.

Die letzte Grenze bildet die Haftungsbeschränkung. Nach § 2898 OZ bleibt eine Vereinbarung unbeachtlich, die im Voraus die Pflicht zum Ersatz eines Schadens ausschließt oder beschränkt, der einem Menschen an seinen natürlichen Rechten oder vorsätzlich beziehungsweise grob fahrlässig zugefügt wurde. Eine vereinbarte Haftungsobergrenze greift daher in diesen Fällen nicht, unabhängig davon, wie die Parteien sie festlegen.

Abschließende Zusammenfassung

Ein IT-Vertrag sollte vom Ende her geschrieben werden. Beantworten Sie zunächst, was Sie an dem Tag, an dem Sie sich vom Anbieter trennen, in der Hand haben müssen: den Quellcode, die Dokumentation, die Daten in einem nutzbaren Format und jemanden, der das System übernimmt. Erst danach klären Sie Preis und Fristen. Formulieren Sie die Abnahmekriterien messbar, beschreiben Sie den Exit einschließlich des Preises für die Unterstützung, und führen Sie den Änderungsprozess gleich zu Beginn ein.

Die rechtliche Grenze ist dabei in einem Punkt günstiger, als Unternehmen vermuten, und in einem anderen strenger. Bei einem beauftragten Programmierer üben Sie die vermögensrechtlichen Rechte aus, bei einer Softwarefirma haben Sie sie nur in dem Umfang, den der Vertrag festlegt. Die Anwaltskanzlei ARROWS ist für den Fall der Berufshaftpflicht mit einem Limit von 350 000 000 CZK (ca. 14,4 Mio. EUR) versichert und verhandelt IT-Verträge im Rahmen der Dienstleistung IT- und Softwarerecht, Cybersicherheit. Schreiben Sie an beratung@arws.cz.