Freelance-Vertrag: Eigentum an Quellcode regeln

1. Legen Sie das genaue Ergebnis der Code-Eigentümerschaft fest

Bevor Sie eine einzige Klausel formulieren, sollten Sie klären, was der Kunde eigentlich kauft. Eine vollständige Abtretung, eine Lizenz oder Eigentum erst nach der Schlusszahlung sind nicht dasselbe, und der Vertrag sollte genau zu dem Geschäftsmodell passen, das Sie wirklich wollen. Wenn der Kunde erwartet, den Quellcode vom ersten Tag an zu besitzen, sagen Sie das. Wenn der Freelancer die Rechte bis zur Begleichung der letzten Rechnung behält, sagen Sie auch das. Ein einziger ungenauer Satz sorgt monatelang für Reibungen.

Hier wird aus „how to write a freelance contract for source code ownership“ etwas ganz Praktisches. Ein Startup-Gründer möchte vielleicht das gesamte Repository übertragen bekommen, während eine kleine Agentur nur eine umfassende Lizenz braucht, um die App zu betreiben. Das sind unterschiedliche Vereinbarungen. Ein Vertrag, der beides vermischt, kann beide Seiten verärgern und keine von beiden vollständig absichern. Genau deshalb sollte ein Freelance Vertrag Quellcode Eigentum schon am Anfang sauber festlegen, welche Rechte tatsächlich gemeint sind.

Nutzen Sie den Vertrag, um drei direkte Fragen zu beantworten: Wem gehört der Code, wann wechselt das Eigentum, und darf der Kunde die Arbeit verändern oder weiterverkaufen? Wenn die Antwort „nach der Schlusszahlung“ lautet, schreiben Sie ausdrücklich, dass vorher kein Übergang stattfindet. Wenn die Antwort „vollständige Abtretung ab Entstehung“ lautet, formulieren Sie das klar und ohne Umwege. Kurze Sätze helfen hier.

Für einen guten Vergleich zum sorgfältigen Umgang mit Plattformen sehen Sie wie man einen Freelancer sicher beauftragt. Dort geht es darum, Menschen klug auszuwählen; hier darum, die Vereinbarung festzuhalten, nachdem Sie sich entschieden haben.

2. Benennen Sie die konkreten Code-Assets im Leistungsumfang

Lassen Sie „Source Code“ nicht als wohlklingende Floskel im Raum stehen. Benennen Sie die Assets. Wenn das Projekt App-Code, Skripte, Repositories, Build-Dateien, Deployment-Konfigurationen, Dokumentation sowie während des Projekts erstellten refaktorierten oder abgeleiteten Code umfasst, listen Sie diese auf. Ein Vertrag, der nur von „dem Code“ spricht, lädt später zu Streit ein. Zwei Wörter reichen nicht.

Denken Sie in Ordnern und Dateien, nicht in Abstraktionen. Der Umfang kann zum Beispiel das Haupt-Repository der Anwendung, ein separates Admin-Panel-Repo, CI-Skripte, Datenbank-Migrationsdateien, API-Wrapper und eine README-Datei umfassen, die das lokale Setup erklärt. Wenn der Freelancer während des Projekts eine gepatchte Version eines vorhandenen Moduls erstellt, legen Sie fest, ob dieser Patch Teil der Lieferung ist. Dieses Detail ist wichtig.

Eine einfache Formulierung für den Umfang wäre: „Sämtlicher Quellcode und zugehörige Projektdateien, die für Projekt X erstellt wurden, einschließlich des in Repository A geschriebenen Codes sowie aller während der Laufzeit dieser Vereinbarung erstellten abgeleiteten oder refaktorierten Codebestandteile.“ Dieser Satz ist nicht elegant. Er funktioniert, weil er Ort, Art der Arbeit und Zeitfenster benennt. Ein gut ausgearbeiteter Mustervertrag Quellcode Rechte abtreten macht genau diese Zuordnung im Text sichtbar.

Wenn das Projekt mehrere Repositories umfasst, fügen Sie eine nummerierte Liste an. Ein Repo, eine Zeile. Zwei Repos, zwei Zeilen. Der Vertrag sollte niemanden raten lassen, ob das Mobile-App-Paket als Quellcode gilt oder nur als exportiertes Artefakt.

3. Fügen Sie eine klare Klausel zur Abtretung von Rechten ein

Die Klausel zur Abtretung von geistigem Eigentum ist das Herz des Vertrags. Sie sollte klar sagen, dass der Freelancer dem Kunden alle Rechte, Titel und Ansprüche am erstellten Code überträgt. Wenn die Übertragung bei Erstellung erfolgt, sagen Sie das. Wenn sie von der Zahlung abhängt, schreiben Sie auch das hinein. Die Klausel sollte nicht auf einer stillschweigenden Annahme beruhen.

Eine praktische Formulierung könnte lauten: „Nach vollständiger Zahlung aller nach dieser Vereinbarung geschuldeten Beträge tritt der Freelancer an den Kunden sämtliche geistigen Eigentumsrechte an den ausschließlich für den Kunden im Rahmen dieses Projekts erstellten Leistungen ab, ausgenommen vorbestehende Materialien, die in Anhang A aufgeführt sind.“ Diese Formulierung enthält den Übertragungszeitpunkt, die Zahlungsbedingung und eine Ausnahme. Drei bewegliche Teile, ein Satz.

Manche Verträge sagen außerdem, dass die Übertragung weltweit und für die gesamte Schutzdauer gilt, einschließlich Verlängerungen und Erneuerungen, soweit rechtlich zulässig. Solche Formulierungen sind üblich, weil Software über Jahre im Einsatz sein kann und niemand die Eigentumsfrage neu verhandeln will, wenn die App bereits produktiv läuft. Eine knappe Abtretung kann zu dünn sein, wenn das Recht im jeweiligen Land mehr Details verlangt. Wer eine saubere Quellcode Eigentumsübertragung Freelancer erreichen will, sollte diese Reichweite deshalb ausdrücklich benennen.

Für einen verwandten Blick auf Plattformbedingungen und Regeln ist die Seite Regeln der Seite 24freelance.pro. freelance als Hintergrund nützlich. Sie schreibt die Klausel nicht für Sie, erinnert aber daran, dass formale Regeln und Vertragsklauseln sich nicht widersprechen sollten.

4. Trennen Sie vorbestehende Werkzeuge, Vorlagen und wiederverwendbare Komponenten ab

Freelancer bringen oft eigene Hilfsmittel mit. Eine Vorlage, eine benutzerdefinierte Utility-Bibliothek, ein privater API-Wrapper oder ein Build-Skript kann bereits vor Projektbeginn existieren. Der Vertrag sollte dieses vorbestehende Material schützen und dem Kunden trotzdem Rechte am Endergebnis geben. Ohne diese Trennung könnte der Kunde glauben, das gesamte Werkzeugset gekauft zu haben.

Am saubersten ist es, ausgeschlossene Materialien in einem Anhang oder einer Anlage zu benennen. Nennen Sie sie Anhang A, Anhang B oder Anlage 1. Listen Sie jedes vorbestehende Werkzeug, jede Vorlage oder jede wiederverwendbare Komponente auf, die der Freelancer nicht abtritt. Wenn der Kunde eines dieser Elemente innerhalb der Lieferung verwenden darf, sagen Sie, ob dies auf Lizenzbasis geschieht und ob die Lizenz exklusiv oder nicht-exklusiv ist. Kleine Bezeichnungen verhindern große Konflikte.

Beispiel: Ein Freelancer baut einen Zahlungsprozess mit einer privaten Validierungsbibliothek, die zwei Jahre zuvor entstanden ist. Der Vertrag kann festhalten, dass die Bibliothek im Eigentum des Freelancers bleibt, während der Kunde eine unbefristete Lizenz erhält, sie nur eingebettet in die gelieferte App zu nutzen. Das schützt die frühere Arbeit des Freelancers und lässt dem Kunden dennoch ein brauchbares Produkt. Die Grenze zwischen „gehört“ und „lizenziert“ muss sichtbar sein.

Hier ist eine Anlage besser als vage Versprechen. Wenn der Freelancer sagt: „Ich habe etwas wiederverwendbaren Code“, reicht das nicht. Setzen Sie die Namen in einen Anhang. Schreiben Sie die Ausnahmen auf. Verweisen Sie im Haupttext auf die Anhangsnummer, damit niemand später vergisst, sie zu öffnen.

5. Legen Sie Anforderungen an Lieferung, Repository-Zugriff und Übergabe fest

Eigentumsklauseln reichen nicht aus, wenn der Kunde die Dateien am Ende nicht tatsächlich bekommt. Der Vertrag sollte Git-Zugriff, Commit-Historie, Branch-Übergabe, Übergabe von Zugangsdaten, Dokumentation und eine Erklärung umfassen, dass alle finalen Quelldateien bei Abnahme geliefert werden. Eine ausgefeilte juristische Klausel ist schön; ein fehlendes Repository-Passwort ist es nicht.

Formulieren Sie genau, was Lieferung bedeutet. Schiebt der Freelancer den finalen Code in das kundenbesessene Repository? Stellt er ein ZIP-Archiv des gesamten Projekts bereit? Umfasst die Übergabe Hinweise zum Datenbankschema, Umgebungsvariablen und Deploy-Schritten? Wenn das Projekt von einem privaten Servicekonto abhängt, sollte der Vertrag festlegen, wann diese Zugangsdaten an den Kunden übergehen oder rotiert werden. Ein fehlendes Token kann den Start blockieren.

Halten Sie die Repository-Regeln konkret. Zum Beispiel: „Der Freelancer gewährt dem Kunden bis zum Lieferdatum Admin-Zugriff auf das Projekt-Repository, behält die Commit-Historie bei, sofern der Kunde keine bereinigte Übergabe wünscht, und überträgt die Kontrolle über alle für die Produktionsarbeit verwendeten Branches.“ Diese Formulierung deckt Zugriff, Historie und Branch-Eigentum an einer Stelle ab. Wenn der Kunde einen separaten Staging-Branch möchte, nennen Sie auch diesen.

Gute Übergabeklauseln verringern auch den Streit „Ich habe alles geschickt“. Wenn die Abnahme von der Lieferung der finalen Quelldateien abhängt, sagen Sie, welche Dateien das sind. Wenn die finale Dokumentation Einrichtungsnotizen umfasst, listen Sie diese auf. Wenn das Projekt Cloud-Deployment beinhaltet, müssen sogar die Zugangsdaten für diese Umgebung möglicherweise separat übergeben werden — an dieser Stelle kann Cloud-Computing-Technologie die praktische Seite der Lieferung prägen.

6. Fügen Sie Regeln zu Vertraulichkeit, Open Source und Drittcode hinzu

Die Eigentümerschaft am Quellcode kann schnell kompliziert werden, sobald externer Code ins Projekt gelangt. Der Vertrag sollte nicht offengelegte Bibliotheken einschränken, die Nutzung von Open Source genehmigungspflichtig machen und die Offenlegung von Drittkomponenten oder Abhängigkeiten verlangen, die die Eigentumsfrage beeinflussen könnten. Wenn der Freelancer ein Paket mit einer Lizenz einbaut, die die kommerzielle Nutzung einschränkt, sollte der Kunde das vor dem Release wissen, nicht erst nach dem ersten Support-Ticket.

Setzen Sie eine Regel für Open-Source-Material. Zum Beispiel darf der Freelancer Open-Source-Code nur verwenden, wenn der Kunde dies schriftlich genehmigt und wenn die Lizenzbedingungen nicht mit den Eigentumserwartungen des Kunden kollidieren. Das bedeutet, dass der Freelancer jede GPL-, LGPL-, MIT-, Apache- oder ähnliche Komponente im Projekt benennen und die praktische Wirkung erklären muss. Die Namen sind wichtig.

Auch Drittcode verdient dieselbe Offenheit. Ein kostenpflichtiges SDK, ein Skript aus einem früheren Arbeitsverhältnis oder ein aus einem öffentlichen Repository kopierter Ausschnitt können die Eigentumslage verkomplizieren. Der Vertrag sollte verlangen, dass jede solche Komponente vor ihrer Einbindung offengelegt wird. Wenn eine Zustimmung erforderlich ist, machen Sie den Genehmigungsprozess zu einem festen Schritt, nicht zu einer Chat-Nachricht. Eine Notiz in Slack geht schnell verloren.

Vertraulichkeit sollte außerdem Repository-Inhalte, Zugangsdaten, Architektur-Notizen und Geschäftslogik abdecken. Das ist nicht nur juristische Verwaltung. Ein Wettbewerber, der den Build-Prozess oder den Deployment-Ablauf sieht, kann mehr erfahren, als der Kunde teilen wollte. Wenn das Projekt öffentliche Fallstudien oder eine Nutzung im Portfolio betrifft, sollte der Vertrag festhalten, ob der Freelancer nach dem Start Screenshots zeigen darf.

7. Definieren Sie Abnahme, Zahlung und den Zeitpunkt des Eigentumsübergangs

Der Eigentumsübergang hängt oft an der Zahlung. Das ist normal. Der Vertrag sollte festlegen, ob die Freigabe eines Meilensteins oder die Schlusszahlung den Eigentumsübergang auslöst, und er sollte regeln, was passiert, wenn das Projekt vorzeitig endet. Wenn der Übergang bei Abnahme erfolgt, definieren Sie die Abnahme klar. Wenn er bei Zahlung der Schlussrechnung erfolgt, schreiben Sie diese Bedingung in einfachem Deutsch auf.

Lassen Sie den Zeitpunkt nicht dem Gedächtnis. Eine Klausel kann festlegen, dass die Leistungen als abgenommen gelten, wenn eine schriftliche Freigabe vorliegt oder wenn innerhalb eines bestimmten Prüfzeitraums keine Ablehnung eingeht. Verknüpfen Sie dann den Eigentumsübergang mit diesem Abnahmeereignis oder mit dem Eingang der Zahlung nach der Abnahme. Ein Ereignis, eine Folge. Diese Struktur verhindert, dass alle über die Reihenfolge der Schritte streiten.

Eine vorzeitige Beendigung braucht eine eigene Regel. Angenommen, der Kunde kündigt nach Meilenstein 2. Gehört ihm dann der bereits bezahlte Code? Behält der Freelancer die Rechte an unfertigen Modulen? Erhält der Kunde eine Lizenz zur Nutzung der Teilleistung oder nur eine Kopie zur internen Prüfung? Der Vertrag sollte alle drei Fragen beantworten, bevor jemand mit dem Coden beginnt.

Bei Projekten mit höherem Risiko trennen manche Teams Zahlung und Eigentum. Der Freelancer erhält bei jedem Meilenstein eine Teilzahlung, während das Eigentum am fertigen Code erst nach Abschluss des letzten Meilensteins übergeht. Das kann funktionieren, aber nur wenn der Vertrag erklärt, ob teilweise bezahlter Code während des Projekts intern genutzt werden darf. Wenn nein, dann sagen Sie nein.

8. Fügen Sie vor dem Versenden des Vertrags eine unterschriftsreife Checkliste hinzu

Bevor Sie den Vertrag verschicken, gehen Sie eine Checkliste durch. Verwenden Sie Namen, Pfade und Daten. Projektname, Repository-Standort, Eigentumsklausel, ausgeschlossene Materialien, Lieferpflichten und eventuelle juristische Prüfung für länderspezifische Formulierungen sollten alle vorhanden sein. Fehlt einer dieser Punkte, korrigieren Sie ihn zuerst. Eine schnelle Unterschrift bleibt ein Risiko.

Hier ist eine praktische Liste vor dem Versand:

• Der Projektname stimmt mit der Leistungsbeschreibung überein.
• Der Repository-Standort ist per URL oder exaktem Pfad angegeben.
• Die Eigentumsklausel nennt den Zeitpunkt des Übergangs.
• Ausgeschlossene Materialien sind in einem Anhang aufgeführt.
• Die Lieferpflichten nennen Quelldateien, Dokumentation und Zugänge.
• Regeln zu Open Source und Drittcode sind ausgeschrieben.
• Abnahme- und Zahlungszeitpunkt sind miteinander verknüpft.
• Landesspezifische Formulierungen wurden rechtlich geprüft.

Wenn der Vertrag für ein Team gedacht ist, dem auch die öffentliche Reputation wichtig ist, lohnt sich ein Blick auf Freelancer-Bewertungen, bevor weitere Aufträge vergeben werden. Ein Vertrag kann die Eigentümerschaft am Code schützen, aber er behebt keine schlechten Übergabengewohnheiten oder wiederholte Terminversäumnisse. Zwei Schutzmechanismen sind besser als einer.

Ein letzter praktischer Hinweis: Wenn das Projekt an einen Nischen-Workflow auf einer Plattform gebunden ist, sollte der Vertrag nicht mit den eigenen Betriebsregeln der Seite, der Zahlungsreihenfolge oder dem Freigabeprozess kollidieren. Deshalb führen viele Kunden eine kurze interne Checkliste neben dem Vertragsentwurf. Das klingt schlicht. Schlicht ist gut.