Neue rechtliche Vorgaben der EU zum Vertragsrecht werden demnächst dazu führen, dass die Mehrzahl aller Verträge (und Allgemeiner Geschäftsbedingungen), bei denen es um digitale Inhalte oder digitale Services geht, weitgehend revidiert werden müssen. Das BGB wird durch eine Vielzahl neuer Bestimmungen (insbesondere durch Einfügung der §§ 327 ff.) ergänzt.
Derzeit liegt ein Regierungsentwurf vor, aus dem sich die anstehenden Änderungen entnehmen lassen. Bis Juli 2020 soll das entsprechende Gesetz vorlegen, zum 01.01.2022 in Kraft treten. Der Zeitraum für die Umsetzung in die Vertragspraxis ist damit denkbar knapp, da es hier nicht nur um rechtliche Formulierung, sondern auch um Geschäftsprozesse und deren technische Umsetzung geht. Betroffen sind die meisten Verträge, in denen es um die Lieferung digitaler Inhalte (u.a. Daten, Software, Content) oder die Erbringung digitaler Services geht. Der Anwendungsbereich der neuen gesetzlichen Regelung ist denkbar breit.
Damit wird die „Digitalisierung“ des Vertragsrechts weiter vorangetrieben. Wesentliche Neuerungen in Stichpunkten:
- Regelungen gelten nur für entgeltliche Verträge, wobei Entgeltlichkeit in der Regel auch dann gegeben ist, wenn mit personenbezogenen Daten bezahlt wird
- Regelungen unabhängig vom Vertragstyp (Keine Differenzierung nach Kauf, Miete, Dienst, etc.)
- Neues Gewährleistungsrecht
- Viele Vorschriften unabdingbar
- Gestaltungsspielräume für den Anbieter beim Mangelbegriff, insbesondere beim objektiven Mangelbegriff
- Besondere Vorschriften für abweichende Vereinbarungen, unter anderem Pflicht zur rechtzeitigen Information und ausdrückliche Zustimmung mittels technischer Opt-In-Lösung
- Aktualisierungspflicht für digitale Inhalte
- Regelungen zum Unternehmer, Regress in der Lieferkette
- Verbraucherfreundliche Regelungen zur Verjährung und zur Beweislast
- Ausnahmen für Open Source
Das neue Regelwerk ist denkbar kompliziert, Abgrenzungen zum Urheberrecht und zum Datenschutzrecht sind unscharf. Entsprechende Projekte zur Neugestaltung von Verträgen und Vertragsmodellen müssen rechtzeitig begonnen werden, da man sonst am 01.01.2022 mit abmahnfähigen AGB, etc., exponiert ist. Das Thema war unter anderem Schwerpunktthema der Kölner Tage IT-Recht im März 2021.
Seit einigen Jahren ist SaaS in aller Munde. Die Software wird nicht mehr an den Kunden verkauft, sondern diesem nur noch über das Internet zur Nutzung zur Verfügung gestellt. Bei der Vertragsgestaltung bleibt dabei in der Praxis häufig viel zu wünschen übrig. Hier ein paar praktische Hinweise.
- Zunächst ist es sinnvoll, die einmalig zu erbringenden Leistungen (Implementierung, Datenmigration, Schulungen) von den auf Dauer zu erbringenden Leistungen (Softwareüberlassung und Service Level Agreement) zu trennen und die jeweiligen Leistungen beispielsweise in separaten Leistungsscheinen zu regeln. Mit dieser Trennung korrespondieren regelmäßig entsprechende Vergütungsvereinbarungen (einmalige Zahlungen und wiederkehrende Zahlungen).
- Ein typischer Streitpunkt ist die Fälligkeit der Vergütung für das Implementierungs- und Migrationsprojekt. Bei dem Verkauf von zeitlich unbefristeten Lizenzen für On-premise-Software hatten die Anbieter den Vorteil, dass sie gleich zu Beginn eines Projekts die Vergütung für den Lizenzerwerb in Rechnung stellen und als Aktivposten bilanzieren konnten. Diese Möglichkeit der sofortigen sog. Revenue Recognition eines nicht unerheblichen Teils des gesamten Projektvolumens entfällt bei SaaS. Die Anbieter versuchen bisweilen, diesen Nachteil zu kompensieren, indem sie eine erhebliche (z. B. 50%) Vorauszahlung der Einmalvergütung für das Implementierungs- und Migrationsprojekt verlangen. Aus Kundensicht ist das im Hinblick auf den Grundsatz, dass die Vergütung erst bei Abnahme fällig wird, jedoch nicht gerechtfertigt. Eine Vergütung nach der Fertigstellung bestimmter Meilensteine der Implementierung wird den Interessen beider Parteien gerecht. Aus Anbietersicht ist es sinnvoll, dies mit einer Vereinbarung von Teilabnahmen der Meilensteine zu verbinden.
- Bei den Bestimmungen über die Laufzeiten sowohl der Softwareüberlassung als auch des Service Level Agreements ist aus Anwendersicht darauf zu achten, dass diese erst nach Abnahme des Implementierungs- und Migrationsprojekts und nach der Übernahme des Systems in den Produktivbetrieb (sog. „Go Live“) beginnen.
- Ein weiterer wichtiger Regelungsgegenstand ist das Verhältnis von Gewährleistung und Service Level Agreement. Mängel der Software sind über die gesamte Vertragslaufzeit bereits aufgrund gesetzlicher Gewährleistung zu beseitigen, und Gewährleistungsansprüche haben grundsätzlich Vorrang vor einem Service Level Agreement. Es ist daher sinnvoll, die Abgrenzung zwischen Gewährleistung und über die Erfüllung von Gewährleistungsansprüchen hinausgehender Wartung und Pflege im Service Level Agreement klar zu regeln.
- Von Mängeln der (Standard-) Software als solcher sind Mängel zu unterscheiden, die auf eine fehlerhafte Implementierung oder eine fehlerhafte Datenmigration zurückzuführen sind. Der Kunde hat zunächst einen vertraglichen Anspruch auf mangelfreie Implementierung des Systems und mangelfreie Migration der Daten. Auch nach der Abnahme der Implementierung und der Migration hat der Kunde einen Anspruch aus Gewährleistung auf Beseitigung noch vorhandener Mängel, insbesondere unwesentlicher Mängel, wegen derer die Abnahme nicht verweigert werden darf. Auch hier gilt, dass Gewährleistungsansprüche grundsätzlich Vorrang vor einem Service Level Agreement haben. Das Problem der Abgrenzung zwischen Gewährleistungsanspruch und Service Level Agreement kann hier relativ einfach durch eine klare und eindeutige Regelung dahingehend gelöst werden, dass das Service Level Agreement erst mit dem Go Live beginnt, und dass die Beseitigung der bei der Abnahme der Implementierung vorhandenen Mängel unverzüglich und unabhängig vom Service Level Agreement erfolgt.
- Bei der Formulierung von Kündigungsrechten ist aus Anwendersicht darauf zu achten, dass durch die Kündigung (oder den Rücktritt vom Vertrag) in der Implementierungs- und Migrationsphase auch die die übrigen Vertragsbestandteile erfasst werden, sofern dem nicht bereits durch eine entsprechende Regelung der Laufzeiten (oben 3.) Rechnung getragen wurde.
Weitere Hinweise finden Sie in einem ausführlichen Aufsatz von Dr. Truiken J. Heydn in Heft 7 der MMR 2020, Seiten 435 ff.
Seit einigen Jahren sind agile Methoden wie z.B. Scrum bei der Softwareerstellung in aller Munde. Höhere Kundenzufriedenheit sollen sie bringen, weil der Kunde schon früh im Projekt brauchbare Software erhält, und die leidigen „Scope“-Diskussionen sollen vermieden werden. Die Vertragsgestaltung wird dabei zumeist äußerst stiefmütterlich behandelt: Entweder man unterschreibt lediglich einen LOI, oder man nimmt irgendein Muster für einen (herkömmlichen) IT-Projektvertrag. Beides ist, vorsichtig ausgedrückt, suboptimal. Denn bei der Vertragsgestaltung für agile Softwareprojekte gibt es einiges zu beachten. Hier ein paar praktische Hinweise am Beispiel von Scrum:
1.
Die agile Projektmethode sollte im Vertrag ausdrücklich vereinbart werden. Denn für die erfolgreiche Anwendung agiler Projektmethoden ist es unabdingbar, dass der Auftraggeber die agile Projektmethode kennt, im besten Fall bereits Erfahrung damit hat, und vor allem dass er mitmacht. Projekte, bei denen nur der Auftragnehmer nach einer agilen Projektmethode arbeitet und der Auftraggeber erklärt, er könne den agilen Prozess nicht implementieren, sind zum Scheitern verurteilt.
2.
Vor allem bei Auftraggebern, die mit agilen Projektmethoden gar nicht oder nur wenig vertraut sind, empfiehlt es sich, im Vertrag gewissermaßen eine Anleitung für den Auftraggeber niederzulegen, also beispielsweise in den Definitionen die Scrum-spezifischen Begriffe zu erklären und gegeneinander abzugrenzen.
3.
Wie bei herkömmlichen IT-Projektverträge auch müssen die Mitwirkungspflichten des Auftraggebers konkret im Vertrag vereinbart werden. Insbesondere muss klar geregelt werden, welche Partei welche Rollen (Product Owner, Scrum Master, Entwicklungsteam) zu besetzen hat, und die Aufgaben der Inhaber dieser Rollen müssen konkret beschrieben werden. Sinnvollerweise sollte der Product Owner aus dem Unternehmen des Auftraggebers stammen und von diesem für die Wahrnehmung seiner Aufgaben im erforderlichen Umfang freigestellt werden. Damit kann dem Problem begegnet werden, dass die Mitarbeiter des Auftraggebers für die Arbeit am Projekt wie beispielsweise die Formulierung der Anforderungen oder die Beantwortung von Fragen des Auftragnehmers keine Zeit haben.
4.
Auch die Aufgaben des Product Owners, etwa die Erstellung, Ordnung und Verwaltung des Product Backlogs sollten im Vertrag vereinbart werden. Sinnvoll ist des Weiteren, dem Product Owner die Formulierung der Definitions of Done und die Entscheidung am Ende jedes Sprints, ob die gelieferte Funktionalität akzeptabel ist, zu übertragen. Denn wenn der Auftragnehmer die Definitions of Done formuliert, sind diese bereits deshalb als Abnahmekriterien untauglich.
5.
Die frühe Auslieferung brauchbarer Softwareteile, die im Idealfall unmittelbar nach ihrer Auslieferung in den Produktivbetrieb übernommen werden können, legt es nahe, zugunsten des Auftragnehmers Teilabnahmen der jeweils ausgelieferten Softwareteile zu vereinbaren.
6.
Bei der Vergütung wird eine Kombination einer aufwandsabhängigen und einer erfolgsabhängigen Vergütung den Interessen beider Parteien am ehesten gerecht, also z.B. eine am Ende jedes Sprints zu zahlende Pauschalvergütung und eine mit erfolgter Endabnahme zu zahlende weitere Vergütung.
7.
Besondere Sorgfalt sollte den Bestimmungen zur vorzeitigen Beendigung des Projekts gewidmet werden. In agilen Projekten empfiehlt sich insofern insbesondere eine Projektevaluierung zu einem genau definierten Zeitpunkt.
Weitere Hinweise finden Sie in einem ausführlichen Aufsatz von Dr. Truiken J. Heydn in Heft 5 der MMR 2020, Seiten 284 ff.
