Wie man einen Freelance-Vertrag für das Eigentum an Quellcode schreibt

1. Definieren Sie das genaue Ergebnis des Code-Eigentums

Bevor Sie eine einzige Klausel schreiben, entscheiden Sie, was der Kunde tatsächlich kauft. Vollübertragung, eine Lizenz oder Eigentum nur nach der endgültigen Zahlung sind nicht dasselbe, und der Vertrag sollte mit dem geschäftlichen Arrangement übereinstimmen, das Sie wirklich wollen. Wenn der Kunde erwartet, den Quellcode am ersten Tag zu besitzen, sagen Sie das. Wenn der Freelancer die Rechte bis zur letzten Rechnung behält, sagen Sie das auch. Ein vager Satz verursacht Monate der Reibung.

Hier wird es praktisch, wenn es darum geht, "wie man einen Freelance-Vertrag für das Eigentum an Quellcode schreibt". Ein Startup-Gründer möchte möglicherweise das gesamte Repository übertragen, während eine kleine Agentur möglicherweise nur eine breite Lizenz benötigt, um die App auszuführen. Das sind unterschiedliche Vereinbarungen. Ein Vertrag, der diese vermischt, kann beide Seiten verärgern, und keine Seite ist vollständig geschützt.

Verwenden Sie den Vertrag, um drei direkte Fragen zu beantworten: Wer besitzt den Code, wann wechselt das Eigentum und ob der Kunde die Arbeit modifizieren oder weiterverkaufen kann. Wenn die Antwort „nach der endgültigen Zahlung“ lautet, stellen Sie klar, dass keine Übertragung vor der Zahlung erfolgt. Wenn die Antwort „vollständige Übertragung ab Erstellung“ lautet, schreiben Sie das klar und ohne Drama. Kurze Sätze helfen hier.

Für einen guten Vergleich der sorgfältigen Plattformnutzung siehe wie man einen Freelancer sicher einstellt. Dieser Artikel handelt davon, Menschen weise auszuwählen; dieser hier handelt davon, den Deal aufzuschreiben, sobald Sie sie ausgewählt haben.

2. Identifizieren Sie die spezifischen Code-Assets im Umfang

Lass "Quellcode" nicht als wohlfühlende Phrase umherirren. Benenne die Vermögenswerte. Wenn das Projekt App-Code, Skripte, Repositories, Build-Dateien, Bereitstellungskonfigurationen, Dokumentation und jeden während des Projekts erstellten refaktorierten oder abgeleiteten Code umfasst, liste sie auf. Ein Vertrag, der nur "den Code" sagt, lädt später zu Streitigkeiten ein. Zwei Wörter sind nicht genug.

Denke in Ordnern und Dateien, nicht in Abstraktionen. Zum Beispiel kann der Umfang das Hauptanwendungs-Repository, ein separates Admin-Panel-Repo, CI-Skripte, Datenbank-Migrationsdateien, API-Wrapper und eine README umfassen, die die lokale Einrichtung erklärt. Wenn der Freelancer während des Projekts eine gepatchte Version eines bestehenden Moduls erstellt, entscheide, ob dieser Patch Teil des Lieferumfangs ist. Dieses Detail ist wichtig.

Hier ist eine einfache Möglichkeit, den Umfang zu formulieren: "Alle Quellcodes und verwandte Projektdateien, die für Projekt X erstellt wurden, einschließlich Code, der in Repository A geschrieben wurde, und jeden abgeleiteten oder refaktorierten Code, der während der Laufzeit dieser Vereinbarung produziert wurde." Dieser Satz ist nicht ausgefallen. Er funktioniert, weil er den Ort, die Art der Arbeit und den Zeitrahmen benennt.

Wenn das Projekt mehrere Repositories hat, füge eine nummerierte Liste an. Ein Repo, eine Zeile. Zwei Repos, zwei Zeilen. Der Vertrag sollte niemanden zwingen, zu raten, ob das mobile App-Bundle als Quellcode zählt oder nur als exportiertes Artefakt.

3. Füge eine klare Klausel zur Übertragung von geistigem Eigentum hinzu.

Die Klausel zur Übertragung von geistigem Eigentum ist das Herz des Vertrags. Sie sollte besagen, dass der Freelancer dem Kunden alle Rechte, Titel und Interessen am erstellten Code überträgt. Wenn die Übertragung bei der Erstellung erfolgt, sagen Sie das. Wenn sie bei der Zahlung erfolgt, sagen Sie stattdessen das. Die Klausel sollte nicht auf einer versteckten Annahme basieren.

Eine praktische Klausel könnte so lauten: „Nach vollständiger Zahlung aller fälligen Beträge aus diesem Vertrag überträgt der Freelancer dem Kunden alle geistigen Eigentumsrechte an den speziell für den Kunden im Rahmen dieses Projekts erstellten Liefergegenständen, mit Ausnahme von bereits bestehenden Materialien, die in Anhang A aufgeführt sind.“ Diese Formulierung gibt einen Übertragungspunkt, eine Zahlungsbedingung und eine Ausnahme. Drei bewegliche Teile, ein Satz.

Einige Verträge besagen auch, dass die Übertragung weltweit und für die gesamte Schutzdauer, einschließlich Verlängerungen und Erneuerungen, wo dies zulässig ist, wirksam ist. Solche Formulierungen sind üblich, da Software Jahre überdauern kann und niemand das Eigentum neu verhandeln möchte, wenn die App bereits in Produktion ist. Eine einzeilige Übertragung kann zu dünn sein, wenn das Recht in der relevanten Gerichtsbarkeit mehr Details erwartet.

Für einen verwandten Blick auf Plattformbedingungen und -regeln ist die Regeln der 24freelance.pro-Website. freelance Seite nützlicher Hintergrund. Sie wird die Klausel nicht für Sie schreiben, erinnert Sie jedoch daran, dass formale Regeln und Vertragsformulierungen nicht im Widerspruch zueinander stehen sollten.

4. Trennen Sie bereits vorhandene Werkzeuge, Vorlagen und wiederverwendbare Komponenten

Freelancer bringen oft ihre eigenen Helfer mit zur Arbeit. Eine Vorlage, eine benutzerdefinierte Dienstprogrammbibliothek, ein privater API-Wrapper oder ein Build-Skript können bereits vor Beginn des Projekts existieren. Der Vertrag sollte diese bereits bestehenden Arbeiten schützen und dem Kunden dennoch Rechte am endgültigen Produkt einräumen. Ohne diese Trennung könnte der Kunde glauben, er habe die gesamte Werkzeugkiste gekauft.

Die sauberste Methode ist, die ausgeschlossenen Materialien in einem Anhang oder einem Zeitplan zu benennen. Nennen Sie es Zeitplan A, Zeitplan B oder Anlage 1. Listen Sie jedes vorbestehende Werkzeug, jede Vorlage oder wiederverwendbare Komponente auf, die der Freelancer nicht abtritt. Wenn dem Kunden erlaubt ist, eines dieser Elemente im Lieferprodukt zu verwenden, geben Sie an, ob diese Nutzung unter einer Lizenz erfolgt und ob die Lizenz exklusiv oder nicht-exklusiv ist. Kleine Etiketten verhindern große Streitigkeiten.

Beispiel: Ein Freelancer erstellt einen Zahlungsfluss mit einer privaten Validierungsbibliothek, die zwei Jahre zuvor erstellt wurde. Der Vertrag kann festlegen, dass die Bibliothek im Besitz des Freelancers bleibt, während der Kunde eine unbefristete Lizenz erhält, die Bibliothek nur als in der gelieferten App eingebettet zu verwenden. Das schützt die frühere Arbeit des Freelancers und lässt dem Kunden dennoch ein nutzbares Produkt. Die Grenze zwischen „besessen“ und „lizenziert“ muss sichtbar sein.

Dies ist ein Bereich, in dem die Sprache des Anhangs vage Versprechen übertrifft. Wenn der Freelancer sagt: „Ich habe etwas wiederverwendbaren Code“, ist das nicht genug. Schreiben Sie die Namen in einen Zeitplan. Halten Sie die Ausnahmen schriftlich fest. Geben Sie die Nummer des Zeitplans im Haupttext an, damit niemand vergisst, ihn später zu öffnen.

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

Eigentumsklauseln sind nicht ausreichend, wenn der Kunde die Dateien tatsächlich nicht erhalten kann. Der Vertrag sollte den Git-Zugriff, die Commit-Historie, die Übergabe von Branches, den Transfer von Anmeldeinformationen, die Dokumentation und eine Erklärung, dass alle endgültigen Quelldateien bei der Abnahme geliefert werden, abdecken. Eine ausgefeilte rechtliche Klausel ist schön; ein fehlendes Repository-Passwort ist es nicht.

Definieren Sie, was Lieferung bedeutet. Schiebt der Freelancer den finalen Code in das vom Kunden besessene Repository? Stellt der Freelancer ein Zip-Archiv des gesamten Projekts zur Verfügung? Beinhaltet die Übergabe Datenbankschema-Notizen, Umgebungsvariablen und Bereitstellungsschritte? Wenn das Projekt von einem privaten Dienstkonto abhängt, sollte der Vertrag festlegen, wann diese Anmeldeinformationen an den Kunden übergeben oder rotiert werden. Ein verpasster Token kann den Start verzögern.

Halten Sie die Repository-Bedingungen konkret. Zum Beispiel: „Der Freelancer gewährt dem Kunden bis zum Lieferdatum Administratorzugang zum Projekt-Repository, bewahrt die Commit-Historie, es sei denn, der Kunde fordert eine saubere Übergabe, und überträgt die Kontrolle über alle für Produktionsarbeiten verwendeten Branches.“ Diese Formulierung deckt Zugriff, Historie und Branch-Eigentum an einem Ort ab. Wenn der Kunde einen separaten Staging-Branch möchte, benennen Sie ihn ebenfalls.

Gute Übergabebedingungen reduzieren auch den Streit um "Ich habe alles gesendet". Wenn die Annahme von der Lieferung der endgültigen Quelldateien abhängt, sagen Sie, welche Dateien das sind. Wenn die endgültige Dokumentation Einrichtungsnotizen enthält, listen Sie diese auf. Wenn das Projekt eine Cloud-Bereitstellung umfasst, können sogar die Anmeldeinformationen für diese Umgebung einen separaten Übergabeschritt erfordern, wo Cloud-Computing-Technologie die praktische Seite der Lieferung gestalten kann.

6. Vertraulichkeit, Open-Source- und Drittanbieter-Code-Regeln einbeziehen

Das Eigentum an Quellcode kann schnell kompliziert werden, wenn externer Code in das Projekt einfließt. Der Vertrag sollte nicht offengelegte Bibliotheken einschränken, eine Genehmigung für die Nutzung von Open-Source erfordern und die Offenlegung von Drittanbieterkomponenten oder -abhängigkeiten verlangen, die das Eigentum beeinflussen könnten. Wenn der Freelancer ein Paket unter einer Lizenz einfügt, die die kommerzielle Nutzung einschränkt, sollte der Kunde dies vor der Veröffentlichung wissen, nicht nachdem ein Support-Ticket eingegangen ist.

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 nur, wenn die Lizenzbedingungen nicht mit den Eigentumserwartungen des Kunden in Konflikt stehen. Das bedeutet, dass der Freelancer alle im Projekt verwendeten Komponenten wie GPL, LGPL, MIT, Apache oder ähnliche identifizieren und die praktischen Auswirkungen erklären muss. Die Namen sind wichtig.

Drittanbieter-Code verdient die gleiche Ehrlichkeit. Ein kostenpflichtiges SDK, ein Skript von einem früheren Arbeitgeber oder ein Snippet, das aus einem öffentlichen Repository kopiert wurde, kann das Eigentum komplizieren. Der Vertrag sollte die Offenlegung eines solchen Elements verlangen, bevor es aufgenommen wird. Wenn eine Genehmigung erforderlich ist, sollte der Genehmigungsprozess ein Schritt und keine Chat-Nachricht sein. Eine Notiz in Slack ist leicht zu verlieren.

Vertraulichkeit sollte auch die Inhalte des Repositories, Anmeldeinformationen, Architekturhinweise und Geschäftslogik abdecken. Das ist nicht nur rechtliche Hausarbeit. Ein Wettbewerber, der den Build-Prozess oder den Bereitstellungsfluss sieht, kann mehr gewinnen, als der Kunde beabsichtigt hat zu teilen. Wenn das Projekt öffentliche Fallstudien oder die Nutzung im Portfolio umfasst, sollte der Vertrag festlegen, ob der Freelancer nach dem Start Screenshots zeigen kann.

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

Der Eigentumsübergang hängt oft von der Zahlung ab. Das ist normal. Der Vertrag sollte festlegen, ob die Genehmigung von Meilensteinen oder die endgültige Zahlung den Eigentumsübergang auslöst, und er sollte sagen, was passiert, wenn das Projekt vorzeitig endet. Wenn der Übergang bei der Annahme erfolgt, definieren Sie die Annahme klar. Wenn er erfolgt, wenn die endgültige Rechnung bezahlt ist, schreiben Sie diese Bedingung in einfachem Englisch.

Lassen Sie das Timing nicht dem Gedächtnis überlassen. Eine Klausel kann besagen, dass die Liefergegenstände nach schriftlicher Genehmigung oder nach einer festgelegten Prüfungsfrist als akzeptiert gelten, wenn keine Ablehnungsmitteilung eintrifft. Dann binden Sie den Eigentumsübergang an dieses Akzeptanzereignis oder an den Erhalt der Zahlung nach der Akzeptanz. Ein Ereignis, eine Konsequenz. Diese Struktur verhindert, dass alle über die Reihenfolge der Abläufe streiten.

Die vorzeitige Kündigung benötigt ihre eigene Regel. Angenommen, der Kunde sagt nach Meilenstein 2 ab. Besitzt der Kunde den bereits bezahlten Code? Behalten die Freelancer die Rechte an unfertigen Modulen? Erhält der Kunde eine Lizenz zur Nutzung der Teilarbeiten oder nur eine Kopie zur internen Überprüfung? Der Vertrag sollte alle drei Fragen beantworten, bevor jemand mit dem Programmieren beginnt.

Für risikoreichere Projekte trennen einige Teams die Zahlung vom Eigentum. Der Freelancer kann bei jedem Meilenstein eine Teilzahlung erhalten, während das Eigentum am fertigen Code erst nach Abschluss des letzten Meilensteins übertragen wird. Das kann funktionieren, aber nur, wenn der Vertrag erklärt, ob teilweise bezahlter Code während des Projekts für die interne Nutzung lizenziert ist. Wenn die Antwort nein ist, sagen Sie nein.

8. Fügen Sie eine unterschriftsbereite Checkliste hinzu, bevor Sie den Vertrag senden

Bevor Sie den Vertrag senden, führen Sie eine Checkliste durch. Verwenden Sie Namen, Pfade und Daten. Projektname, Repo-Standort, Eigentumsklausel, ausgeschlossene Materialien, Lieferverpflichtungen und alle rechtlichen Überprüfungen, die für die spezifische Sprache der Gerichtsbarkeit erforderlich sind, sollten alle vorhanden sein. Wenn eines dieser Elemente fehlt, beheben Sie es zuerst. Eine hastige Unterschrift ist immer noch ein Risiko.

Hier ist eine praktische Liste vor dem Versand:

• Der Projektname stimmt mit dem Leistungsbeschreibung überein.
• Der Speicherort des Repositories ist durch URL oder exakten Pfad identifiziert.
• Die Eigentumsklausel sagt, wann der Transfer stattfindet.
• Ausgeschlossene Materialien sind in einem Zeitplan aufgeführt.
• Die Lieferverpflichtungen erwähnen Quelldateien, Dokumente und Zugriffe.
• Die Regeln für Open-Source- und Drittanbieter-Code sind schriftlich festgehalten.
• Akzeptanz- und Zahlungszeitpunkte sind verknüpft.
• Rechtsgebietsspezifische Sprache hat eine rechtliche Überprüfung.

Wenn der Vertrag für ein Team ist, das auch den öffentlichen Ruf schätzt, hilft es, zu überprüfen Bewertungen von Freelancern bevor mehr Arbeit zugewiesen wird. Ein Vertrag kann das Eigentum an Code schützen, aber er behebt keine schlechten Übergabeverhalten oder wiederholte verpasste Fristen. Zwei Sicherheitsvorkehrungen sind besser als eine.

Eine letzte praktische Anmerkung: Wenn das Projekt an einen Nischenplattform-Workflow gebunden ist, sollte der Vertrag nicht mit den eigenen Betriebsregeln der Seite, der Zahlungsabfolge oder dem Genehmigungsweg in Konflikt stehen. Deshalb führen viele Kunden eine kurze interne Checkliste neben dem Vertragsentwurf. Es klingt einfach. Einfach ist gut.