Individuelle Apps: Wem gehört der Quellcode?

Die kurze Antwort: Durch die Bezahlung der Entwicklung erhalten Sie nicht automatisch den Quellcode oder das uneingeschränkte Recht, die Anwendung zu ändern und einem anderen Anbieter zu übergeben. Entscheidend ist, wer das Programm erstellt hat, in welchem Vertragsverhältnis diese Person tätig war und was der Vertrag regelt. Sichern Sie sich neben den Rechten am Code auch das Repository, die Dokumentation, die Konten, die Daten und einen geprüften Bereitstellungsprozess.

Trennen Sie zunächst Rechte, Dateien und Betrieb

Der Satz „Der Code gehört dem Kunden“ kann mehrere unterschiedliche Dinge bedeuten:

• wer die vermögensrechtlichen Urheberrechte am Programm ausübt;
• welche Lizenz der Auftraggeber in welchem Umfang erhält;
• wer Zugriff auf die Quelldateien und die Änderungshistorie hat;
• auf wen Cloud-, Domain- und Entwicklungskonten registriert sind;
• wer die Anwendung ändern, bereitstellen und an ein anderes Team übergeben darf;
• wer Betriebsdaten exportieren und das System aus einer Sicherung wiederherstellen darf.

Diese Fragen sind nicht deckungsgleich. Ein Unternehmen kann über eine weitreichende Lizenz verfügen, ohne den aktuellen Quellcode zu besitzen. Es kann eine Kopie des Repositorys haben, aber nicht berechtigt sein, sie einem neuen Anbieter zu übergeben. Und selbst wenn beides vorhanden ist, lässt sich die Anwendung ohne Datenbank, Schlüssel und Dokumentation möglicherweise trotzdem nicht starten.

Das praktische Ziel besteht daher nicht darin, „eine ZIP-Datei zu besitzen“. Ziel ist es, das System rechtlich und technisch betreiben, ändern, sichern und gefahrlos übernehmen zu können, ohne von einer einzigen Person abhängig zu sein.

Was der autorský zákon regelt

Am 2. Oktober 2026 führt e-Sbírka den zákon č. 121/2000 Sb. in der seit dem 1. Juli 2025 geltenden Fassung. Für individuell entwickelte Software sind insbesondere § 58, § 61 a § 66 autorského zákona, zákona č. 121/2000 Sb. relevant.

Urheber eines Programms ist die natürliche Person, die es erstellt hat. Rechtlich genügt es daher nicht, festzuhalten, dass der Kunde „zum Urheber wird“ oder die Urheberschaft auf ihn übertragen wird. Der Vertrag muss genau regeln, wer die vermögensrechtlichen Urheberrechte ausübt, welchen Umfang die Lizenz hat und ob der Quellcode übergeben werden muss.

Die gesetzliche Ausgangslage hängt davon ab, wer das Programm tatsächlich erstellt:

Wer das Programm erstellt	Gesetzliche Ausgangslage
Beschäftigter des Auftraggebers	Wurde das Programm zur Erfüllung von Pflichten aus einem arbeitsrechtlichen oder dienstlichen Verhältnis erstellt, kann der Auftraggeber als Arbeitgeber nach § 58 odst. 1 die vermögensrechtlichen Urheberrechte am Arbeitnehmerwerk ausüben, sofern nichts anderes vereinbart wurde.
Urheber als natürliche Person unmittelbar im Auftrag	Ein Computerprogramm, das kein Kollektivwerk ist und vom Urheber im Auftrag erstellt wurde, gilt nach § 58 odst. 7 als Arbeitnehmerwerk und der Auftraggeber als Arbeitgeber. Die vermögensrechtlichen Urheberrechte übt dann der Auftraggeber aus, sofern nichts anderes vereinbart wurde.
Beschäftigte eines Entwicklungsunternehmens	Wurde das Programm zur Erfüllung von Pflichten aus einem arbeitsrechtlichen oder dienstlichen Verhältnis erstellt, kann deren Arbeitgeber, also das beauftragte Entwicklungsunternehmen, nach § 58 odst. 1 die vermögensrechtlichen Urheberrechte am Arbeitnehmerwerk ausüben, sofern nichts anderes vereinbart wurde. Der Kunde benötigt die mit dem Anbieter vertraglich vereinbarten Nutzungsrechte.
Freiberufler und weitere Subunternehmer	Der Anbieter muss über die erforderlichen Rechte an jedem übernommenen Bestandteil verfügen und berechtigt sein, dem Kunden den vereinbarten Rechteumfang einzuräumen.

Bei Computerprogrammen, die ein Urheber im Auftrag erstellt hat, findet § 61 autorského zákona gemäß § 58 odst. 7 keine Anwendung. Auf die allgemeine Regelung für Auftragswerke kann daher nicht als Ersatz für einen präzisen Softwarevertrag vertraut werden.

Eine weitere Besonderheit betrifft die Übertragung der Ausübung vermögensrechtlicher Urheberrechte. Nach § 58 odst. 1 darf der Arbeitgeber dieses Recht nur mit Zustimmung des Urhebers auf einen Dritten übertragen; ausgenommen ist die Übertragung im Zusammenhang mit der Veräußerung eines Geschäftsbetriebs. Verlangt der Kunde eine solche Übertragung, muss der Anbieter prüfen, ob ihm die erforderlichen Zustimmungen vorliegen. In der Praxis kann eine genau definierte Lizenz geeigneter sein. Die richtige Lösung hängt vom Verhältnis zwischen den Urhebern, dem Anbieter und dem Auftraggeber ab.

Nach § 66 odst. 1 autorského zákona greift ein berechtigter Nutzer einer Programmkopie nicht in das Urheberrecht ein, wenn er das Programm ändert, soweit dies für dessen bestimmungsgemäße Einführung und Nutzung notwendig ist, oder wenn er Fehler behebt. Er darf außerdem eine Sicherungskopie erstellen, sofern diese für die Nutzung des Programms erforderlich ist. Diese Bestimmung gewährleistet jedoch nicht die Übergabe eines lesbaren Quellcodes, der Repository-Historie, der Dokumentation oder der Zugänge zur Infrastruktur.

Dies ist ein allgemeiner Überblick und keine rechtliche Beurteilung eines konkreten Vertrags. Lassen Sie das Dokument vor der Unterzeichnung von einem Rechtsanwalt prüfen, der auf Urheberrecht und IT spezialisiert ist.

Was der Vertrag regeln sollte

1. Umfang der Rechte am Programm

Der Satz „Der Auftraggeber darf die Anwendung nutzen“ reicht nicht aus. Der Vertrag sollte mindestens die folgenden Fragen beantworten:

• Darf der Auftraggeber die Anwendung auf eigener oder gemieteter Infrastruktur betreiben?
• Darf er sie durch eigene Beschäftigte oder einen anderen Anbieter ändern lassen?
• Darf er Entwicklungs-, Test-, Sicherungs- und Schulungsinstanzen erstellen?
• Darf er einem Auditor, Administrator oder Käufer des Unternehmens Zugriff auf den Quellcode gewähren?
• Gelten die Rechte auch für später beauftragte Module und Aktualisierungen?
• Ist die Lizenz ausschließlich oder nicht ausschließlich?
• Gilt sie ohne zeitliche, räumliche oder mengenmäßige Beschränkung?
• Bleiben die Rechte auch nach Beendigung des Servicevertrags bestehen?

Der Umfang muss der geplanten Nutzung entsprechen. Ein internes Verwaltungssystem für ein einzelnes Unternehmen erfordert andere Rechte als eine Plattform, die der Kunde seinen eigenen Kunden anbieten möchte.

2. Laufend zugängliches Repository

Der Quellcode sollte nicht erst am Ende als Archiv ohne Historie übergeben werden. Sicherer ist es, ihn fortlaufend in einer Organisation des Auftraggebers auf GitHub, GitLab oder Azure DevOps zu speichern. Der Auftraggeber sollte administrativen Zugriff besitzen, während der Anbieter nur die für die Entwicklung notwendigen Berechtigungen erhält.

Das Repository sollte alles enthalten, was zum Erstellen und Bereitstellen des vereinbarten Systemteils erforderlich ist:

• Frontend und Backend;
• Datenbankmigrationen;
• automatisierte Tests;
• Abhängigkeitsdefinitionen und festgeschriebene Versionen;
• Build- und Bereitstellungsskripte;
• CI/CD-Konfiguration;
• Container- oder Infrastrukturdefinitionen;
• eine Beispielkonfiguration ohne echte Passwörter und Schlüssel.

Zugangsdaten gehören nicht in das Repository. Der Vertrag sollte gesondert regeln, wo geheime Schlüssel gespeichert werden, wer sie verwaltet und wie ihre sichere Übergabe oder Ersetzung erfolgt.

3. Herkunft des Codes und Rechte der Subunternehmer

Der Anbieter muss nicht das gesamte System von Grund auf neu schreiben. Eine Anwendung kombiniert üblicherweise:

1. eigens für den Auftraggeber erstellten Code;
2. ältere Module des Anbieters;
3. Open-Source-Pakete;
4. kostenpflichtige Komponenten und Dienste Dritter;
5. von Freiberuflern oder generativen Werkzeugen erstellte Bestandteile.

Der Vertrag oder eine technische Anlage sollte diese Gruppen unterscheiden. Verlangen Sie bei Subunternehmern eine Bestätigung, dass der Anbieter die zur Einräumung der vereinbarten Lizenz notwendigen Rechte erworben hat. Bei älteren Modulen des Anbieters muss klar sein, ob Sie diese nach Ende der Zusammenarbeit weiter betreiben, ändern und einem anderen Administrator anvertrauen dürfen.

Automatisch erzeugter Code ist kein Grund, die Kontrollanforderungen zu senken. Die Verantwortung für Integration, Sicherheit und Herkunft des Ergebnisses muss Teil des Entwicklungsprozesses bleiben, wie wir im Artikel KI-Code: Wer hat ihn gelesen, bevor er zu den Nutzern gelangte? erläutern.

4. Verzeichnis der Bibliotheken und Lizenzen

Für ein Verzeichnis der Abhängigkeiten genügt eine Datei wie package.json, requirements.txt oder composer.json allein nicht. Sie benötigen außerdem die tatsächlich verwendeten Versionen einschließlich transitiver Abhängigkeiten sowie deren Lizenzen.

MIT, Apache License 2.0, GPL und AGPL sehen unterschiedliche Bedingungen vor. Der Anbieter kann dem Kunden keine weitergehenden Rechte einräumen, als er selbst vom Urheber einer Komponente erhalten hat. Zur Übergabe sollte daher ein aktuelles Verzeichnis der Komponenten und Lizenzen gehören, gegebenenfalls als maschinenlesbare Software-Stückliste.

Kennzeichnen Sie kostenpflichtige Vorlagen, Schriftarten, Kartendaten, Konnektoren, externe APIs und Cloud-Dienste gesondert. Der Quellcode allein reicht möglicherweise nicht aus, wenn eine zentrale Funktion von einer nicht übertragbaren Lizenz oder einem ausschließlich auf den Anbieter registrierten Konto abhängt.

5. Durch eine Inbetriebnahme geprüfte Dokumentation

Die Dokumentation sollte nicht nur die Benutzeroberflächen beschreiben. Ein neues Team benötigt mindestens:

• einen Überblick über die Architektur und die einzelnen Dienste;
• die unterstützten Versionen der Laufzeitumgebung;
• eine Anleitung für Build und Bereitstellung;
• Datenbankschema und Migrationen;
• eine Liste der Integrationsschnittstellen;
• Konfigurationsvariablen ohne ihre geheimen Werte;
• das Verfahren zur Sicherung und Wiederherstellung;
• Betriebskontrollen, Protokollierung und Lösungen für bekannte Fehler;
• das Vorgehen zur Wiederherstellung nach einem Ausfall.

Die zuverlässigste Abnahmeprüfung findet in einer sauberen Umgebung statt. Ein Entwickler, der nicht am Projekt beteiligt war, erhält ausschließlich das vereinbarte Repository, die Dokumentation und die Zugänge. Damit muss er die Anwendung erstellen, die Tests ausführen, eine Testinstanz bereitstellen und eine Datenkopie wiederherstellen können.

Die Wiederherstellung sollte tatsächlich durchgeführt werden. Es genügt nicht, nur zu prüfen, ob Sicherungsdateien vorhanden sind. Denselben Grundsatz behandelt der Artikel Wiederherstellungstest einer Sicherung: Durchführung und Dokumentation.

6. Konten unter Kontrolle des Auftraggebers

Insbesondere die folgenden Konten und Ressourcen sollten auf den Auftraggeber registriert sein:

• Domain und DNS-Verwaltung;
• Cloud-Konto und Abrechnung;
• Repository und Container-Registry;
• Produktions- und Sicherungsumgebung;
• Dienst zum Versand von E-Mails;
• Monitoring und zentrale Protokolle;
• Konten in den App-Stores für mobile Anwendungen;
• Zertifikate, Sicherungen und Identitätsadministratoren.

Der Anbieter sollte ein namentlich zugeordnetes Konto mit einer angemessenen Rolle erhalten. Ein gemeinsam verwendetes Passwort ohne Nachvollziehbarkeit und Mehrfaktorauthentifizierung erschwert sowohl Audits als auch die Beendigung des Zugriffs.

Betreibt der Anbieter die Anwendung in seiner eigenen Umgebung, muss der Vertrag den Export, die Migration und die Unterstützung beim Anbieterwechsel regeln. Die bloße Formulierung „Das Hosting übernimmt der Anbieter“ erklärt nicht, wie der Kunde das System übernehmen kann.

7. Daten und Exit-Plan

Die Rechte am Quellcode regeln nicht automatisch den Umgang mit den Betriebsdaten. Legen Sie daher im Vertrag fest:

• welche Daten übergeben werden;
• in welchem Format und in welcher Struktur die Übergabe erfolgt;
• ob der Export Anhänge, Metadaten und Verknüpfungen enthält;
• wie Verschlüsselungsschlüssel übergeben werden;
• wie Vollständigkeit und Lesbarkeit des Exports geprüft werden;
• wer bei der Migration Unterstützung leistet;
• wann die Konten des bisherigen Anbieters gesperrt werden;
• wie mit verbleibenden Datenkopien verfahren wird.

Der Exit-Plan sollte zu Beginn der Zusammenarbeit vorbereitet werden und nicht erst während eines Konflikts. Praktische Schritte für Konten, Passwörter und Dokumentation fasst auch der Artikel Ihr IT-Administrator ist gegangen? So übernehmen und übergeben Sie die Unternehmens-IT zusammen.

Schwache Übergabe versus übernahmefähiges System

Schwache Regelung	Übernahmefähiges System
Das Repository wird ausschließlich vom Anbieter verwaltet	Der Auftraggeber besitzt administrativen Zugriff
Am Ende wird eine ZIP-Datei ohne Historie übergeben	Der Code wird fortlaufend in ein gemeinsames Repository übertragen
Der Vertrag erlaubt nur die „Nutzung“	Die Rechte umfassen ausdrücklich Betrieb, Änderungen und Übergabe
Abhängigkeiten werden nicht dokumentiert	Die Übergabe enthält die Versionen der Komponenten und ihre Lizenzen
Nur ein Programmierer kennt den Bereitstellungsprozess	Das Verfahren ist schriftlich dokumentiert und in einer sauberen Umgebung geprüft
Die Cloud-Konten gehören dem Anbieter	Der Auftraggeber besitzt die Konten und weist Rollen zu
Der Export besteht aus einer Tabelle ohne Anhänge	Der Export umfasst Daten, Verknüpfungen, Dateien und Metadaten
Eine Sicherung ist lediglich vorhanden	Die Wiederherstellung wurde durchgeführt und dokumentiert

Ein niedrigerer Angebotspreis bedeutet nicht zwangsläufig geringere Gesamtkosten. Die Rekonstruktion von Datenbankmigrationen, nicht dokumentierten Abhängigkeiten oder die manuelle Übertragung von Daten kann einen späteren Anbieterwechsel erheblich verteuern.

Warnsignale vor der Unterzeichnung

Seien Sie vorsichtig, wenn der Anbieter:

• das Repository als rein interne Angelegenheit bezeichnet;
• sich weigert, die verwendeten Bibliotheken und Lizenzen zu dokumentieren;
• den Betrieb nur über sein eigenes Konto und ohne Exportverfahren anbietet;
• die Dokumentation erst nach Fertigstellung verspricht;
• weder Subunternehmer noch die Herkunft übernommener Module nennen will;
• behauptet, mit der Bezahlung der Rechnung sei automatisch alles geregelt;
• keine Bereitstellung aus dem Quellcode vorführen kann;
• Daten nur als Tabelle ohne Dateien und Verknüpfungen übergibt.

Die mündliche Zusicherung „Der Code gehört selbstverständlich Ihnen“ ersetzt weder konkrete Vertragsbestimmungen noch eine technische Abnahme.

Wenn Sie vor der Unterzeichnung oder bei einem Anbieterwechsel das Repository, die Zugänge, die Sicherungen und die Bereitstellbarkeit prüfen lassen möchten, übernehmen wir dies bei ITHOPE im Rahmen eines IT-Audits für kleine Unternehmen. Wenn Sie die Anwendung direkt bei uns beauftragen, gilt, was wir zur individuellen Anwendungsentwicklung angeben: Wir liefern ohne Vendor Lock-in, Code und Daten bleiben in Ihrer Hand und die Lösung kann auch lokal in Brünn betrieben werden. Ihre Anforderungen können Sie über eine unverbindliche Anfrage übermitteln. Das Ergebnis sollte eine konkrete Liste der fehlenden Rechte, Dateien, Konten und Schritte für eine sichere Übernahme sein und nicht nur eine allgemeine Bewertung.

Was Sie bei der Übernahme prüfen sollten

Prüfen Sie vor der Zahlung des letzten Preisanteils mindestens Folgendes:

• Der Auftraggeber besitzt administrativen Zugriff auf das Repository.
• Das Repository enthält die aktuelle Produktionsversion.
• Der Vertrag erlaubt den vereinbarten Betrieb, Änderungen und die Einbindung eines weiteren Anbieters.
• Der Anbieter hat seine Rechte an externen Bestandteilen nachgewiesen.
• Versionen und Lizenzen aller Abhängigkeiten sind bekannt.
• Aus dem Quellcode lässt sich eine saubere Instanz erstellen und bereitstellen.
• Die Tests können gemäß der Dokumentation ausgeführt werden.
• Die Datenbankmigrationen entsprechen dem Produktionsschema.
• Der vollständige Export enthält Daten, Anhänge und Metadaten.
• Eine Sicherung lässt sich wiederherstellen.
• Domains, Cloud-Ressourcen und zentrale Konten werden vom Auftraggeber kontrolliert.
• Geheime Schlüssel sind nicht im Quellcode gespeichert.
• Es gibt ein Verfahren zum Entzug der Zugriffsrechte des bisherigen Teams.

Häufig gestellte Fragen

Gehört uns der Quellcode, wenn wir die Rechnung bezahlt haben?

Die Zahlung der Rechnung allein reicht nicht aus. Entscheidend sind die Art der Entstehung des Programms, das Verhältnis des Urhebers zum Anbieter, die vertraglichen Rechte des Auftraggebers und die Vereinbarung über die Übergabe der Quelldateien. Die Rechnung bestätigt die Zahlung, nicht automatisch den Umfang der Lizenz oder die Vollständigkeit der Übergabe.

Reicht es aus, den Quellcode als ZIP-Datei zu übergeben?

Nein. Ein Archiv enthält in der Regel weder die Änderungshistorie noch Branch-Einstellungen, Bereitstellungsautomatisierung oder eine Übersicht der verwendeten Versionen. Ohne Dokumentation, Datenbankmigrationen, Zugänge und einen geprüften Build kann eine solche Kopie praktisch unbrauchbar sein.

Darf der Anbieter seine älteren Module verwenden?

Ja, sofern er über die dafür erforderlichen Rechte verfügt. Der Vertrag muss diese Module von den für den Kunden erstellten Bestandteilen unterscheiden und festlegen, ob der Auftraggeber sie nach Beendigung der Zusammenarbeit weiter betreiben, ändern und einem neuen Administrator zugänglich machen darf.

Was gilt, wenn die Anwendung Open-Source-Bibliotheken enthält?

Jede Bibliothek unterliegt ihrer eigenen Lizenz. Verlangen Sie ein Verzeichnis der Komponenten, der verwendeten Versionen und der Lizenzen. Führen Sie dieselbe Prüfung auch für Schriftarten, Vorlagen, Karten, kostenpflichtige Pakete und externe Dienste durch.

Wie erkennen wir, ob ein anderes Team das System tatsächlich übernehmen kann?

Lassen Sie einen unabhängigen Entwickler ausschließlich anhand des übergebenen Repositorys, der Dokumentation und der Zugänge eine Testumgebung erstellen. Führen Sie gleichzeitig die Wiederherstellung einer Sicherung und einen vollständigen Datenexport durch und prüfen Sie, ob der Vertrag die Weitergabe des Codes an einen neuen Anbieter erlaubt.

Wo Sie uns finden

ITHOPE ist eine Firma aus Brno, Tschechien: wir machen Datenrettung von Festplatten, RAID und NAS, PC- und Notebook-Service und IT für Unternehmen, alles im eigenen Labor in der Viniční 3587/216, 615 00 Brno.

Telefon +420 775 556 063 (rund um die Uhr). Das Gerät können Sie persönlich bringen oder per Kurier schicken (Zásilkovna, PPL).