Suche
Suche Menü

App-Entwicklung: Alles rechtlich Wichtige + Tipps & Vertragsmustern

app entwicklungsvertrag muster

In diesem umfassenden Beitrag erfahren Sie alles rechtlich Wichtige rund um App-Entwicklung. Unser Schwerpunkt liegt auf dem App-Entwicklungsvertrag, für den wir zahlreiche Musterformulierungen bereitstellen.

Wir beraten Sie bei Rechtsfragen zu mobilen Apps. Nutzen Sie unsere kostenlose und unverbindliche Ersteinschätzung.

I. Vorbemerkung

Der Begriff App (kurz für „application“) erfasst seinem Wortsinn nach jede Form von Anwendungssoftware. In diesem Beitrag geht es allein um Apps für mobile Endgeräte einschließlich Mischformen aus nativen und Web-Apps (vgl. LG Hamburg, Beschluss vom 08.10.2013, Az. 327 O 104/13wetterDE), nicht jedoch um reine Web-Apps, bei denen nur über den Browser ein Programm als SaaS ausgeführt wird.

App-Entwickler können es im Rechtsverkehr mit verschiedenen Vertragspartnern zu tun bekommen. Zuerst beleuchten wir eingehend das Vertragsverhältnis zum App-Anbieter. Will der App-Entwickler seine App selbst anbieten, kommen weitere Vertragsbeziehungen mit dem App Store und den Nutzern zustande.

nach oben

II. App-Entwickler ↔ App-Anbieter: App-Entwicklungsvertrag

Die Entwicklung einer mobilen App unterscheidet sich aus rechtlicher Perspektive nicht sonderlich von der Entwicklung gewöhnlicher Software. Die Besonderheiten mobiler Apps im Vergleich zu gewöhnlicher Software liegen im Vertrieb an den Endkunden, der in aller Regel über einen App-Store erfolgt, welcher wiederum vom Anbieter der Plattform des Endgeräts betrieben wird.

Beispiele: Die wichtigsten App-Stores sind für Apple- bzw. iOS-Geräte der App Store, für Android-Geräte der Google Play Store, für Windows-Geräte der Microsoft Store und für Amazon-Geräte der Amazon Appstore.

Diese Besonderheiten beim Vertrieb der Apps schlagen auf das Vertragsverhältnis zwischen App-Entwickler und App-Anbieter durch. Für den App-Anbieter ist es von großem Interesse, dass die entwickelte App für den vorgesehenen Vertriebsweg vertriebsfertig ist, d.h. den ins Auge gefassten App-Store.

Die Vertragsgestaltung zwischen App-Entwickler und App-Anbieter lässt sich in zwei wesentliche Schritte aufteilen:

  1. Zuerst muss geprüft werden, welchem Vertragstyp des BGB der geplante Vertrag zuzuordnen ist. Dadurch ist feststellbar, welchen gesetzlichen Regelungen der Vertrag unterliegt.
  2. Diese gesetzlichen Regelungen entsprechen oftmals nicht dem Parteiwillen. Deshalb sollten im App-Entwicklungsvertrag Vereinbarungen getroffen werden, die unerwünschte gesetzliche Vorschriften soweit möglich verdrängen oder konkretisieren.

nach oben

1. Abgrenzung des Vertragstyps

Mobile Apps sind Software. Entsprechend stellen App-Entwicklungsverträge Softwareerstellungsverträge dar. Je nach Ausgestaltung des App-Entwicklungsvertrags kann Werkvertragsrecht, Dienstvertragsrecht oder gar Werklieferungsrecht und damit im Ergebnis Kaufrecht Anwendung finden. Direkt zu unseren Praxistipps →

a. Werkvertrag

Die Rechtsprechung behandelt Softwareerstellungsverträge grundsätzlich nach den in §§ 631 ff. BGB geregelten Vorschriften für Werkverträge (ständige Rechtsprechung, erstmals: BGH, Urteil vom 11.02.1971, Az. VII ZR 170/69Testauswertung; LG Wiesbaden, Urteil vom 30.11.2016, Az. 11 O 10/15).

Sofern im Vertrag nicht abweichend geregelt, gelten bei Anwendung von Werkvertragsrecht unter anderem die folgenden Prinzipien:

  • Erfolgsorientierung: Gegenstand eines Werkvertrages ist die Herbeiführung eines bestimmten Erfolges (§ 631 II BGB). Anders als beim Dienstvertrag (§§ 611 ff. BGB) muss nicht nur eine bestimmte Handlung vorgenommen, sondern auch ein konkretes Ergebnis geliefert werden. Bei Softwareerstellungsverträgen und im Speziellen App-Entwicklungsverträgen reicht es daher nicht aus, irgendeine Software zu programmieren – die Software muss auch den vertraglich festgelegten Anforderungen entsprechen.
  • Abnahme: Entscheidender Zeitpunkt für das Vorliegen von Mängeln ist die Abnahme (§ 640 BGB). Die Abnahme ist eine Hauptleistungspflicht des Auftraggebers. Mit ihr erklärt er, dass er das geleistete Werk des Auftragnehmers als im Wesentlichen vertragsgemäß akzeptiert. Er kann daher nach Abnahme keine Gewährleistungsrechte für Mängel mehr geltend machen, die bei Abnahme noch ohne Vorbehalt akzeptiert worden waren (§ 640 Abs. 3 BGB).
  • Kündigungsrechte: Die §§ 648, 648a BGB regeln besondere Kündigungsrechte sowohl für den Auftraggeber als auch den Auftragnehmer. Sie regeln außerdem, wie hoch die zu zahlende Vergütung im Falle einer Kündigung ist. 
Beispiel: Kündigt der Besteller nach § 648 S. 1 BGB den Vertrag ohne besonderen Grund, muss er grundsätzlich die gesamte Vergütung zahlen, wobei sich der Auftragnehmer anrechnen lassen muss, was er durch die Kündigung an Aufwendungen spart (§ 648 S. 2 BGB). Gesetzlich vermutet wird in solchen Lagen, dass der Auftragnehmer für Teile der Software, die er noch nicht erstellt hat, 5 % der anteiligen Vergütung verlangen kann (§ 648 S. 3 BGB).
  • Mitwirkungspflichten: Der Auftragnehmer kann vom Auftraggeber verlangen, dass dieser die nötigen Mitwirkungshandlungen vornimmt. In der Praxis sind das vor allem Auskünfte, auf die der Auftragnehmer angewiesen ist (§§ 642, 643 BGB). Wirkt der Auftraggeber nicht oder nicht ausreichend mit, kann der Auftragnehmer Entschädigung verlangen oder den Vertrag nach Fristsetzung kündigen.
  • Aufwendungsersatz nach Selbstvornahme: Ist das Endprodukt mangelhaft, kann der Auftraggeber den Mangel selbst beseitigen und die dafür erforderlichen Kosten vom Auftragnehmer ersetzt verlangen (§ 637 Abs. 1 BGB).

nach oben

b. Dienstvertrag

In bestimmten Fällen kann die Gestaltung eines Vertrags dazu führen, dass kein Werkvertragsrecht, sondern Dienstvertragsrecht anwendbar ist. Das kann vor allem bei Zurufprojekten und agiler Entwicklung der Fall sein. In beiden Fällen erfolgt die Entwicklung iterativ, das heißt in mehreren Schritten und in enger Zusammenarbeit zwischen Auftraggeber und Auftragnehmer.

Der Auftraggeber äußert seine Wünsche, der Auftragnehmer setzt diese bestmöglich (in Sprints) um und führt sein Ergebnis vor. Daraufhin äußert der Auftraggeber Änderungswünsche und der Prozess wiederholt sich. Weil der Auftragnehmer hier im Hinblick auf die App keinen bestimmten Erfolg schuldet, sondern eher eine entwicklungsoffene beratende Tätigkeit stattfindet, liegt eine Einordnung als Dienstvertrag nahe (vgl. Auer-Reinsdorff/Conrad/Schneider, Handbuch IT- und Datenschutzrecht, 3. Auflage 2019, § 11 Rn. 12).

Für die teilweise schwierige Abgrenzung zwischen Werk- und Dienstvertrag stellt der BGH auf den Parteiwillen ab (vgl. BGH, Urteil vom 16.07.2002, Az. X ZR 27/01).

nach oben

c. Werklieferungsvertrag

In der juristischen Literatur wird diskutiert, ob es sich bei Softwareüberlassungsverträgen und damit auch bei App-Entwicklungsverträgen um Werklieferungsverträge im Sinne von § 650 BGB handelt (vgl. Kilian/Heussen/Kremer Computerrechts-Handbuch, 32.4 Rn. 33 ff.). Weil Software von der Rechtsprechung in der Regel als bewegliche Sache im Sinne von § 650 BGB eingeordnet wird, fände grundsätzlich Kaufrecht statt Werkvertragsrecht Anwendung, wenngleich bei der App-Entwicklung über § 650 S. 3 BGB doch einige Werkvertragsvorschriften anwendbar blieben.

Bei der Herstellung von Individualsoftware, das heißt speziell für den Kunde entwickelter Software, wird wiederum teilweise vertreten, dass die Planungsleistungen so im Vordergrund stünden, dass es sich um einen reinen Werkvertrag handele (vgl. Münchener Kommentar zum BGB/Busche, 8. Auflage 2020, § 631 Rn. 142 und § 650 Rn. 12).

nach oben

d. Praxistipps

Der BGH hat behandelt Softwareentwicklungsverträge ohne Erläuterung nach Werkvertragsrecht (vgl. BGH, Urteil vom 05.06.2014, Az. VII ZR 276/13) oder lässt die Frage offen (vgl. BGH, Urteil vom 04.03.2010, Az. III ZR 79/09). Es wird jedoch für möglich gehalten, dass der BGH seine Linie in Zukunft noch einmal ändert (vgl. Auer-Reinsdorff/Conrad/Schneider, Handbuch IT- und Datenschutzrecht, 3. Auflage 2019, § 10 Rn. 34 ff. und § 11 Rn. 15 ff.).

Unsicherheiten bei der Einstufung als Werkvertrag, Dienstvertrag (oder gar Werklieferungsvertrag) können die Vertragsparteien durch Vertragsgestaltung beseitigen, insbesondere durch ausführliche Konkretisierung der Planungsleistungen und des Entwicklungsprozesses.

Soll der Auftragnehmer nach dem App-Entwicklungsvertrag weitgehend eigenständig eine App mit bestimmten Eigenschaften erstellen, ist ein bestimmter Erfolg geschuldet, was die Anwendung von Werkvertragsrecht nahelegt. Erfolgt die App-Entwicklung in einem kooperativen Prozess, bei dem der Auftraggeber durch konkrete Anweisungen erheblichen Einfluss auf die Gestaltung hat, wird es sich eher um einen Dienstvertrag handeln.

Keine taugliche Möglichkeit zur Beeinflussung der Vertragsart ist es, den Vertrag schlicht als Werk- bzw. Dienstvertrag zu bezeichnen, z.B. in der Überschrift (OLG Düsseldorf, Urteil vom 18.07.1997, Az. 22 U 3/97). Welcher gesetzliche Vertragstyp einschlägig ist, beurteilt sich nach inhaltlichen und nicht nach formellen Gesichtspunkten.

Faustregel: Grundsätzlich ist die Entwicklung einer (individuell gestalteten) App für einen Auftraggeber als Werkvertrag einzuordnen. Je mehr der Auftraggeber in den Entwicklungsprozess eingebunden, je weniger klar definiert das angestrebte Endprodukt ist und je mehr Bauteile aus Standardsoftware bestehen, desto genauer ist im Einzelfall zu prüfen, ob nicht doch ein anderer Vertragstyp vorliegt.

nach oben

2. Wichtige Regelungen im App-Entwicklungsvertrag

Die einschlägigen gesetzlichen Regelungen bieten ein Grundgerüst zur Bewältigung von Streitigkeiten im Rahmen eines App-Entwicklungsvertrags. Sie werden den besonderen Dynamiken der App-Entwicklung aber nicht vollständig gerecht. Deshalb empfehlen wir, die folgenden Punkte im App-Entwicklungsvertrag ausdrücklich zu regeln.

Hinweise

Für die Entwicklung mobiler Apps gibt es keine juristische Allgemeinlösung. Jedes App Projekt muss individuell geprüft und eine sachgerechte, passende Vertragslösung erarbeitet werden. Die meisten vertraglichen Gestaltungsmöglichkeiten haben Vor- und Nachteile.

Unsere Muster basieren auf Werkvertragsrecht. Sie stellen lediglich einen Ausgangspunkt für eine mögliche Vertragsgestaltung dar und sollten nicht ungeprüft übernommen werden. Ihre Reihenfolge ist nicht zwingend. Auf allgemeine Klauseln, die bei allen Verträgen geregelt werden sollten und für die sich keine Besonderheiten bei App-Entwicklungsverträgen ergeben (z.B. Vertragsparteien, Schlussbestimmungen), gehen wir nicht gesondert ein.

Wir beraten Sie bei der Gestaltung Ihres individuellen App-Entwicklungsvertrags. Nutzen Sie unsere kostenlose und unverbindliche Ersteinschätzung.

nach oben

a. Vertragsgegenstand: Anforderungen an die App

Die Hauptleistungspflicht des App-Entwicklers als Auftragnehmer besteht in der Programmierung („Herstellung“) der App und deren Überlassung an den Auftraggeber. Eine Herstellung liegt auch vor, wenn der Entwickler wie heute üblich auf bereits vorhandene Bibliotheken und bestimmte Programmtechniken zurückgreift und die App dadurch in weiten Teilen aus bereits existenten Teilen zusammensetzt und nur noch bestimmte Teilbereiche individuell programmiert bzw. anpasst. Unter Umständen handelt es sich dann aber um einen Werklieferungsvertrag.

Um späteren Zweifeln vorzubeugen, ob die fertige App vertragsgemäß oder mangelhaft ist, sollten die Anforderungen möglichst präzise beschrieben werden. Hierzu empfiehlt sich ein Vorgehen in zwei Schritten:

nach oben

aa. Grobe Beschreibung des Vertragsgegenstandes

Bereits im Hauptvertrag sollte die zu entwickelnde App als Vertragsgegenstand so beschrieben werden, dass beide Parteien zumindest eine ungefähre Vorstellung vom Endprodukt haben. Die folgende Punkte sollten ausdrücklich erwähnt werden:

  • Funktionen der App
  • Art der App (Web-App oder native App, s.o.)
  • Plattform, auf der die App erscheinen soll
  • Besondere Einzelhandlungen, die zum Erreichen des angezielten Erfolges nötig sind (z.B. Installation, Migration von Daten)

Schon an dieser Stelle kann die Bezugnahme auf das Lastenheft als zweiten Schritt erfolgen.

Muster

§ 1 Vertragsgegenstand

1.1 Gegenstand dieses App-Entwicklungsvertrags ist die Planung, Erstellung und Lieferung der Software mit dem Projekttitel [App-Name bzw. Arbeitstitel] als native mobile App mit den Funktionen [Funktion 1], [Funktion 2] und [Funktion 3] zum Vertrieb an Dritte auf den Plattformen bzw. App Stores der Betreiber [Plattformbetreiber 1] und [Plattformbetreiber 2].

1.2 Die fachliche Feinspezifikation ist in der Ausarbeitung vom [Datum] von [Name, ggf. Versionsnummer], festgehalten und beschreibt den Leistungsumfang der vom Auftragnehmer zu erstellenden App. Sie ist Vertragsbestandteil und als Anlage 1 beigefügt.

1.3 […]

nach oben

bb. Spezifische Anlagen

Die App-Anforderungen sollten grundsätzlich sowohl in fachlicher Hinsicht als auch in technischer Hinsicht konkretisiert werden. Hierbei ergeben sich Unterschiede je nachdem, ob nach dem Wasserfallmodell oder nach agilen Methoden entwickelt wird. Agile Softwareentwicklung dürfte mittlerweile Entwicklungsstandard geworden sein oder sich zumindest auf dem Weg dorthin befinden. Wir stellen nachfolgend beide Herangehensweisen kurz dar:

Beim klassischen Wasserfallmodell richtet sich die Entwicklung der Software nach den Inhalten von Lastenheft und Pflichtenheft.

Die Begriffe werden in der Praxis und von der Rechtsprechung nicht immer trennscharf, teilweise sogar gegensätzlich verwendet. Von Juristen wird das Lastenheft (oder auch Lasten- und Pflichtenheft gemeinsam) häufig schlicht als „Pflichtenheft“ bezeichnet (Redeker, IT-Recht, Rn. 314). Im Sinne der für die IT-Branche maßgeblichen DIN/VDI-Vorschriften unterscheiden sie sich aber wie folgt:

Das Lastenheft bestimmt, was die geschuldete Software leisten muss. Das Lastenheft ist daher eher ergebnisbezogen und enthält eine fachliche Spezifikation der geschuldeten Leistung. Für einen sinnvoll durchführbaren App-Entwicklungsvertrag sollte ein Lastenheft vorliegen (vgl. Schneider/v. Westphalen, Software-Erstellungsverträge 2. Auflage 2013, D. Rn. 8). Das gilt zumindest für große bzw. komplexe Projekte.

Das Pflichtenheft knüpft an das Lastenheft an und beschreibt die konkreten technischen Entwicklungsschritte, die ergriffen werden müssen, um das im Lastenheft beschriebene Ziel zu erreichen. Das Pflichtenheft ist deshalb eher prozessbezogen und enthält eine technische Spezifikation. Im Gegensatz zum Lastenheft können die Inhalte des Pflichtenhefts auch erst bei der Vertragserfüllung entwickelt werden, d.h. bei Vertragsschluss muss nicht zwingend ein vollständiges Pflichtenheft vorliegen.

Wesensmerkmal agiler Entwicklung ist demgegenüber, dass zu Beginn des Projekts regelmäßig noch kein fixer Plan der App existiert. Die konkrete Ausgestaltung der Software formt sich erst im Laufe der Zusammenarbeit. Trotzdem darf agile Entwicklung nicht so verstanden werden, dass keine funktionale Leistungsbeschreibung notwendig wäre. Analog zum Lastenheft wird bei agiler Entwicklung ein Product Backlog angefertigt mit einer Beschreibung der Anforderungen an das Endprodukt. Das Product Backlog wird während des Entwicklungsprozesses laufend angepasst.

Sprint Backlogs wiederum splitten die zu bearbeitenden Anforderungen des Product Backlogs in zahlreiche (kleine) konkret umrissene Programmieraufgaben für die Entwickler auf, sog. Sprints.

Beispiele für Inhalte des Product Backlogs

  • Systemanforderungen
  • User Stories: Formulierung der Wünsche des Benutzers und Aufstellung von sog. Akzeptanzkriterien für deren Erreichung
  • gesetzliche Vorgaben zu Datenschutz, IT-Sicherheit etc.

nach oben

b. Lieferung der App / Herausgabe des Quellcodes

Die Ablieferung der finalen App beim Auftraggeber kann auf verschiedene Weisen erfolgen:

  • Der Entwickler übergibt die App auf einem Datenträger an den Auftraggeber. Der Auftraggeber muss die App dann selbst im App-Store anmelden.
  • Der Entwickler meldet die App für den Auftraggeber im App-Store an. Dies sollte im Vertrag ausführlich geregelt werden.

Zur ordnungsgemäßen Lieferung der App gehört die Erstellung einer mangelfreien Dokumentation (BGH, Urteil vom 04.11.1992, Az. VIII ZR 165/91), die aber erst zum Zeitpunkt der Abnahme vorliegen muss (OLG Frankfurt, Urteil vom 17.08.2017, Az. 5 U 152/17; anders noch die Vorinstanz: LG Wiesbaden, Urteil vom 20.11.2016, Az. 11 O 10/15), was vor allem für Ansprüche auf Teilvergütung im Rahmen von agiler Softwareentwicklung bedeutsam sein kann.

Dringend sollte im App-Entwicklungsvertrag festgelegt werden, ob und unter welchen Voraussetzungen der Quellcode herauszugeben ist.

  • Besteht die App weitgehend aus Standardsoftware, die nur geringfügig modifiziert wurde, hat der Entwickler ein Interesse daran, die erneute wirtschaftliche Verwendung der Softwarebestandteile durch eine Zurückbehaltung des Quellcodes zu sichern.
  • Wurde die App hingegen weitgehend individuell für den Auftraggeber entwickelt, kann wahrscheinlich ohnehin nur eine einmalige wirtschaftliche Verwertung erfolgen. Zudem sind im Laufe des Entwicklungsprozesses mehr Fachwissen und Ideen des Auftraggebers in das Projekt eingeflossen, die teilweise sogar Betriebsgeheimnisse berühren können, so dass sich das Interesse zugunsten des Auftraggebers verschiebt (vgl. Münchener Anwaltshandbuch IT-Recht/von dem Bussche/Schelinski, 3. Auflage 2013, Rn. 283 ff.). Für den Auftraggeber kann eine Herausgabe des Quellcodes besonders wichtig sein, wenn kein anschließender Pflegevertrag für die App abgeschlossen wird. Dann muss er selbst Änderungen vornehmen (lassen) können, z.B. wenn sich die technischen Voraussetzungen des App-Stores ändern.

Eine vermittelnde Lösung kann Quellcodehinterlegung (Software-Escrow) sein.

Fehlt im App-Entwicklungsvertrag eine ausdrückliche Regelung zur Herausgabe des Quellcode, ist auf Vertragszweck und Vergütungshöhe abzustellen (vgl. BGH, Urteil vom 16.02.2003, Az. X ZR 129/01).

Muster

§ 3 Lieferung

Der Auftragnehmer liefert die App, indem er sie im App Store anmeldet und bereitstellt. Eine Übergabe des Quellcodes schuldet er nicht. Updates sind in gleicher Weise zu liefern.

nach oben

c. Einräumung von Nutzungsrechten

Der Entwickler schuldet die Übertragung der notwendigen Nutzungsrechte an der mobilen App.

Bei Individualprogrammierung ist die Einräumung ausschließlicher Nutzungsrechte der Regelfall. Bei Apps, die überwiegend aus Standardsoftware zusammengesetzt sind, werden dagegen in der Regel nur einfache Nutzungsrechte eingeräumt, damit der App-Entwickler die Software(bestandteile) auch an Dritte veräußern kann. Eine Kombination ist denkbar, wenn der Auftragnehmer sowohl Standardmodule als auch Individualanteile liefert (vgl. Redeker/Witte, Handbuch der IT-Verträge, 1.4 Rn. 74a).

Die Wichtigkeit einer vertraglichen Regelung der Nutzungsrechtseinräumung kann nicht überbetont werden. Fehlt im App-Entwicklungsvertrag eine ausdrückliche Regelung, greift die urheberrechtliche Zweckübertragungslehre (§ 31 Abs. 5 UrhG), wonach der Auftraggeber nur in dem Umfang Nutzungsrechte eingeräumt bekommt, der für die Erreichung des Vertragszwecks unbedingt erforderlich ist. Im Zweifel bedeutet dies, dass der Auftraggeber nur einfache Nutzungsrechte erhält, wenn sich aus dem Vertrag mit dem Entwickler nicht ergibt, dass ausschließliche Nutzungsrechte zur Erreichung des Vertragszwecks zwingend erforderlich sind.

Im App-Entwicklungsvertrag ist für jede in Betracht kommende Nutzungsart ausdrücklich zu regeln, ob und in welchem Umfang einfache bzw. ausschließliche Nutzungsrechte eingeräumt werden. Es ist dringend zu empfehlen, alle wichtigen Nutzungsarten zu benennen und die Einräumung der Nutzungsrechte unter die Bedingung einer vollständigen Zahlung der geschuldeten Vergütung zu stellen.

Muster (für die Einräumung eine ausschließlicher Nutzungsrechte)

§ 4 Rechtsübertragung

(1) Mit der vollständigen Zahlung der Vergütung erwirbt der Auftraggeber das umfassende, ausschließliche, sich auf alle bekannten Nutzungsarten beziehende zeitlich unbegrenzte Recht, die vertragsgegenständliche App in Objekt- und Quellcode zu nutzen. Dazu zählen insbesondere:

(a) das Recht zur dauerhaften oder vorübergehenden Vervielfältigung, ganz oder teilweise, mit jedem Mittel und in jeder Form, insbesondere im Rahmen des Cloud-Computings und des Angebots an die Öffentlichkeit,

(b) das Recht zur umfassenden Bearbeitung und Veränderung der App, bspw. zur Anpassung an geänderte Einsatzbedingungen oder zur Verbindung mit Leistungen anderer,

(c) […]

(2) […]

nach oben

d. Vergütung / Preis und Zahlungsweise

Wenn die Vertragsparteien keine Vergütung vereinbaren, gilt regelmäßig eine marktübliche Vergütung als vereinbart (§ 632 BGB für Werkverträge, § 612 BGB für Dienstverträge). In der Praxis wird es freilich nur selten an einer Vergütungsvereinbarung fehlen.

Die Vergütung kann auf verschiedene Weisen erfolgen:

  • Pauschalfestpreis (→ typischerweise im Interesse des Auftraggebers)
  • Aufwandsbezogen (→ typischerweise im Interesse des App-Entwicklers)
  • Aufwandsbezogen mit Obergrenze (→ der App-Entwickler trägt das Risiko einer Überschreitung des Kostenanschlags, vgl. § 649 Abs. 1 BGB)
  • Aufwandsbezogen mit Bonus (→ vielfältige und teilweise komplexe Gestaltungsmöglichkeiten)

Je nach Art der Vergütung empfehlen sich Regelungen zu Fälligkeit und Zahlungsweise. Ein Festpreis wird standardmäßig mit Abnahme der App fällig (§ 641 BGB). Gängig sind aber auch gestaffelte Zahlungen nach Projektfortschritt.

Muster (für Pauschalfestpreis mit gestaffelter Zahlung)

§ 6 Vergütung

(1) Der Gesamtpreis für die Herstellung und Überlassung der App mitsamt aller in diesem Vertrag geregelten Nebenleistungen beträgt [Betrag] Euro.

(2) Die Zahlungen erfolgen abhängig vom Fortschritt des Projekts in folgender Reihenfolge:

a) Bei Übergabe des Pflichtenheftes: [Betrag] Euro

b) Nach Abnahme der App: [Betrag] Euro

c) Nach Ablauf der Verjährungsfrist für Mängelansprüche: [Betrag] Euro (Anm.: Hier ist der Restbetrag einzufügen. Alternativ kann auch eine Mängelbürgschaft vereinbart werden)

nach oben

e. Mitwirkungserfordernisse

Den Auftraggeber können bestimmte Mitwirkungsobliegenheiten treffen, unter Umständen sogar Mitwirkungspflichten. Im Gegensatz zu Obliegenheiten kann der Auftragnehmer vom Auftraggeber die Erfüllung von Mitwirkungspflichten rechtlich einfordern und ggf. einklagen. Die Verletzung von Obliegenheiten kann aber zu anderen Rechtsnachteilen führen, z.B. einem Ausschluss von Gewährleistungsrechten (so im Falle der handelsrechtlichen Rügeobliegenheit nach § 377 HGB).

Im besten Falle werden Mitwirkungspflichten ausdrücklich vertraglich geregelt und dabei explizit als Pflichten benannt. Andernfalls kann die Abgrenzung zu bloßen Obliegenheiten Probleme bereiten. Mitwirkungspflichten des Auftraggebers bei einem App-Entwicklungsvertrag können beispielsweise sein:

  • Erstellung des Pflichtenhefts nach vorgegebenen Maßstäben
  • Mitteilung von für die App-Entwicklung erforderlichen Informationen
  • Festlegung eines Ansprechpartners für den App-Entwickler bei Rückfragen

Muster

§ 7 Mitwirkungspflichten des Auftraggebers

(1) Der Auftraggeber verpflichtet sich, dem Auftragnehmer alle zur vereinbarten Programmierung der App erforderlichen Auskünfte auf eigene Kosten zu erteilen. Hierzu benennt er einen festen Ansprechpartner, der in einem zeitlich angemessenen Umfang zur Verfügung steht.

(2) […]

nach oben

f. Projektphasen / Zeitplan

Wie bereits betont, ist bei der Vertragsdurchführung zur Vermeidung von Unklarheiten oder Streitigkeiten eine möglichst präzise Festlegung der jeweiligen Pflichten anzuraten. Das kann auch durch eine Regelung der Abläufe der Projektdurchführung erreicht werden. Gewöhnlich wird dazu ein Aktivitäten- und Fristenplan erstellt („Masterplan“), in dem geregelt wird,

  • wer
  • wann
  • welchen Schritt des Projekts
  • bis wann

ausführt. Dieser Aktivitäten- und Fristenplan wird dem Vertrag als Anlage angefügt und in Bezug genommen. Ob im Einzelfall ein Aktivitäten- und Fristenplan erstellt werden sollte, hängt von Umfang und Komplexität des Projekts ab. Vor allem bei phasenweisem Vorgehen ist dies zu empfehlen.

Unabhängig davon, ob ein konkreter Aktivitäten- und Fristenplan oder nur ein bloßes Lieferdatum festgelegt werden, sollte eine Klausel den Umgang mit unverschuldeten Leistungsverzögerungen (z.B. behördliche Anordnungen, Störungen der TK-Infrastruktur) festlegen.

Muster

§ 8 Zeitplan

(1) Die Leistungen sind bis zum [Datum] vollständig abnahmebereit zu erbringen. Die einzelnen Schritte des Projekts sind bis zu den im als Anlage 2 beigefügten Aktivitäten- und Fristenplan geregelten Zeitpunkten zu erbringen.

(2) Der Auftragnehmer zeigt dem Auftraggeber Leistungsverzögerungen unverzüglich an. Verzögerungen wegen höherer Gewalt, insbesondere Streik und Störungen der Infrastruktur, sowie Verzögerungen wegen nicht rechtzeitig erbrachter Mitwirkungsleistungen des Auftraggebers hat der Auftragnehmer nicht zu vertreten. Er ist in diesen Fällen berechtigt, die Leistungserbringung um einen angemessenen Zeitraum hinauszuschieben.

nach oben

g. Weitere (Neben-)Pflichten

Je nach vereinbartem Leistungsumfang treffen den Auftragnehmer neben der Erstellung und Überlassung der App eine Reihe von Nebenpflichten. Es kommen insbesondere in Betracht:

  • Einweisung, Schulung und Beratung
  • Parametrisierung
  • Migration
  • Geheimhaltung
  • ggf. Pflege / Instandhaltung (hier wird oftmals ein eigenständiger Pflegevertrag abgeschlossen)

Empfehlung: Je präziser die geschuldete Leistung formuliert ist, desto geringer ist die Wahrscheinlichkeit von rechtlichen Streitigkeiten und Problemen.

nach oben

h. Abnahme

Besondere Bedeutung haben die Regelungen zur Abnahme der App. Der Auftraggeber billigt das gelieferte Produkt durch die Abnahme als im Wesentlichen vertragsgemäß (§ 640 Abs. 1 BGB). Damit ist eine Reihe von Rechtsfolgen verbunden:

  • Beginn der Verjährungsfrist von Mängelansprüchen (§ 634a Abs. 2 BGB)
  • Ausschluss von Gewährleistung für bekannte Mängel (§ 640 Abs. 3 BGB)
  • Fälligkeit der Vergütung (§ 641 BGB)
  • Übergang der Gefahr für zufällige Verschlechterung/Untergang auf den Auftraggeber (§ 644 BGB)

Um die Mängelfreiheit zu überprüfen, muss der Auftraggeber die App auf ihre (im Lastenheft/Pflichtenheft spezifizierte) Funktionalitäten testen. Die Abnahme ist eine Hauptleistungspflicht des Auftraggebers. Kommt er dieser nicht nach und hat der Auftragnehmer erfolglos eine angemessene Frist zur Abnahme gesetzt, greift gemäß § 640 Abs. 2 S. 1 BGB eine Abnahmefiktion, nach der die oben genannten Rechtsfolgen auch ohne Abnahmeerklärung des Auftraggebers eintreten.

Zur Vermeidung von Streitigkeiten sollte das Abnahme-Prozedere im App-Entwicklungsvertrag geregelt sein. Bei größeren Projekten kann der Zeitpunkt der Abnahme beispielsweise erheblich hinter der Bereitstellung der App zur Abnahme liegen, damit ein längerer Testlauf (z.B. 1 Monat) möglich wird. Über die Abnahme selbst sollte ein Abnahmeprotokoll erstellt werden.

Muster

§ 9 Abnahme

(1) Auftraggeber und Auftragnehmer führen im Rahmen der Abnahme bei beidseitiger Anwesenheit folgende Tests in folgender Testumgebung durch:

(a) […]

(b) […]

(2) Der Auftraggeber prüft hierbei die Leistungen des Auftragnehmers auf ihre Vertragsmäßigkeit. Stellt der Auftrageber Mängel fesr, die nicht unwesentlich im Sinne von § 640 Abs. 1 S. 2 BGB sind, wird er diese gegenüber dem Auftragnehmer geltend machen. [Das Vorliegen von Mängeln richtet sich nach der fachlichen Feinspezifikation in Anlage 1.] Bei Mängelfreiheit nimmt der Auftraggeber das Werk ab.

(3) Im Rahmen der Abnahme wird ein schriftliches Abnahmeprotokoll erstellt, das Teilnehmer, Ort, Zeit, technische Umstände und Ergebnisse der Tests festhält. Das Protokoll ist von Auftraggeber und Auftragnehmer zu unterschreiben.

nach oben

i. Mängel / Gewährleistung

Die Abnahme dreht sich stark um den Mangelbegriff. Wann ein Mangel vorliegt, regelt grundsätzlich § 633 BGB, dort insbesondere § 633 Abs. 2 S. 1 BGB (Nichtvorliegen der vereinbarten Beschaffenheit). Erneut kommt es hier maßgeblich auf eine präzise Leistungsbeschreibung an. Je genauer Lasten- und Pflichtenheft die von der App zu erfüllenden Anforderungen regeln, desto besser lässt sich eine negative Abweichung feststellen.

Ist die App mangelhaft, kann der Auftraggeber die Abnahme verweigern (§ 640 Abs. 1 S. 1 BGB). Tritt der Mangel erst nach der Abnahme zutage, stehen dem Auftraggeber die in § 634 BGB geregelten Ansprüche zu:

  • Nacherfüllung (§§ 634 Nr. 1, 635 BGB): Der Auftragnehmer kann sich aussuchen, ob er den Mangel am Produkt beseitigt oder ein neues mangelfreies Werk herstellt.
  • Aufwendungsersatz nach Selbstbeseitigung (§§ 634 Nr. 2, 637 BGB): Der Auftraggeber kann, wenn er dem Auftragnehmer erfolglos eine angemessene Frist zu Nacherfüllung gesetzt hat, den Mangel auf dessen Kosten selbst beheben (lassen).
  • Rücktritt (§§ 634 Nr. 3, 323, 326 Abs. 5, 636 BGB): Der Auftraggeber kann nach erfolgloser Setzung einer Nachfrist (in bestimmten Ausnahmefällen auch ohne Fristsetzung, vgl. § 636 BGB) vom Vertrag zurücktreten. Bereits gewährte Leistungen sind dann gem. §§ 346 ff. BGB zurück zu gewähren.
  • Minderung (§§ 634 Nr. 3, 638 BGB): Statt eines Rücktritts (also unter denselben Voraussetzungen) kann der Auftragnehmer eine in Anbetracht des Mangels entsprechend verminderte Vergütung zahlen.
  • Schadensersatz (§§ 634 Nr. 4, 280 ff., 311a BGB): Hat der Auftragnehmer die mangelhafte Lieferung im Sinne von § 276 BGB verschuldet, muss er dem Auftraggeber entstandene Schäden ersetzen.

Teilweise finden sich in App-Entwicklungsverträge sog. Mangelkategorien. Hierbei verständigen sich die Vertragsparteien im Vornherein darauf, wie bestimmte Arten von Mängeln rechtlich zu bewerten sind und schließen bspw. für als „leicht“ eingestufte Mängel bestimmte Gewährleistungsrechte wie den Rücktritt aus oder treffen besondere Anforderungen an die Nacherfüllung. Ebenfalls wird teilweise die gesetzliche Verjährungsfrist von zwei Jahren (§ 634a Abs. 1 Nr. 1 BGB) verkürzt oder verlängert.

Für den App-Entwickler kann es sinnvoll sein, eine Klausel in den Vertrag aufzunehmen, nach der sich das Vorliegen von Mängeln allein an der fachlichen Feinspezifikation orientiert, also dem Pflichten- und Lastenheft (so auch Auer-Reinsdorff/Conrad/Schneider, Handbuch IT- und Datenschutzrecht, 3. Auflage 2019, § 11 Rn. 87). Dadurch kann er sein Haftungsrisiko auf die dort geregelten überschaubaren Anforderungen beschränken und Diskussionen über weitergehende Mängel vorbeugen. Im Falle einer solchen Vereinbarung müssen die fachlichen und technischen Anforderungen im Lasten- und Pflichtenheft natürlich sehr spezifisch geregelt sein.

Muster

§ 10 Mängelhaftung

(1) Nacherfüllungsansprüche verjähren in zwölf Monaten.

(2) Die vereinbarte Beschaffenheit der geschuldeten App ergibt sich allein aus der als Anlage 1 beigefügten fachlichen Feinspezifikation.

(3) […]

nach oben

j. Change Requests

Gerade bei agilen Entwicklungsmethoden (sog. „Product Backlog Refinement“), aber auch bei der Entwicklung im klassischen Wasserfall-Modell, treten häufig Änderungswünsche des Auftraggebers am ursprünglichen Projekt auf, teilweise sogar auf Anregung des Auftragnehmers.

Grundsätzlich gilt, dass kein gesetzlicher Anspruch auf Änderung eines bereits festgelegten Vertragsgegenstandes existiert. Nur bei ganz außergewöhnlichen Umständen kommt ein Anspruch auf Änderung wegen Wegfalls der Geschäftsgrundlage in Betracht (§ 313 BGB). Bloße Opportunitätserwägungen genügen dafür allerdings nicht.

Wegen der Häufigkeit von Change Requests in der Praxis sollte ein Verfahren für den Umgang mit Änderungswünschen in den Vertrag integriert werden einschließlich der Folgen für Fristen und Kosten.

Muster für Change Request Management (angelehnt an Beck’sches Formularbuch IT-Recht/Imhof, C.5 § 5):

§ 11 Vorgehen bei Änderungswünschen

(1) Der Auftraggeber kann jederzeit schriftlich Änderungswünsche am vereinbarten Leistungsgegenstand gegenüber dem Auftragnehmer äußern. Bei geringen Änderungswünschen, die innerhalb von [Zahl] Arbeitsstunden umgesetzt werden können, kann der Auftragnehmer diese ohne das in den Absätzen 2-4 geregelte Verfahren umsetzen.

(2) Nach Eingang eines Änderungswunsches prüft der Auftragnehmer diese auf seine Umsetzbarkeit und die erwarteten Auswirkungen auf Vergütung, Termine und sonstige Vereinbarungen. Je nach Umfang und Dauer der Prüfung ist der Auftragnehmer berechtigt, Termine für Leistungen um angemessene Zeit zu verschieben.

(3) Der Auftragnehmer teilt dem Auftraggeber das Ergebnis der Prüfung unverzüglich mit und entwickelt einen Vorschlag für die Umsetzung des Änderungswunsches oder teilt die Gründe für die Nichtumsetzbarkeit mit. Die Vertragsparteien beginnen unverzüglich mit den Abstimmungen über die Veränderungen.

(4) Werden sich die Vertragspartner über die Änderungen einig, werden diese als Nachtragsvereinbarungen dem Vertragstext beigefügt. Dabei werden vom Änderungsverfahren betroffene Termine soweit erforderlich verschoben. Scheitern die Verhandlungen, verbleibt es beim ursprünglichen Leistungsumfang.

(5) Die Kosten des Änderungsverfahrens, inklusive der Prüfung des Änderungswunsches und des Erstellens des Änderungsvorschlags, trägt der Auftraggeber. Sie bemessen sich nach der üblichen Vergütung des Auftragnehmers.

nach oben

k. Anmeldung im App Store

Wenn die Anmeldung der App im jeweiligen App Store zum Pflichtenprogramm des App-Entwicklers zählen soll, ist es wichtig klarzustellen, dass es sich um eine Dienstleistung und keine werkvertragliche Pflicht handelt, d.h. kein Erfolg in Gestalt der Aufnahme in den App-Store geschuldet ist.

Die Betreiber der App Stores behalten sich nämlich vor, die Zulassung von Apps ohne Begründung zu verweigern, weshalb die Erreichung der Aufnahme in den App Store nicht in der Macht des App-Entwicklers liegt (vgl. Lachenmann, ITRB 2013, 190).

Muster

§ 12 Anmeldung im App Store

Der Auftragnehmer meldet die App nach Fertigstellung in den oben festgelegten App Stores von [Plattform A] und [Plattform B] an. Über die Vornahme der Anmeldehandlung hinaus schuldet der Auftragnehmer nicht die Zulassung der App durch den Betreiber des App Stores. Der Kunde wird darauf hingewiesen, dass der Betreiber die Einstellung der App in seinen App Store ohne Begründung ablehnen kann.

nach oben

l. Kündigungsrechte

Das Werkvertragsrecht sieht eine Reihe von Kündigungsrechten vor. Diese bieten grundsätzlich ein System, das den Interessen beider Vertragsparteien Rechnung trägt und angemessene Lösungen im Einzelfall ermöglicht. Ein vertraglich vereinbarter Ausschluss aller Kündigungsrechte wäre in Form von Allgemeinen Geschäftsbedingungen in jedem Fall unwirksam und ist auch als Individualvereinbarung nicht zu empfehlen (vgl. BGH, Urteil vom 27.01.2011, Az. VII ZR 133/10; Lachenmann IRTB 2013, 190, 193).

Angepasst werden sollte jedoch die Rechtsfolge einer Kündigung des Auftraggebers gemäß § 648 BGB. Nach § 648 S. 3 BGB wird vermutet, dass dem Auftragnehmer für noch nicht erbrachte Leistungen nur 5 % der anteiligen Vergütung zusteht. Diese Prozentzahl wird Softwareprojekten nicht gerecht, da hier regelmäßig Gewinnspannen um 50 % kalkuliert werden. Entsprechend sollte der App-Entwickler für den Fall einer Kündigung durch den Auftraggeber einen Pauschalbetrag in vergleichbarer Höhe in den Vertrag aufnehmen lassen (vgl. ausführlich dazu Redeker, ITRB 2012, 42).

Muster (nach Redeker, ITRB 2012, 42).

§ 13 Kündigung

Eine Kündigung ist nach Maßgabe der gesetzlichen Vorschriften möglich. Im Falle einer grundlosen Kündigung des Auftraggebers nach § 648 BGB steht dem Auftragnehmer ein Wahlrecht zu zwischen den gesetzlichen Ansprüchen nach § 648 BGB und einem Pauschalbetrag i.H.v. 50 % der Vergütung für die noch nicht erbrachten Leistungen zzgl. der Vergütung für bereits erbrachte Leistungen. Der Auftraggeber bleibt berechtigt, nachzuweisen, dass der dem Auftragnehmer zustehende Betrag nach § 648 BGB geringer ist.

nach oben

m. Ansprüche Dritter

In der IT-Branche kommt es häufig zu Problemen mit Schutzrechten, insbesondere dem Urheberrecht. So kann es dem Auftraggeber passieren, dass er die vom Auftragnehmer entwickelte App einsetzt und ein Dritter ihm gegenüber eine Urheberrechtsverletzung geltend macht. Der Auftraggeber wird allerdings selbst nur selten einschätzen können, ob die geltend gemachten Ansprüche bestehen, d.h. ob die App wirklich fremde Urheberrechte verletzt.

Der Auftraggeber wird deshalb berechtigterweise eine Klausel in den Vertrag aufnehmen wollen, in dem die Rechtsstreitigkeiten auf den Auftragnehmer abgewälzt werden. Dieser sollte in diesem Fall wiederum darauf achten, dass der Auftragnehmer ihm alle wichtigen Informationen erteilt und er selbst alle Entscheidungen im Rechtsstreit (z.B. über einen Vergleich) treffen darf.

Muster (nach Schneider/Westphalen/Redeker, Software-Erstellungsverträge, 2. Auflage 2013, D. Rn. 481)

§ 14 Geltendmachung von Rechten durch Dritte

(1) Macht ein Dritter wegen der vom Auftragnehmer gelieferten App Ansprüche gegenüber dem Auftraggeber aus Urheberrechten, Patenten oder sonstigen gewerblichen Schutzrechten geltend, übernimmt der Auftragnehmer auf eigene Kosten die Vertretung des Auftraggebers in dem jeweiligen Rechtsstreit und stellt ihn hinsichtlich der Drittansprüche frei.

(2) Der Auftraggeber setzt den Lieferanten unverzüglich über Anspruchsschreiben Dritter und alle Einzelheiten etwaiger Rechtsschritte in Kenntnis. Er überlässt dem Auftragnehmer alle Entscheidungen hinsichtlich der weiteren Verwendung der App, der Rechtsverteidigung sowie eines Vergleichsabschlusses.

(3) Die Pflichten des Auftragnehmers nach Absatz 1 bestehen nicht, wenn der Auftraggeber gegen seine Pflichten aus Absatz 2 verstößt oder wenn bei Unterrichtung des Auftragnehmers Ansprüche wegen Rechtsmängeln bereits verjährt sind.

nach oben

3. Besonderheiten und Probleme bei vorformulierten Verträgen (AGB)

Unsere hier genannten Klauselvorschläge gehen von einem Szenario aus, in dem der Vertrag zwischen App-Entwickler und App-Anbieter individuell verhandelt und erstellt wird. In der Praxis verwenden viele Unternehmer aber häufig auch vorbereitete Standardverträge. Diese stellen Allgemeine Geschäftsbedingungen (AGB) im Sinne der §§ 305 ff. BGB dar. Die Regelungsmöglichkeiten in AGB sind im Vergleich zu individuellen Vereinbarungen begrenzt. Viele Vereinbarungen, die App-Entwickler und App-Anbieter individuell wirksam treffen könnten, sind als AGB unwirksam.

Beispiele für unwirksame AGB

  • Erfordernis der Setzung einer Nacherfüllungsfrist, auch wenn diese nach §§ 323 Abs. 2, 326 Abs. 5, 636 BGB ausgeschlossen wäre (BGH, Versäumnisurteil vom 06.06.2013, Az. VII ZR 355/12).
  • Haftungsbeschränkende Klausel „Software ist niemals mangelfrei. Unwesentliche Abweichungen vom erteilten Auftrag sind zulässig und kein Mangel der Software“ (Kilian/Heussen/Kremer, Computerrechts-Handbuch, 32.4. Rn. 117).
  • Beschränkung von Gewährleistungsrechten im Sinne von § 309 Nr. 8 BGB. Diese Vorschrift gilt gemäß § 310 Abs. 1 S. 1 BGB zwar nicht unmittelbar im Verhältnis zwischen Unternehmern (B2B), entfaltet aber faktisch eine starke Indizwirkung für eine unangemessene Benachteiligung im Sinne von § 307 Abs. 1 BGB (vgl. BGH, Urteil vom 26.02.2016, Az. V ZR 208/14).
  • Dynamischer Verweis auf Bedingungen der App-Store-Betreiber zur Beschreibung der geschuldeten Leistung (vgl. Kremer, CR 2011, 769, 775).

nach oben

4. Checkliste

Zusammenfassend sollte Ihr App-Entwicklungsvertrag mindestens Regelungen zu folgenden Punkten enthalten:

☐ Vertragsgegenstand, ggf. Spezifizierung durch Lasten-/Pflichtenheft
☐ Lieferung der App
☐ Herausgabe des Quellcodes
☐ Übertragung von Nutzungsrechten (einfach/ausschließlich?)
☐ Vergütung und Zahlungsweise
☐ Mitwirkung des Auftraggebers
☐ Projektphasen/Zeitplan
☐ zusätzliche Leistungen (Nebenpflichten)
☐ Abnahme
☐ Mängel und Gewährleistung
☐ Change Requests
☐ Anmeldung im App Store
☐ Kündigungsrechte
☐ Geltendmachung von Schutzrechten durch Dritte

Wir beraten Sie bei Rechtsfragen zu mobilen Apps. Nutzen Sie unsere kostenlose und unverbindliche Ersteinschätzung.

nach oben

III. App-Entwickler / Auftraggeber ↔ App-Store

Das Verhältnis zwischen dem Anbieter einer App und dem Betreiber des App-Stores, in welchem die App vertrieben wird, ist durch ein erhebliches Machtgefälle zugunsten des App-Store-Betreibers geprägt. Dieser gibt Lizenz- und Nutzungsbedingungen vor, die der App-Anbieter grundsätzlich nicht beeinflussen, sondern nur zustimmen oder auf einen Vertrieb über die Plattform verzichten kann. Individuelle Absprachen mit einzelnen Anbietern sind äußerst selten.

Die Lizenz- und Nutzungsbedingungen zielen in erster Linie darauf ab, für die App-Store-Betreiber vorteilhafte Regelungen zu schaffen.

Beispiele: Apple: iDPLA, englisch; Google: Android Market – Vereinbarung für den Entwicklervertrieb, deutsch)

Besonders bei der Prüfung von Apps zur Aufnahme in den Store behalten sich die Betreiber der App Stores weite Spielräume vor. Viele der Regelungen wären nach deutschem Recht wohl unwirksame AGB (ausführlich dazu: Kremer, CR 2011, 769), haben aber nach dem anwendbaren kalifornischen Recht in der Praxis Bestand.

Im Ergebnis ist der App-Anbieter dem guten Willen der App-Store-Betreiber weitgehend ausgeliefert und muss sich auf deren Spielregeln einlassen.

nach oben

IV. App-Entwickler/ Auftraggeber ↔ Nutzer

Das Verhältnis zwischen App-Anbieter und den Endnutzern der App ist umstritten. Weil der Nutzer die App über den App Store erwirbt, entsteht der Vertrag über den Erwerb der App nach wohl herrschender Ansicht zwischen dem Betreiber des App Stores und dem Nutzer, nicht zwischen App-Anbieter und Nutzer, wobei teilweise zwischen den verschiedenen App-Stores differenziert wird (vgl. Kilian/Heussen/Ewald, Computerrechts-Handbuch, 32.7. Rn. 46 ff m.w.N.). Rechtsprechung zur Thematik existiert bislang soweit ersichtlich noch nicht.

Im Gegensatz zum Erwerb der App sind In-App-Käufe („In-App-Purchases“) rechtlich geklärt. Hier entsteht ein Vertrag zwischen App-Anbieter und Nutzer.

Beispiele: Erwerb von Erweiterungen, besonderen Features oder ähnlichen Leistungen direkt in der App.

Häufig sind In App Käufe als Rechtskäufe gemäß § 453 BGB zu qualifizieren (Bisges, NJW 2014, 183). Auch die ggf. vom Anbieter in der App verwendeten AGB (häufig „Nutzungsbedingungen“ genannt) sind nach allgemeinen Regeln zu bewerten.

Weil der Nutzer in der Regel Verbraucher ist, stellen In-App-Käufe regelmäßig Fernabsatzverträge dar (§§ 312b ff. BGB), weshalb nach §§ 312 g Abs. 1, 355 BGB ein Widerrufsrecht besteht. Für den App-Anbieter besteht allerdings die Möglichkeit, über § 356 Abs. 5 BGB einen Verzicht auf das Widerrufsrecht zu vereinbaren, was sich lohnt, weil der Verbraucher gemäß § 357 Abs. 9 BGB im Falle eines Widerrufs keinen Wertersatz zu leisten braucht. Die Gestaltung der Verzichtserklärung ist im Einzelfall allerdings sehr problematisch (LG Karlsruhe, Urteil vom 25.05.2016, Az. 18 O 7/16 – nicht rechtskräftig).

nach oben

V. Sonstiges

Rechtliche Probleme im Zusammenhang mit Apps können abgesehen von den obigen vertragsrechtlichen Thematiken insbesondere in den Bereichen Datenschutz, Urheberrecht, Wettbewerbsrecht, Markenrecht, Telemediengesetz und Jugendschutz entstehen.

nach oben

1. Datenschutz

Apps ermöglichen dem Anbieter in aller Regel einen Zugriff auf personenbezogene Daten der Nutzer. Als identifizierendes Merkmal kommt neben der IP-Adresse auch die UID („unique device identifier“) des verwendeten Endgeräts in Betracht. Der App-Anbieter ist hierbei Verantwortlicher im Sinne von Art. 4 Nr. 7 DSGVO und deshalb für die Einhaltung der datenschutzrechtlichen Vorgaben zuständig.

Datenschutzrechtlichen Vorgaben muss schon bei der App-Entwicklung Rechnung getragen werden. Ausführliche Informationen zur Umsetzung der DSGVO finden Sie in unserem großen DSGVO-Guide. Für die App-Entwicklung sind besonders folgende Aspekte wichtig:

Bei Apps, die Telekommunikationsdienstleistungen anbieten, kann außerdem das besondere Datenschutzrecht der §§ 91 ff. TKG Anwendung finden.

nach oben

2. Urheberrecht

Der Urheberrechtsschutz von mobilen Apps entspricht dem von gewöhnlicher Software. Antworten auf die wichtigsten Rechtsfragen finden Sie in unserer Übersicht zum Urheberrechtsschutz von Software.

nach oben

3. Wettbewerbsrecht

Für die Entwicklung und auch den Vertrieb von Apps gelten die allgemeinen wettbewerbsrechtlichen Vorschriften. Beispiele für wettbewerbswidrige Handlungen im Zusammenhang mit mobilen Apps (nach Auer-Reinsdorff/Conrad/Kremer, Handbuch IT- und Datenschutzrecht, 3. Auflage 2019, § 28 Rn. 41 ff.):

  • Falsche Bezeichnung einer App im Titel oder in der Beschreibung als kostenfrei (oder mit einem gleichbedeutenden Begriff wie „gratis“, „free“ etc.), obwohl bei der Nutzung zwangsläufig Kosten entstehen (§ 3 Abs. 1, 3 UWG in Verbindung mit Nr. 21 des Anhangs zu § 3 Abs. 3 UWG).
  • Fehlen eines gut sichtbaren „Jetzt zahlungspflichtig bestellen“-Buttons bei In-App-Käufen (§ 3a UWG iVm. § 312j III 2 BGB).
  • Besonders hartnäckige Werbung für In-App-Käufe kann – gerade gegenüber Kindern und Jugendlichen – eine unlautere aggressive geschäftliche Handlung darstellen (§ 4a UWG).

nach oben

3. Markenrecht

Der Name der App ebenso wie die markenmäßige Benutzung von Kennzeichen in der App kann ältere fremde

verletzen.

nach oben

4. Telemediengesetz

Apps sind elektronische Informations- und Kommunikationsdienste und somit Telemedien (§ 1 Abs. 1 TMG). Sie benötigen ein Impressum gemäß § 5 Abs. 1 TMG.

Tipp: Nutzen Sie unseren kostenlosen Impressum Generator.

nach oben

5. Jugendschutz

Der Jugendschutz bei mobilen Apps muss zwei verschiedene Regelwerke beachten: Zum einen die speziellen Jugendschutz-Richtlinien der App-Stores und zum anderen die allgemeinen gesetzlichen Regelungen des JMStV und des JuSchG. Die Regeln der App-Stores sind überwiegend restriktiver, so dass bei ihrer Einhaltung meist keine Probleme mit dem Gesetzen auftreten. Insbesondere die von den App-Stores zur Altersfreigabe genutzten Systeme sind zwar keine offiziell anerkannten Jugendschutzprogramme gemäß § 11 JMStV, stellen aber wohl geeignete technische Mittel im Sinne von § 5 Abs. 3 Nr. 1 JMStV dar und reichen deshalb aus (ausführlich dazu Rauda, MMR-Beil, 2020, 13).

Wir beraten Sie bei Rechtsfragen zu mobilen Apps. Nutzen Sie unsere kostenlose und unverbindliche Ersteinschätzung.

Hinweis: Dieser Beitrag wurde unter Mitwirkung unseres wissenschaftlichen Mitarbeiters Felix Wichert erstellt.

nach oben

Autor:

Niklas Plutte ist Rechtsanwalt und Fachanwalt für gewerblichen Rechtsschutz mit Sitz in Mainz. Folgen Sie ihm bei Twitter und Facebook!

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.


Kostenlose Ersteinschätzung