Wem gehört der Quellcode Ihrer App? Das muss in den Vertrag

Vermutlich liegt gerade ein App Angebot auf Ihrem Tisch, oder die Zusammenarbeit mit Ihrem Entwickler ist zu Ende gegangen. In beiden Fällen klären Sie zunächst drei Fragen:

1. Räumt Ihnen der Vertrag ausdrücklich die Rechte am Quellcode ein?
2. Auf wessen Namen laufen die Entwicklerkonten bei Apple und Google?
3. Wer hat die Adminzugänge zu Server, Datenbank und Domain?

Talha Aslan und Team erklären in diesem Leitfaden die Eigentumsfrage aus technischer und vertraglicher Sicht. Die Abläufe in den Stores haben wir anhand der offiziellen Hilfeseiten von Apple und Google geprüft. Ein wichtiger Hinweis: Dieser Beitrag ist eine allgemeine Information und keine Rechtsberatung. Lassen Sie Ihren Vertrag vor der Unterschrift von einer Anwältin oder einem Anwalt prüfen.

Was unterscheidet Quellcode, fertige App und Nutzungsrechte?

Zunächst zur Begriffsklärung, denn diese drei Begriffe geraten oft durcheinander. Im Vertrag brauchen Sie allerdings für jeden eine eigene Regelung. Quellcode sind die Dateien, die ein Entwickler schreibt und bearbeiten kann. Die fertige App ist dagegen das Installationspaket auf dem Smartphone. Sie können es ausführen, aber nicht ändern. Die Nutzungsrechte schließlich legen fest, wer das Werk verwenden, vervielfältigen, bearbeiten und verbreiten darf.

Ein Beispiel: Übergibt der Entwickler nur die veröffentlichte App, haben Sie ein funktionierendes Produkt. Sobald Sie jedoch eine neue Funktion möchten, kann kein anderes Team weiterarbeiten. Andererseits bleibt Ihr Recht zur Bearbeitung unklar, wenn Sie zwar einen Ordner mit Code erhalten, aber keine Rechte vertraglich bekommen.

Ein sicherer Vertrag regelt daher drei Dinge gemeinsam. Erstens die tatsächliche Übergabe des Codes. Zweitens die schriftliche Einräumung der Rechte. Drittens die Zugänge, mit denen Sie die App selbst neu bauen und veröffentlichen. Fehlt einer dieser Punkte, besteht Ihr Eigentum nur auf dem Papier.

Wem gehört der Quellcode der App, wenn der Vertrag schweigt?

Schweigt der Vertrag, liegen die Rechte am Quellcode der App in vielen Fällen beim Urheber, also beim Entwickler. In Deutschland schützt das Urheberrechtsgesetz Computerprogramme als Werke. Das Urheberrecht selbst ist dabei nicht übertragbar. Übertragen lassen sich nur Nutzungsrechte, und zwar einfache oder ausschließliche.

Hinzu kommt der sogenannte Zweckübertragungsgrundsatz. Sind die einzelnen Nutzungsarten im Vertrag nicht genannt, erhalten Sie im Zweifel nur die Rechte, die der Vertragszweck erfordert. Ein Satz wie „die App gehört Ihnen" reicht deshalb oft nicht aus.

In der Praxis entsteht dadurch ein stilles Problem. Das Unternehmen nutzt die App weiter. Will es den Code dann einem neuen Team geben, widerspricht der ursprüngliche Entwickler. Manche Entwickler verkaufen zudem dieselbe Codebasis an andere Kunden und sehen darin keinen Konflikt.

Verlangen Sie daher ausschließliche, zeitlich, räumlich und inhaltlich unbeschränkte Nutzungsrechte an allen Arbeitsergebnissen, einschließlich Quellcode. Gesetze und Rechtsprechung können sich ändern; prüfen Sie den aktuellen Stand deshalb mit einer Anwältin oder einem Anwalt.

Macht es einen Unterschied, ob Angestellte, Freelancer oder eine Agentur programmieren?

Ja, denn die Ausgangslage hängt vom Urheber ab. Für Programme, die Angestellte in Erfüllung ihrer Aufgaben schaffen, sieht das Urheberrechtsgesetz eine besondere Regel vor: Die vermögensrechtlichen Befugnisse stehen grundsätzlich dem Arbeitgeber zu. Freelancer und Agenturen sind allerdings keine Angestellten. Folglich müssen Sie die Rechte bei ihnen ausdrücklich im Vertrag regeln.

Die letzte Zeile übersehen allerdings viele. Hat die Agentur Arbeit ausgelagert und sich die Rechte nicht gesichert, kann sie Ihnen keine vollständigen Rechte einräumen. Deshalb empfehlen wir in jedem App Vertrag eine entsprechende Zusicherung.

Welche Rechte sollte die Klausel einzeln aufzählen?

Begnügen Sie sich nicht mit einem allgemeinen Satz. Bestehen Sie stattdessen auf einer Klausel, die jede Nutzungsart nennt. Unseren Kunden empfehlen wir, mindestens auf diese Punkte zu achten:

• Bearbeitung, Anpassung und Weiterentwicklung des Codes.
• Vervielfältigung von Code und App.
• Verbreitung und Verkauf der App über App Stores.
• Öffentliche Zugänglichmachung über das Internet.
• Ausschließlichkeit ohne zeitliche, räumliche oder inhaltliche Grenzen.
• Recht zur Weiterübertragung und Unterlizenzierung an Dritte.

Listen Sie außerdem die erfassten Arbeitsergebnisse auf: Quellcode, Datenbankschema, Designdateien, Icons und Bilder, Texte sowie technische Dokumentation. Hat etwa eine separate Designerin die Screens gestaltet, brauchen auch die Designdateien eine eigene Rechteeinräumung.

Legen Sie schließlich fest, wann die Rechte übergehen. Manche Verträge knüpfen das an die Schlusszahlung, andere an jeden Meilenstein. Beides funktioniert. Lassen Sie den Zeitpunkt nur nicht offen.

Lizenz oder volle Rechteeinräumung: Was sollten Sie verlangen?

Bei einer umfassenden, ausschließlichen Rechteeinräumung dürfen nur Sie das Werk nutzen. Bei einer einfachen Lizenz behält der Entwickler seine Rechte und erlaubt Ihnen lediglich die Nutzung. Steht die App im Zentrum Ihres Geschäfts, ist die ausschließliche Variante meist sicherer. Denn so können Sie später den Entwickler wechseln, die App verkaufen oder bei Investoren Ihre Rechte belegen.

Trotzdem ist eine Lizenz nicht immer schlecht. Mieten Sie zum Beispiel eine fertige Buchungsplattform monatlich, schreibt ohnehin niemand eigenen Code für Sie. Dann zählen vor allem die Lizenzbedingungen: Laufzeit, Umgang mit Ihren Daten nach dem Ende und eine Grenze für Preiserhöhungen.

Und das Mischmodell? Viele Agenturen lizenzieren ihr gemeinsames Framework und räumen an den individuell entwickelten Teilen volle Rechte ein. Das ist fair, solange der Vertrag auflistet, welche Dateien in welche Gruppe fallen. Sonst wird jedes Modul mit dem Satz „das ist unser Framework" zum Streitpunkt.

Fragen Sie beim Vergleich von Angeboten gezielt danach. Die Fragen in unserem Leitfaden App Angebot richtig bewerten erleichtern diesen Vergleich deutlich.

Was passiert mit quelloffenen Bibliotheken und fremden Komponenten?

Keine moderne App beginnt bei null. Entwickler nutzen quelloffene Bibliotheken und kommerzielle Komponenten für Login, Karten, Diagramme oder Zahlungen. Rechte daran kann Ihnen niemand einräumen, denn auch der Entwickler besitzt sie nicht. Sie erhalten lediglich das Recht, diese Bausteine nach deren eigenen Lizenzbedingungen zu nutzen.

Nehmen Sie deshalb eine Klausel auf, nach der der Entwickler bei Übergabe eine Liste aller fremden Komponenten samt Lizenzart liefert. Manche Open Source Lizenzen enthalten Bedingungen, die unter Umständen die Offenlegung Ihres eigenen Codes verlangen. Plant das Team eine solche Komponente, sollte es vorher Ihre Zustimmung einholen.

Bei kostenpflichtigen Komponenten gilt dasselbe. Hat die Agentur die Lizenz auf eigenen Namen gekauft, verlieren Sie womöglich den Zugriff, sobald die Zusammenarbeit endet. Bestehen Sie daher darauf, dass bezahlte Lizenzen direkt auf Ihr Unternehmen laufen. Eine ähnliche Logik zeigt sich bei der Entscheidung native oder Cross Platform, denn die Technologie bestimmt auch, von welchen Komponenten Sie abhängen.

Auf wessen Namen sollten die Entwicklerkonten bei Apple und Google laufen?

Die Entwicklerkonten gehören der Person oder Organisation, die die App veröffentlicht, also Ihnen. Apple erklärt auf der Anmeldeseite des Apple Developer Program, dass bei Einzelpersonen deren Name als Verkäufer im App Store erscheint. Bei Organisationen erscheint dagegen der Name der Organisation. Außerdem verlangt Apple von Organisationen eine DUNS Nummer.

Bei Google gibt es eine ähnliche Unterscheidung. Laut der Hilfeseite zu den Kontotypen der Play Console wählen Sie ein Organisationskonto, wenn Sie das Konto für eine Organisation oder ein Unternehmen anlegen. Auch dafür ist eine DUNS Nummer nötig. Hakt die Anmeldung, hilft Ihnen unser Beitrag zur Anmeldung beim Apple Developer Program und der DUNS Nummer.

Die Veröffentlichung über das Konto der Agentur wirkt anfangs bequem. Allerdings erscheint dann die Agentur als Verkäufer, und Bewertungen sowie Downloadzahlen sammeln sich in ihrem Konto. Besser legen Sie die Konten auf Ihren Namen an und laden die Agentur als Nutzer ein. Beide Stores erlauben dem Kontoinhaber, Teammitglieder einzuladen und Rollen zu vergeben.

Warum sollten Sie die Rolle des Kontoinhabers nie abgeben?

Jede Apple Mitgliedschaft hat einen Account Holder, also einen Kontoinhaber. Laut Apples Dokumentation zu den Rollen akzeptiert diese Person rechtliche Vereinbarungen, verlängert die Mitgliedschaft und fügt die ersten Admins hinzu. Bei Google Play ist der Kontoinhaber das zuerst registrierte Konto. Es hat vollen Zugriff auf die Play Console und kann als einziges ein Zahlungsprofil für kostenpflichtige Apps verknüpfen.

Kurz gesagt ist diese Rolle der Schlüssel zu Ihrer App. Bleibt sie bei der Agentur, gehört Ihnen die App vielleicht rechtlich, kontrolliert wird sie aber faktisch von jemand anderem. Ein Beispielszenario: Die Verlängerung steht an, die Agentur verpasst sie, und die App verschwindet aus dem Store. Sie selbst können nicht eingreifen.

Richten Sie es stattdessen so ein:

1. Legen Sie das Konto auf Ihr Unternehmen und mit einer geschäftlichen E-Mail Adresse an.
2. Behalten Sie die Rolle des Kontoinhabers bei einer Person in Ihrem Unternehmen.
3. Geben Sie dem Entwicklerteam nur die Rechte, die es für seine Arbeit braucht.
4. Prüfen und entfernen Sie Zugänge, sobald das Projekt endet oder das Team wechselt.

Genau dieses Vorgehen empfehlen wir auch für Social Media und Werbekonten. Den Gesamtrahmen beschreibt unser Beitrag digitale Assets verwalten.

Wie holen Sie eine App aus dem Konto der Agentur?

Beide Stores erlauben den Umzug einer App in ein anderes Entwicklerkonto. Sie müssen sie also nicht löschen und neu veröffentlichen. Laut Apples Überblick zur App Übertragung startet der Account Holder der abgebenden Mitgliedschaft den Vorgang. Danach nimmt der Account Holder des Zielkontos ihn an. Die App behält Bewertungen, Rezensionen und ihre Bundle ID, und Nutzer erhalten weiterhin Updates.

Apples Seite mit den Übertragungskriterien nennt zudem Bedingungen. Zum Beispiel muss mindestens eine Version der App bereits im App Store erschienen sein. Außerdem darf die App zu diesem Zeitpunkt nicht in der Prüfung stecken. Beide Seiten müssen zudem die aktuellen Vereinbarungen für kostenlose und kostenpflichtige Apps akzeptiert haben.

Für Google beschreibt die Hilfeseite zur App Übertragung in der Play Console den Ablauf. Der bisherige Kontoinhaber stellt die Anfrage, der Zielkontoinhaber bestätigt sie. Nutzer, Downloadstatistiken, Bewertungen und Rezensionen wandern ins Zielkonto. Massenexporte und Einnahmeberichte gehen allerdings nicht mit; laden Sie diese also vorher herunter. Auch Testgruppen müssen Sie neu anlegen.

Nehmen Sie deshalb eine Klausel auf: Die Agentur überträgt Apps, die sie in ihrem Konto veröffentlicht hat, auf Anfrage und innerhalb angemessener Frist in Ihr Konto.

Warum sind Signaturschlüssel und Zertifikate so wichtig?

App Stores prüfen per digitaler Signatur, ob ein Update wirklich vom Eigentümer der App stammt. Verlieren Sie die Schlüssel, kann die Veröffentlichung von Updates schwierig werden. Somit gehören Schlüssel genauso auf die Lieferliste wie der Quellcode.

Googles Hilfeseite zur Play App Signatur unterscheidet zwei Schlüssel. Den Uploadschlüssel hält der Entwickler und signiert damit das App Bundle vor dem Hochladen. Den App Signaturschlüssel hält Google und signiert damit die Pakete für die Geräte der Nutzer. Geht der Uploadschlüssel verloren, können Sie in der Play Console ein Zurücksetzen beantragen. Verwalten Sie den App Signaturschlüssel jedoch selbst und verlieren ihn, lässt er sich laut Google nicht zurücksetzen.

Bei Apple hängen Zertifikate und Profile am Entwicklerkonto. Läuft das Konto auf Ihren Namen, kann ein neues Team sie mit eigenem Zugang neu erstellen. Verlangen Sie daher den Uploadschlüssel, die Passwörter und eine schriftliche Übersicht, welches Zertifikat in welchem Konto liegt. Teilen Sie Passwörter über einen sicheren Passwortmanager, nicht per E-Mail.

Wer sollte Server, Datenbank und Schnittstellen kontrollieren?

Die meisten Business Apps zeigen ihr Gesicht auf dem Smartphone, ihr Gehirn sitzt aber auf einem Server. Konkret liegen Konten, Bestellungen, Termine und Inhalte in einer Datenbank. Die App greift darauf über eine API zu, also eine Schnittstelle für den Datenaustausch. Selbst mit dem Quellcode der App in der Hand funktioniert nichts, wenn Ihnen der Serverzugang fehlt.

Halten Sie deshalb im Vertrag ausdrücklich fest:

• Auf wessen Namen und Zahlungsmittel das Server oder Cloudkonto läuft.
• Wer den Adminzugang zur Datenbank und zu den regelmäßigen Backups hat.
• Dass auch der Backendcode der Schnittstelle zum Rechteumfang gehört.
• Dass Domain und E-Mail Konten Ihrem Unternehmen gehören.
• Wo personenbezogene Daten liegen und wer darauf zugreifen kann.

Der letzte Punkt hängt zudem mit rechtlichen Pflichten zusammen. Verarbeiten Sie Nutzerdaten, tragen Sie die Verantwortung dafür; mehr dazu lesen Sie in unserem Beitrag zum Datenschutz in der App. Dasselbe Problem bei Websites behandelt unser Leitfaden Website und Domain von der Agentur zurückholen.

Auf wessen Namen sollten Drittanbieterkonten laufen?

Eine App besteht aus mehr als einem Storeeintrag und einem Server. Analyse, Absturzberichte, Pushbenachrichtigungen, Karten, E-Mail Versand und Zahlungen laufen meist über eigene Dienste. Jeder davon bedeutet zudem ein Konto, eine Rechnung und einen Schlüssel.

Ein Muster sehen wir dabei häufig. Der Entwickler legt diese Dienste während der Entwicklung in einem privaten Konto an und lässt sie nach dem Start dort. Ein Beispielszenario: Die Karte des Entwicklers läuft ab, der Benachrichtigungsdienst stoppt, und Ihre Kunden erhalten keine Bestellhinweise mehr. Schon die Ursachensuche kann Tage dauern.

Nehmen Sie also eine Klausel auf, nach der der Entwickler alle Drittanbieterkonten auf Ihr Unternehmen anlegt oder bei Übergabe überträgt. Fordern Sie zur Übergabe eine Liste mit Dienst, Inhaber und Abrechnung an. Auch Googles Hilfeseite zur Übertragung weist darauf hin, dass Integrationen wie Analytics Berechtigungen und Cloudverknüpfungen nicht automatisch mit der App umziehen. Diese passen Sie also selbst an.

Was gehört zur Übergabe beim Quellcode der App?

Konkret ist die Lieferliste der greifbarste Teil des Vertrags. In unseren eigenen Projekten nutzen wir die folgende Tabelle; Sie können sie als Anlage an Ihren Vertrag hängen.

Unterschätzen Sie die Zeile Dokumentation nicht. Auch mit dem Code in der Hand braucht ein neues Team ohne schriftliche Buildschritte lange, um das Projekt zu verstehen. Diese Zeit bezahlen am Ende Sie.

Wann und in welcher Form sollten Sie den Quellcode der App erhalten?

Den Quellcode der App am Projektende als einzelne Archivdatei zu bekommen, ist die schwächste Variante. Denn Sie können kaum prüfen, ob das Archiv wirklich aktuell ist, und die Änderungshistorie fehlt. Verlangen Sie stattdessen, dass der Code von Anfang an in einem Repository auf Ihren Namen liegt.

So sehen Sie jede Änderung sofort. Bricht das Projekt mittendrin ab, besitzen Sie trotzdem alles, was bis dahin entstanden ist. Zudem haben Sie den Entwickler als Nutzer hinzugefügt und können seinen Zugang nach Projektende mit einem Klick entfernen.

Ein Detail zum Repository: Sie sollten Eigentümer sein, der Entwickler eingeladener Nutzer. Liegt das Repository dagegen im Konto des Entwicklers und Sie sind nur Gast, kann Ihr Zugang jederzeit verschwinden. Anders gesagt: Prüfen Sie die Eigentümereinstellung, nicht nur Ihren Zugang.

Testen Sie die Übergabe dann mit einem einfachen Verfahren. Bitten Sie einen unabhängigen Entwickler, die App allein anhand der gelieferten Dokumentation neu zu bauen. Klappt das und verhält sich das Ergebnis wie die Storeversion, ist die Übergabe echt. Wir empfehlen diese Prüfung vor der Schlusszahlung.

Halten Sie außerdem den Liefertermin fest und was bei Verzug passiert. Ein Satz wie „wir liefern, wenn das Projekt fertig ist" hilft nicht, sobald beide Seiten „fertig" anders verstehen.

Wie regelt der Vertrag Wartung und Fehlerbehebung?

In den ersten Wochen nach dem Start belasten echte Nutzer die App zum ersten Mal richtig. Vereinbaren Sie deshalb eine Gewährleistungsphase. In dieser Zeit behebt der Entwickler Fehler im gelieferten Umfang ohne Zusatzkosten.

Für die Zeit danach schließen Sie einen eigenen Wartungsvertrag. Halten Sie darin schriftlich fest:

• Schweregrade für Fehler (App fällt aus, Funktion defekt, optischer Mangel).
• Reaktionszeit und Lösungszeit je Schweregrad.
• Ob Anpassungen an neue Betriebssysteme und geänderte Storeregeln enthalten sind.
• Dass neue Funktionen als neuer Auftrag gelten, nicht als Wartung.
• Eine erneute Übergabe von aktuellem Code und Zugängen am Ende der Wartung.

Pflichtupdates der Stores machen einen großen Teil jedes Wartungsbudgets aus. Wie sich das auf die Kosten auswirkt, erklären wir in unserem Beitrag Was bestimmt die Kosten der App Entwicklung. Feste Zeiten oder Preise nennen wir hier nicht, denn wir betrachten jedes Projekt mit seinem eigenen Umfang.

Wie verknüpfen Sie Zahlungsplan und Rechteübergang?

Für den Entwickler ist das größte Risiko, zu liefern und kein Geld zu sehen. Für das Unternehmen ist es umgekehrt: zahlen und keinen Code erhalten. Ein Verfahren löst beide Sorgen zugleich. Teilen Sie die Zahlung in Meilensteine und lassen Sie sich bei jeder Zahlung den Code dieses Meilensteins übergeben.

Ein Beispielszenario: Sie gliedern das Projekt in vier Phasen, nämlich Design, Kernfunktionen, alle Funktionen und Start. Am Ende jeder Phase überträgt der Entwickler den Code in Ihr Repository. Dann prüfen Sie ihn und geben die Zahlung frei. Somit trägt keine Seite ein großes Risiko.

Verträge, die den Rechteübergang an die Schlusszahlung knüpfen, sind ebenfalls üblich. Für den Entwickler ist das ein nachvollziehbarer Wunsch. Trotzdem sollte der Code auch dann von Beginn an in Ihrem Repository liegen. Das heißt, rechtlich gehen die Rechte am Ende über, praktisch halten Sie den Code jedoch die ganze Zeit.

Verknüpfen Sie zudem den Zahlungsplan mit der Lieferliste. Ein Satz wie „der Kunde leistet die Schlusszahlung, sobald die Lieferliste vollständig erfüllt ist" macht jede Position verbindlich.

Was schützen Vertraulichkeit, Wettbewerbsverbot und Wiederverwendung?

Ihre App spiegelt einen Teil Ihres Geschäftsmodells: Preislogik, Aktionen oder Abläufe. Eine Vertraulichkeitsklausel verhindert, dass der Entwickler dieses Wissen weitergibt. Achten Sie darauf, dass sie auch nach Vertragsende gilt.

Heikler ist dagegen das Thema Wiederverwendung, denn hier gibt es zwei berechtigte Interessen. Entwickler nehmen ihr allgemeines Fachwissen natürlich in andere Projekte mit, und ein Verbot wäre unrealistisch. Andererseits ist es fair, den Verkauf Ihrer individuellen Geschäftslogik, Screens und Inhalte an einen Wettbewerber auszuschließen.

Eine ausgewogene Klausel könnte so lauten: Allgemeine Codebausteine und Fachwissen bleiben frei nutzbar. Ihre individuelle Geschäftslogik, das Design und die Inhalte stehen dagegen ausschließlich Ihnen zu, und der Entwickler gibt sie nicht an Dritte weiter. Wünschen Sie ein Wettbewerbsverbot, begrenzen Sie es auf einen angemessenen Zeitraum und eine Branche. Weil die Wirksamkeit solcher Klauseln stark vom Einzelfall abhängt, holen Sie anwaltlichen Rat ein.

Was tun Sie, wenn das Projekt stockt oder die Zusammenarbeit endet?

Nicht jedes Projekt endet wie geplant. Der Entwickler wechselt vielleicht den Job, die Agentur schließt, oder der Kontakt bricht ab. Bleiben Sie in diesem Fall ruhig und gehen Sie der Reihe nach vor:

1. Sammeln Sie Vertrag und Nachrichten in einem Ordner und markieren Sie die Klauseln zu Rechten und Übergabe.
2. Prüfen Sie, auf wessen Namen Storekonten, Server und Domain laufen.
3. Kontrollieren Sie in Ihren eigenen Konten alle berechtigten Nutzer und ändern Sie Passwörter.
4. Fordern Sie fehlende Lieferpositionen schriftlich und mit angemessener Frist an.
5. Liegt die App im Konto der Agentur, verlangen Sie den offiziellen Übertragungsprozess.
6. Bleibt eine Antwort aus, besprechen Sie Ihre rechtlichen Möglichkeiten mit einer Anwältin oder einem Anwalt.

Eine Warnung: Vertrauen Sie niemandem, der Ihre Konten durch unbefugten Zugriff „zurückholen" will. Der Zugriff auf fremde Konten oder die Täuschung des Storesupports mit gefälschten Unterlagen birgt rechtliche Risiken und gefährdet auch Ihr Entwicklerkonto. Der offizielle Übertragungsweg der Stores und Ihr Vertrag sind Ihre stärksten Werkzeuge.

Wie prüfen Sie den Vertrag vor der Unterschrift?

Alle Punkte haben wir in einer Checkliste gebündelt. Können Sie vor der Unterschrift jede Zeile mit „ja" beantworten, haben Sie die wichtigsten Risiken weitgehend geschlossen.

• Der Vertrag räumt ausschließliche Nutzungsrechte inklusive Quellcode ein und nennt jede Nutzungsart.
• Es gibt keine zeitliche, räumliche oder inhaltliche Grenze.
• Nutzt die Agentur ein eigenes Framework, listet der Vertrag die lizenzierten Dateien auf.
• Die Agentur sichert zu, alle Rechte ihrer Subunternehmer zu besitzen.
• Ihr Unternehmen besitzt die Entwicklerkonten bei Apple und Google.
• Server, Datenbank, Domain und Drittanbieterkonten gehören Ihnen.
• Von Anfang an liegt der Code in Ihrem Repository.
• Die Lieferliste ist Anlage des Vertrags.
• Gewährleistungsphase und Wartungsbedingungen sind festgelegt.
• Zahlungen folgen den Meilensteinen.
• Vertraulichkeit gilt auch nach Vertragsende.

Notieren Sie beim Abgleich neben jeder Zeile die passende Vertragsziffer. So sehen Sie Lücken auf einen Blick. Schicken Sie die Liste außerdem vorab an den Entwickler. Ein seriöses Team beantwortet diese Fragen ohne Mühe und passt den Entwurf an. Weicht ein Angebot dagegen bei einer Zeile aus, ist das ein deutliches Warnsignal.

Betrachten Sie die Liste also als Ausgangspunkt. Ihr Projekt braucht womöglich weitere Klauseln; am sichersten ist daher eine anwaltliche Prüfung des finalen Textes.

Wie gehen Talha Aslan und Team in App Projekten mit dem Eigentum um?

In unseren Projekten zur Entwicklung mobiler Apps sprechen wir die Eigentumsfrage im ersten Termin an. Wir entwickeln Ihre App und bringen sie für Sie in die Stores. Entwicklerkonten, Server und Repository legen wir dabei von Anfang an auf Ihren Namen an. In diesen Konten arbeiten wir nur mit den Rechten, die wir für unsere Aufgabe brauchen.

Unser Angebot zeigt Lieferliste, Gewährleistungsphase und Wartungsoptionen als getrennte Abschnitte. So sehen Sie vor der Unterschrift, welche Position wann an Sie übergeht. Nutzen wir in einem Teil des Projekts ein eigenes Framework, sagen wir das klar.

Ist Ihre App Idee reif, oder liegt ein halbfertiges Projekt bei Ihnen? Dann schauen wir es uns gemeinsam an. Fordern Sie über unsere Seite zur App Entwicklung ein Angebot an; wir erstellen Umfang und Lieferliste passend zu Ihrem Projekt.