Mrz

Von der Idee über die Entwicklung bis zur Vermarktung einer App – Wo liegen die rechtlichen Hürden? (Part 1)

Smartphone, iPad und Co. sollen es uns möglich machen, unser tägliches Leben bequem und umfassend zu regeln und zu gestalten, sei es um zu kommunizieren, um Taxi- und Zugfahrten zu buchen, um Essen zu bestellen, um sich die Zeit mit Spielen zu vertreiben, um Musik zu hören, Videos zu schauen oder Zeitung zu lesen, um ein Fitness-Programm durchzuführen, abzunehmen, um den neuen Partner fürs Leben zu finden oder schlicht den schnellsten Weg zur Arbeit.

Dementsprechend gibt es bereits rund 3 Millionen „mobile Apps“ (Application Software), die derzeit im Apple Store, bei Google Play und anderen Plattformen für den Nutzer zur Installation bereit stehen. Laut Statista wurde im Jahr 2014 mit mobilen Apps ein Umsatz von über 34 Milliarden US-Dollar weltweit erzielt. Und man muss kein Hellseher sein, um einen weiteren, rasanten Anstieg dieser Zahlen zu prophezeien.

Auf diesen Zug wollen verständlicherweise alle, vom Großkonzern bis zum WG-Zimmer-Startup, aufspringen.

Was von der Idee für eine App bis in die Zielgerade aus rechtlicher Sicht Beachtung finden sollte, sei nachfolgend einmal dargestellt. Dieser Beitrag erhebt selbstverständlich keinen Anspruch auf Vollständigkeit. Er soll vielmehr davor bewahren, erst wild mit einer App-Entwicklung loszulegen und nachher vor einem (rechtlichen) Chaos zu stehen, das im Nachhinein im Zweifel nicht mehr so einfach geordnet werden kann.

Die Idee für eine App steht – Und jetzt?

Bevor die Idee, die mit der App realisiert werden soll, tatsächlich umgesetzt wird, sollten selbstverständlich Vorüberlegungen zur Konzeption der App angestellt werden – wie etwa zum Design, Namen, der Zielgruppe und den späteren Vertriebswegen. Schon aus wirtschaftlicher Notwendigkeit spielt die Marketing-Strategie bis hin zur Monetarisierung der App eine wesentliche Rolle. Dies betrifft auch die Frage, ob die App später kostenlos oder kostenpflichtig angeboten werden soll, und, ob weitere Finanzierungs- bzw. Einnahmemöglichkeiten über In-App-Käufe, Sponsoring, In-App-Ads usw. möglich sein sollen. Aber diese Punkte überlassen wir mal den BWLern ;].

In rechtlicher Hinsicht gilt es zunächst zu bedenken, wer an der Realisierung einer App beteiligt sein kann und mit wem Vertragsbeziehungen eingegangen werden, namentlich

der App-Betreiber,
der App-Entwickler,
die Anbieter von Dritt-Services,
der App-Vermarkter und schlussendlich
der Nutzer.

Dabei ist zu berücksichtigen, dass wenigstens die folgenden Rechtsbereiche in der App-Entwicklung und bzw. dem App-Verkauf eine Rolle spielen:

Namens- und Markenrecht,
IT-/Softwareentwicklungs-Vertragsrecht,
Datenschutzrecht
Nutzungsbedingungen der App – Vertrag zwischen Betreiber und Nutzer (AGB-Recht)
Nutzungsbedingungen der App-Vermarkter – Vertrag zwischen App-Betreiber und App-Vermarktern (Stores)

Von der Idee bis zur Vermarktung der App

Schon die vorgenannte Aufzählung zeigt, dass die rechtlichen Stolpersteine mannigfaltig am Wegesrand verstreut liegen. Nun aber der Reihe nach.

Im Ersten Teil unserer kleinen Reihe geht es um das Markenrecht, den „Entwicklervertrag“ und um sonstige Verträge wie hinsichtlich der Logogestaltung oder des Marketings.

Im Zweiten Teil wird es dann um die Einbindung von Dritt-Services, den Datenschutz bei Apps sowie um die Vertragsbeziehungen zwischen App-Betreibern und App-Vermarktern (also den Stores) gehen.

1. Wie soll das Kind denn heißen? – Vom Markenrecht

Zunächst sollte die geplante App, bzw. der Name der App, im Hinblick auf Namens- und Markenrechte überprüft werden. Denn natürlich finden das Markenrecht (MarkenG), das Namensrecht nach § 12 BGB, als auch das Wettbewerbsrecht (UWG) nicht nur im „Internet“, sondern auch in Bezug auf Applikationen Anwendung. Was aus markenrechtlicher wie wettbewerbsrechtlicher Sicht bei der Wahl eines Namens zu berücksichtigen ist, haben wir Artikel Domainrecht – Von den rechtlichen Fallstricken bei der Auswahl der eigenen Domain bereits ausführlich beschrieben (Wie der Titel schon sagte, erfolgen die Ausführungen dort in Bezug auf Domains, aber das tut dem Ganzen keinen Abbruch und ist auch für App-Entwickler bzw. Betreiber lesenswert). Mit dem Werktitelschutz für Apps haben wir uns anhand einer Entscheidung des Hamburger Landgerichts (Beschl. v. 8.10.2013, 327 O 104/13) ebenfalls schon umfassend hier befasst.

Nicht vergessen werden sollte dann zu einem späteren Zeitpunkt, dass auch die ASO (App Store Optimization) ihre Grenzen in den Rechten Dritter findet. Kurz: Auch für das ASO dürfen keine markenrechtlich geschützten Begriffe als Keywords oder im Titel von Apps verwendet werden. werden (Vgl. Hanseatisches Oberlandesgericht Hamburg 5. Zivilsenat, Beschl. v. 19.06.2013, 5 W 31/13).

Warum sich um den ganzen vorstehenden Kram kümmern? Nun, Name, Slogan oder Logo können die bestehenden Rechte Dritter ebenso verletzen wie die Verwendung von unlauteren Keywords. Folglich droht die klassische Abmahnung aufgrund der Verletzung von Namens-, Marken- und/oder Wettbewerbsrecht. Neben Kosten- und etwaigen Schadensersatzansprüchen ist vor allem der damit geltend gemachte Unterlassungsanspruch unangenehm. Denn dies bedeutet, dass der gewählte App-Name nicht mehr verwendet werden darf und damit, dass nicht nur die Suche nach einem neuen Namen los geht, sondern dass auch auch sämtliche Marketing-Aktivitäten von vorne Beginnen müssen.

2. IT-rechtliche Fragestellungen – der Vertrag zwischen App-Betreiber und Entwickler

Absprachen per Handschlag können gut gehen. Sie können aber genauso gut extrem schief gehen. Und da die App-Entwicklung letztlich ein Kernstück des App-Business darstellt, sollte hier wahrlich nicht zu nachlässig mit umgegangen werden. Geht es an die Vertragsgestaltung sind natürlich die allgemeinen Grundsätze der Vertragsgestaltung zu beachten. Also, Leistung und Gegenleistung muss festgehalten werden, Haftung und Gewährleistung müssen geregelt sein und keinesfalls dürfen die Rechteübertragungen vergessen werden. Aber auch hier der Reihe nach:

a. Zur Vertragsart und dem „Problem“ agiler Projektstrukturen

Bei der Software-Entwicklung handelt es sich in der Regel um einen Werkvertrag (vgl. BGH, Urteil vom 25. März 2010, Az. VII ZR 224/08). Wenn Aspekte der Software-Pflege oder des Software-as-a-Service (SaaS) hinzukommen, können diese Elemente auch dienstvertraglicher Natur sein. Die konkrete Einordnung ist genauso einzelfallabhängig wie wichtig. Denn während bei einem Werkvertrag ein konkreter Erfolg geschuldet ist (App verfügt über die und die Funktionen und läuft) wird bei einer Dienstleistung nur die Erbringung der Leistung an sich und kein konkreter Erfolg geschuldet. Die Einordnung der einzelnen Elemente und damit ob Abnahmen (im Werkvertrag) zu erfolgen haben, hat erhebliche Folgen in Bezug auf die Gewährleistung – für den Fall, dass etwas nicht rund läuft.

Daneben ist grundsätzlich zu bedenken, dass die wenigsten IT-Projekte linear verlaufen. Dass Buzzword lautet hier „agil“ bzw. „agile Projekte„, letztendlich meint es nichts anderes, als das fortlaufend unter dem Projekt Änderungen anstehen können und/oder von verschiedenen Seiten zugearbeitet wird.

Wie das rechtlich zu bewerten ist, warum Projektbeschreibungen sowie Lasten- und Pflichtenhefte dabei eine große Rolle spielen, das haben wir schon vor einiger Zeit in unserem Artikel Von Lastenheften, Pflichtenheften und was das gerade bei agilen Projekten mit Verträgen zu tun hat ausführlich dargestellt. In aller Kürze kann man aber an dieser Stelle sagen, dass als ein wesentlicher Punkt eine Projektbeschreibung enthalten sein und in einem weiteren Schritt zwischen dem App-Betreiber und dem Entwickler ein Lasten- und ein Pflichtenheft erstellt werden sollte , in welchen die vom jeweiligen Vertragspartner gewollten Anforderungen konkret benannt werden.

Dazu ein (einfaches) Beispiel: Da Apple´s iOS, Google´s Android, Microsoft Windows oder auch die kleineren Systeme jeweils für das eigene Betriebssystem einen eigenen Quellcode verwenden, wäre etwa im Pflichtenheft festzulegen, dass der Entwickler sich an IOS oder Android (bzw. Windows 8 / Mobil) zu orientieren hat und das bereitgestellte Software-Kit für Entwickler (SDK) bei der Programmierung verwenden soll.

Wie auch bei der Auftragserteilung und Entwicklung einer Homepage ist es zudem von Vorteil, dem Entwickler klare Vorgaben über das Design und den Funktionsumfang anhand konkreter Spezifikationen im Pflichtenheft vorzulegen und die Fortschritte protokollieren zu lassen und vor allem auch Leistungsbausteine (Milestones) und Abnahmen wie auch gegebenenfalls Zwischen-Abnahmen zu vereinbaren.

Wie gesagt, ausführlich haben wir hier die Vertragsstrukturen von agilen Projekten beschrieben.

b. In der Umsetzungsphase – Wer macht eigentlich was? Und wie wird das geregelt?

In Bezug auf die Umsetzung sollte zum einen bedacht werden, dass die Mitwirkungspflichten der Parteien und die Konsequenzen, wenn eine Partei eben diesen nicht nachkommt, vertraglich geregelt werden müssen. Denn was nützt ein das Datieren eines Milesstones und einer Abnahme, wenn der Entwickler letztlich aufgrund mangelnder Mitwirkung des Auftraggebers diesen Milestone überhaupt nicht erreichen konnte? Wenn nun der Auftraggeber darauf dennoch dringt, ist der Ärger mehr als vorprogrammiert und es wird sich gestritten, wer, was, wann und wie hätte beibringen müssen und wer für die Leistungsverzögerung denn nun verantwortlich ist.

Daneben sollte unbedingt im Vertrag ein Passus zu Leistungsänderungen im Projektverlauf zu finden sein, der dezidiert darlegt, unter welchen Bedingungen solche möglich sind und auf welche Art diese vereinbart werden können. So können auch spätere Eventualitäten berücksichtigt werde, die bei Vertragsschluss noch nicht bedacht wurden. (Siehe dazu ausführlich auch im schon eben genannten Artikel zur agilen Projekten).

Gerade während der Umsetzungsphase werden dann auch die oben schon angesprochenen Abnahmen und vor allem die Zwischenabnahmen relevant. Ist eine Abnahme erfolgt, dann gilt das Werk als mangelfrei und ist entsprechend zu bezahlen. In Folge dessen sollten sich Auftraggeber hüten bei Mängeln zu sagen „Ach, ist okay, ihr macht das ja schon noch…“. Vielmehr sollten bei jeder (Zwischen-)Abnahme unbedingt Mängellisten geführt und die einzelnen Mängel, insbesondere auch Abweichungen vom Konzept (Pflichtenheft), sauber dokumentiert werden. Solange ein Werk(teil) noch über Mängel verfügt und in Folge dessen nicht abgenommen ist, gilt es nicht als fertig. Und der Entwickler schuldet in diesem Moment noch immer die vereinbarte Leistung, d.h. es ist noch nicht nach etwaigen Gewährleistungsregelungen zu fragen.

Es ist allerdings auch wichtig zu wissen, dass ein Werk wegen unwesentlicher Mängel nicht nicht abgenommen werden darf. Diese Regelung dient dazu einem Werkersteller nicht mit „mimosenhaften Vorstellungen“ um den (zeitigen) Lohn zu prellen – um es einmal ganz plakativ auszudrücken. Aber auch hier sollte aber eine Liste hinsichtlich der unwesentlichen – und noch zu beseitigenden Mängel erstellt werden.

c. Rechteübertragungen

Gerne vergessen, aber doch so wichtig: Die Übertragung der Rechte an der App-Software. Software erfährt in Deutschland über §§ 69a ff. UrhG Schutz. Folglich hat zunächst einmal einer Rechte an der Software und zwar der oder die Programmierer als Urheber der geistig-schöpferischen Leistung.

Wird das Programm im Arbeits- oder Dienstverhältnis entwickelt, ist alles „relativ“ problemlos. Denn hier erwirbt gemäß § 69b UrhG der Arbeitgeber alle vermögensrechtlichen Befugnisse, während der „Arbeitnehmerurheber“ von der Verwertung seines Programms in der Regel ausgeschlossen wird.

Ist der Entwickler aber kein Arbeitnehmer, muss die Rechteübertragung ebenso wie eine evtl. Herausgabe der Programmierungsgrundlagen (Dokumentation, Quellcode bzw. Hinterlegungsvereinbarungen) unbedingt geregelt werden, damit etwa die Weiterentwicklung der App auch bei einem möglichen Wechsel des Entwicklers bzw. Entwickler-Team reibungslos stattfinden kann. Die Fragen der Rechteübertragung werden oft unter dem Stichwort „Lizenz“ abgehandelt. Doch gleich, wie dieses Kind heißt, muss der Umfang der Rechteübertragung geregelt sein.

d. Und wenn es doch schiefläuft? – Von Abnahmen, Gewährleistung und Haftung

Für den Fall, dass es dennoch einmal dazu kommt, dass die App vom Entwickler zu vertretende Fehler aufweist, ist an Haftungs- und Gewährleistungsklauseln im Vertrag zu denken.

Aus Sicht der App-Entwickler sind Haftungs- und Gewährleistungsklauseln natürlich soweit zu „drücken“, wie es Recht und Gesetz zulässt. Das Interesse des Auftraggebers ist hier natürlich gegenteilig. Im Zusammenspiel mit klaren Leistungsverpflichtungen des Auftragnehmers sollte der Auftraggeber versuchen, die Haftung des Programmieres so weit als möglich zu definieren. Hinsichtlich welcher Punkte genau, hängt wieder stark vom einzelnen Projekt ab. Aber sagen wir es einmal so: Würden Sie als App-Betreiber gerne für automatisierte, nicht autorisierte In-App-Käufe der Nutzer haften wollen und keinen Regress nehmen können, wenn diese In-App-Käufe auf einer Fehlfunktion im Code beruhen?

3. Und sonst so vertraglich? – Zum Beispiel: Softwarepflegeverträge oder Lizenzvereinbarungen hinsichtlich des Logos?

Kaum eine Software kommt ohne ständige Updates (schon aufgrund der Updates der Umgebungssysteme) und sonstige Pflege aus. Folglich ist es auch keine schlechte Idee, die regelmäßige Wartung und Anpassung der App, vertraglich zu regeln. Das schimpft sich dann im Zweifel Software-Pflegevertrag.

Auch für weitere Aufträge, beispielsweise die Gestaltung eines Logos oder hinsichtlich der geplanten Marketing-Aktivitäten sollten Verträge mit dem Gestalter oder der Agentur geschlossen werden. Man mag später nämlich sicher nicht über Nutzungsrechte und spätere Nachzahlungen oder um die vereinbarten Marketing-Leistungen streiten müssen. (Am Beispiel eines Agenturvertrags haben wir hier schon ein paar Lösungsvorschläge ausgearbeitet).