Wie Vertragsklauseln für Auslandsentwickler den Code schützen

Der sicherste Vertrag für die Entwicklung im Ausland behandelt Eigentum als Beweiskette, nicht als einzelnen Satz, wonach der Kunde den Code besitzt. Eine durchsetzbare schriftliche Übertragung ist wichtig, deckt aber nur die Rechte ab, die der Unterzeichner tatsächlich hat. Wenn ein nicht offengelegter Subunternehmer ein Modul geschrieben hat, eine alte Bibliothek des Gründers in das Produkt gelangt ist oder allein der Anbieter das Repository kontrolliert, kann selbst die weiteste Eigentumsklausel dem Kunden nur einen Anspruch statt nutzbarer Software verschaffen.

Dieser Artikel bietet einen Formulierungsrahmen, den kaufmännische und technische Teams ihrer Rechtsberatung vorlegen können. Er ist keine Rechtsberatung, und keine Vorlage kann das anwendbare Recht, den Beschäftigungsstatus, die steuerliche Behandlung oder Rechtsbehelfe für ein bestimmtes Land festlegen. Vor der rechtlichen Prüfung sollten Teams den Code, die Personen, Konten, Abhängigkeiten, Nachweise und Übergabepflichten ermitteln, die der Vertrag erfassen muss. Die Rechtsberatung kann diese Tatsachen dann an die Orte anpassen, an denen Kunde, Anbieter und Entwickler tätig sind.

So erfasst die Übertragung sämtliche Liefergegenstände

Verwenden Sie eine sofortige Übertragung definierter Rechte mit einer Mitwirkungspflicht für weitere Handlungen, statt sich auf „work made for hire“ oder ein Versprechen zur späteren Übertragung zu verlassen. Nach US-Recht verlangt 17 U.S.C. § 204 bei einer Urheberrechtsübertragung grundsätzlich eine vom Rechteinhaber unterzeichnete Schriftform. Das Circular 30 des U.S. Copyright Office erklärt auch, warum eine Auftragsarbeit nicht automatisch als „work made for hire“ gilt: Die Arbeit eines selbstständigen Auftragnehmers muss in eine der gesetzlichen Kategorien fallen, und die Parteien müssen dies ausdrücklich schriftlich vereinbaren. Gewöhnliche Individualsoftware fällt möglicherweise nicht in diese Kategorien, weshalb der Vertrag selbst dann eine Übertragung enthalten sollte, wenn er zusätzlich diese Rechtsfigur nennt.

Definieren Sie „Liefergegenstände“ weit genug, damit mehr als produktive Quellcodedateien erfasst werden. Die Definition sollte Quellcode, Objektcode, Skripte, Infrastrukturdefinitionen, Datenbankschemata und Migrationen, Tests, für das Projekt erstellte Modell-Prompts und Evaluierungsdatensätze, Entwürfe, technische Dokumentation, Build-Dateien, Bereitstellungsanweisungen und Änderungen an all diesen Elementen einschließen. Verbinden Sie die Definition mit Leistungsbeschreibungen, Tickets, Commits und anderen schriftlichen Aufgabenaufzeichnungen, damit ein fehlender Anhang keine Lücke schafft.

Die Einräumung sollte Urheberrechte und weitere übertragbare Rechte des geistigen Eigentums weltweit für deren gesamte Dauer einschließlich Verlängerungen erfassen. Sie sollte dem Kunden das Recht geben, die Liefergegenstände zu nutzen, zu vervielfältigen, zu ändern, zu verbreiten, anzuzeigen, auszuführen, zu bearbeiten, zu vermarkten, unterzulizenzieren und zu übertragen. Die Rechtsberatung muss entscheiden, wie Patente, Datenbankrechte, Halbleiterschutzrechte und ähnliche Rechte auf Projekt und Rechtsordnungen anzuwenden sind. Eine Klausel, die nur sagt „der Kunde besitzt sämtliche Arbeitsergebnisse“, kann die Absicht ausdrücken, beantwortet aber weder, welche Rechte wann übertragen wurden, noch welche Materialien dazugehören.

Ein nützlicher Ausgangspunkt für die rechtliche Prüfung lautet:

Der Entwickler überträgt dem Kunden hiermit unwiderruflich, jeweils mit ihrer Entstehung, sämtliche Rechte, Rechtspositionen und Ansprüche an jedem Liefergegenstand, einschließlich aller Urheberrechte und sonstigen übertragbaren Rechte des geistigen Eigentums, für die gesamte Dauer dieser Rechte weltweit. Soweit ein Recht bei Entstehung nicht übertragen werden kann, überträgt der Entwickler es unverzüglich, sobald eine Übertragung rechtlich möglich ist, und gewährt dem Kunden bis zum Wirksamwerden der Übertragung eine ausschließliche, unwiderrufliche, unbefristete, weltweite, übertragbare, unterlizenzierbare und vollständig abgegoltene Lizenz zur Ausübung dieses Rechts. Der Entwickler unterzeichnet weitere Dokumente und nimmt angemessene Handlungen vor, die zur Bestätigung, Registrierung oder Durchsetzung der Rechte des Kunden erforderlich sind.

Diese Ersatzlizenz ist wichtig, wenn örtliches Recht die Vorausübertragung begrenzt oder einzelne Rechte als nicht übertragbar behandelt. Die Rechtsberatung sollte auch Urheberpersönlichkeitsrechte und vergleichbare persönliche Rechte regeln. Der Vertrag kann einen Verzicht verlangen, soweit das Gesetz ihn zulässt, und andernfalls die unwiderrufliche Zustimmung des Urhebers, diese Rechte nicht gegen die erlaubte Nutzung des Kunden geltend zu machen. Formulieren Sie keinen absoluten Verzicht in der Annahme, jedes Land werde ihn anerkennen.

Legen Sie fest, ob das Eigentum bei Entstehung, Zahlung oder Abnahme übergeht. Kunden wollen meist eine Übertragung bei Entstehung und behandeln Zahlungsstreitigkeiten als vertragliche Ansprüche. Anbieter können verlangen, dass die Übertragung von der vollständigen Zahlung abhängt. Beide Positionen sind verhandelbar, doch Schweigen ist schlechter: Ein Team sollte nicht während einer Finanzierung oder Übernahme feststellen, dass ein unbezahlter Änderungsauftrag angeblich den Rechtserwerb am gesamten Repository blockiert.

Vorbestehendes geistiges Eigentum braucht eine Liste und dauerhafte Lizenz

Trennen Sie neue Liefergegenstände von vorbestehendem geistigem Eigentum, weil eine Übertragungsklausel nicht gefahrlos Werkzeuge erfassen kann, die der Anbieter bereits besaß oder gar nicht übertragen durfte. Dazu gehören vorhandene Frameworks, interne Bibliotheken, Vorlagen, Generatoren, Dienstprogramme, Know-how und Drittmaterial, das der Anbieter in die Liefergegenstände einbauen oder für deren Betrieb verwenden will. Der Vertrag sollte vor der Nutzung eine schriftliche Liste verlangen, nicht einen unbestimmten Vorbehalt für „sämtliche vorbestehenden Materialien“.

Die Liste sollte jeden Gegenstand, seinen Inhaber, die Version oder den Commit, Lizenzbedingungen, Zweck, Einbauort und die Frage nennen, ob das fertige System ohne ihn gewartet werden kann. Wenn der Anbieter ein proprietäres Bereitstellungsframework verwendet, fragen Sie, ob der Kunde dessen Quellcode, nur eine ausführbare Kopie oder einen vom Anbieter kontrollierten Fernzugang erhält. Das sind unterschiedliche Abhängigkeitsrisiken. Ein System, das sich nur über die private Toolchain des Anbieters bauen lässt, ist nicht unabhängig, nur weil dem Kunden das Anwendungs-Repository gehört.

Für genehmigtes vorbestehendes geistiges Eigentum, das in einen Liefergegenstand eingebaut oder zu dessen Nutzung nötig ist, verlangen Sie eine Lizenz, die den erwarteten Lebenszyklus des Kunden abdeckt. Typische Elemente sind eine unbefristete, weltweite, unwiderrufliche, vollständig abgegoltene, übertragbare und unterlizenzierbare Lizenz zum Nutzen, Kopieren, Ändern, Warten, Verbreiten und Bearbeiten, einschließlich erforderlicher Rechte für verbundene Unternehmen, Hosting-Anbieter, Erwerber, Kunden und Ersatzentwickler. Die Rechtsberatung sollte den gewünschten Umfang am örtlichen Recht und an der tatsächlichen Befugnis des Anbieters messen.

Nennen Sie eine ausdrückliche Folge für ausgelassene Gegenstände:

Der Entwickler wird vorbestehende Materialien nur einbinden, wenn der Kunde sie schriftlich genehmigt und die Parteien sie vor dem Einbau in Anlage B aufnehmen. Für ohne diese Genehmigung eingebaute vorbestehende Materialien gewährt der Entwickler dem Kunden die weiteste in diesem Vertrag genannte Lizenz und ersetzt auf eigene Kosten jedes Material, zu dessen Lizenzierung er nicht befugt ist, ohne Funktion, Sicherheit oder Wartbarkeit wesentlich zu mindern.

Diese Formulierung schafft einen Anreiz zur Offenlegung, erzeugt aber keine Rechte, die der Anbieter nie hatte. Die Austauschpflicht und eine passende Freistellung geben dem Kunden vertragliche Ansprüche. Die technische Prüfung muss die Liste dennoch mit dem Repository und der Software-Stückliste abgleichen. Steht im Vertragsanhang „keine“, während der Abhängigkeitsscan einen privaten Paket-Namespace findet, stoppen Sie die Abnahme und klären die Abweichung.

Führen Sie auch Materialien des Kunden in einer eigenen Kategorie. Spezifikationen, Daten, Marken, vorhandener Code, Zugangsdaten und Geschäftsregeln des Kunden bleiben dessen Eigentum. Gewähren Sie dem Anbieter eine begrenzte Lizenz nur zur Ausführung des Projekts, untersagen Sie die Wiederverwendung für andere Kunden und verlangen Sie bei Ende Rückgabe oder Löschung, vorbehaltlich enger, rechtlich geprüfter Aufbewahrungspflichten.

Die Repository-Kontrolle beginnt mit dem ersten Commit

Legen Sie das maßgebliche Repository von Anfang an in einer vom Kunden kontrollierten Organisation an, mit Kundenadministratoren, verpflichtender Mehrfaktorauthentifizierung, geschützten Branches und einem Verzeichnis aller Mitwirkenden. Ein vertraglicher Anspruch auf Code am Ende ist schwächer als laufende Verwahrung. ZIP-Dateien zum Projektende lassen regelmäßig Branches, Tags, Ticketverlauf, Large-File-Objekte, Submodule, Bereitstellungskonfiguration oder die genauen Abhängigkeitsversionen für einen erneuten Build aus.

Der Vertrag sollte das führende System benennen und wesentliche Arbeit in nicht offengelegten Repositories untersagen. Verpflichten Sie Entwickler, abgeschlossene Arbeit in vereinbarter Häufigkeit hochzuladen, Commit-Autoren und Zeitangaben zu erhalten, vom Kunden genehmigte Konten zu nutzen und Änderungen nach dem vereinbarten Prüfverfahren einzureichen. Geben Sie dem Kunden durchgehenden Lese- und Exportzugriff sowie einen zu seinem Sicherheitsmodell passenden administrativen Zugang. Der Anbieter kann seine Arbeitsberechtigungen behalten, ohne die einzige Partei zu sein, die den Zugang wiederherstellen kann.

Repository-Zugriff ist nicht dasselbe wie Eigentum. Eine Kopie beweist nicht, dass jeder Mitwirkende Rechte übertragen hat. Eigentum ist auch nicht dasselbe wie betriebliche Kontrolle: Eine unterzeichnete Übertragung liefert keinen fehlenden Signaturschlüssel, kein Cloud-Konto, keine Paket-Registry und keine Domain. Vertrag und technische Einrichtung müssen beide Unterschiede abdecken.

Lassen Sie die Rechtsberatung Zugriffsverstöße konkret fassen. Der Vertrag kann die Sperrung des Kundenzugangs, die Verlagerung der Arbeit in ein nicht genehmigtes Repository, das Löschen des Verlaufs oder das Zurückhalten von Zugangsdaten nach einer Aufforderung als wesentliche Vertragsverletzung behandeln. Er sollte dem Kunden während des Projekts Backups und Exporte erlauben. Vermeiden Sie Regelungen, nach denen der Anbieter Repositories oder Produktivsysteme abschalten darf, sobald er einen Zahlungsstreit behauptet; die Rechtsberatung kann ein Streitverfahren vorsehen und Rechte wahren, ohne den Betrieb zur Geisel zu machen.

Die Projektleitung sollte diese Verwahrungsprüfung an jedem Meilenstein durchführen können:

1. Das Repository mit einem kundeneigenen Konto in eine saubere Umgebung klonen.
2. Sämtliche Branches, Tags, Submodule und Large-File-Objekte abrufen und das Ergebnis mit dem führenden System vergleichen.
3. Nach den eingecheckten Anweisungen bauen und testen, wobei Zugangsdaten aus dem genehmigten Secret Store stammen.
4. Jeden aktiven Mitwirkenden einem unterzeichneten Vertrag und jede ungewöhnliche Abhängigkeit der genehmigten Materialliste zuordnen.
5. Tickets, Release-Aufzeichnungen, Build-Definitionen, Paketmetadaten und erforderliche Konfiguration ohne exklusiven Anbieterzugriff exportieren.

Ein fehlgeschlagener Build bedeutet nicht immer schlechten Code. Häufig deckt er ein nicht dokumentiertes Registry-Token, ein über das Privatkonto eines Auftragnehmers veröffentlichtes Paket oder einen manuellen Produktionsschritt auf. Genau deshalb gehören Verwahrungstests in die laufende Zusammenarbeit und nicht auf den letzten Arbeitstag des Anbieters.

Open-Source-Freigaben müssen der tatsächlichen Lizenz folgen

Verbieten Sie Open Source nicht reflexartig vollständig. Verlangen Sie Offenlegung, Freigaberegeln nach Lizenz und Nutzung, eine Software-Stückliste, erhaltene Hinweise und die Einhaltung der tatsächlich geltenden Lizenzen. Ein pauschales Verbot klingt schützend, doch moderne Anwendungen hängen von Open-Source-Paketen und Toolchains ab. Es führt oft zu unzutreffenden Bestätigungen oder versteckten Abhängigkeiten.

Der Vertrag sollte Entwicklungswerkzeuge von Komponenten unterscheiden, die ausgeliefert, verbreitet, geändert, verlinkt, in ein Gerät eingebettet oder für einen Netzwerkdienst eingesetzt werden. Diese Tatsachen können Pflichten verändern. Die Open Source Initiative erklärt, dass Copyleft-Anforderungen unterschiedlich sind und die bloße Verbreitung eines Werks neben einem anderen das zweite nicht automatisch der Copyleft-Lizenz unterwirft. Sie weist auch darauf hin, dass die GNU Affero General Public License ein Quellcodeangebot verlangen kann, wenn Nutzer über ein Netzwerk mit geänderter Software interagieren. Die Rechtsberatung muss den Text jeder relevanten Lizenz und die Produktnutzung prüfen, statt alle offenen Komponenten als „permissiv“ oder „viral“ einzustufen.

Verpflichten Sie den Anbieter zu einem maschinenlesbaren Verzeichnis mit mindestens Komponentenname, Version, Quelle, Urheberrechtshinweis, Lizenzkennung, Änderungsstatus und Ort im Produkt. SPDX-Kennungen helfen bei einheitlichen Angaben, ersetzen aber keine rechtliche Prüfung. Das Verzeichnis sollte auch angeben, ob ein Paket nur in der Entwicklung vorkommt, Teil eines verbreiteten Artefakts ist oder in einem gehosteten Dienst verwendet wird.

Legen Sie eine Freigaberichtlinie fest, die technische Mitarbeiter anwenden können. So kann der Vertrag aufgeführte hinweisbasierte Lizenzen erlauben, wenn der Anbieter vorgeschriebene Hinweise bewahrt, für reziproke oder Source-Available-Bedingungen eine schriftliche Genehmigung verlangen und Code ohne erkennbare Lizenz untersagen. Die Rechtsberatung sollte Kategorien und Ausnahmen wählen. „Öffentlich verfügbar“ bedeutet nicht lizenziert, und ein Repository ohne Lizenz gibt Außenstehenden normalerweise keine allgemeine Kopiererlaubnis.

Die OpenChain-Spezifikation ISO/IEC 5230 beschreibt Anforderungen an ein Programm zur Einhaltung von Open-Source-Lizenzen. Sie bestätigt den vertraglich relevanten Prozessgedanken: Jemand muss die Richtlinie verantworten, identifizierte Lizenzen prüfen, Aufzeichnungen führen und Verstöße korrigieren. Eine Anbietergarantie mit dem Inhalt „wir halten Open Source ein“ liefert wenig betrieblichen Nachweis, wenn die Lieferung nicht auch Verzeichnis, Hinweise, nötige Quellcodeangebotsunterlagen und eine Abhilfepflicht enthält.

Verlangen Sie eine schnelle Mitteilung, wenn der Anbieter einen Konflikt entdeckt. Der Rechtsbehelf sollte den Kunden, soweit wirtschaftlich angemessen, zwischen ausreichender Rechtebeschaffung, Austausch der Komponente, Änderung des Liefergegenstands zur Konfliktbeseitigung oder Erstattung der betroffenen Arbeit wählen lassen. Ein Ersatz muss vereinbarte Funktion, Sicherheit und Wartbarkeit erhalten. Die Rechtsberatung kann diesen Rechtsbehelf mit IP-Garantien, Freistellungen, Haftungsgrenzen und Ausnahmen abstimmen.

Jeder Subunternehmer braucht dieselbe Rechtekette

Machen Sie den Vertragspartner für jede Person und Gesellschaft verantwortlich, die an der Arbeit beteiligt ist, einschließlich verbundener Unternehmen, Personaldienstleister, Freelancer und nachgeordneter Subunternehmer. Die Genehmigung sollte vor Zugriff oder Beitrag erfolgen, wobei der Kunde den rechtlichen Namen, Arbeitgeber, Arbeitsstaat, die Rolle und den Zugriffsumfang erfährt. Diese Angaben betreffen geistiges Eigentum, Vertraulichkeit, Datenschutz, Exportkontrollen, Sanktionen und Sicherheitsprüfungen.

Der Anbieter sollte von jedem Mitwirkenden schriftliche Bedingungen verlangen, die bei Übertragung, Vertraulichkeit, vorbestehenden Materialien, Open Source, Sicherheit, Datennutzung und Übergabe mindestens so schützend sind wie der Hauptvertrag. „Der Anbieter bleibt verantwortlich“ ist nötig, überträgt aber nicht von selbst das Urheberrecht eines Freelancers auf den Kunden. Verlangen Sie die Aufbewahrung unterzeichneter Mitwirkendenvereinbarungen und auf Anfrage Kopien oder andere Nachweise der relevanten Rechte, wobei sachfremde personenbezogene Daten rechtmäßig geschwärzt werden können.

Eine saubere Kette folgt meist einem von zwei dokumentierten Wegen: Jede Person überträgt an den Anbieter und dieser an den Kunden, oder jede Person überträgt direkt an den Kunden, während der Anbieter die Unterlagen verwaltet. Die Rechtsberatung sollte einen unter den einschlägigen Gesetzen wirksamen Weg wählen. Vermischte Wege ohne Verzeichnis erschweren Prüfungen, weil niemand sagen kann, welches Dokument welchen Commit erfasst.

Akzeptieren Sie die nachträgliche Bereinigung nicht als Normalverfahren. Ehemalige Mitwirkende können die Unterschrift verweigern, verschwinden oder eine neue Zahlung verlangen, sobald eine Finanzierungsfrist Druck erzeugt. Koppeln Sie Repository-Berechtigungen an vollständige Onboarding-Unterlagen und sperren Sie den Zugang beim Ausscheiden. Das Mitwirkendenverzeichnis sollte mit Repository-Verlauf, Codeprüfungen und abgerechneter Besetzung übereinstimmen.

Auch weitergereichte Pflichten brauchen einen Durchsetzungsmechanismus. Der Anbieter sollte garantieren, dass er die nötigen Rechte eingeholt hat, für Handlungen von Subunternehmern haften und Lücken auf eigene Kosten schließen. Die Rechtsberatung kann entscheiden, ob der Kunde unmittelbare Durchsetzungsrechte, beigefügte Übertragungsformulare, Prüfungsrechte und eine Freistellung für IP-Ansprüche Dritter benötigt.

Die Abnahme prüft Qualität, ohne still Eigentum zu ändern

Definieren Sie Abnahme als Prüfung der vereinbarten Liefergegenstände, nicht als Ereignis, das zufällig über das Eigentum des Kunden entscheidet. Eine Leistungsbeschreibung sollte objektive Abnahmekriterien, Prüfungsfrist, Verfahren für Ablehnungsmitteilungen, Nachbesserungsfristen, erneute Tests und die Behandlung kleiner Mängel nennen. Sie sollte auch regeln, was bei produktiver Nutzung oder ausbleibender Antwort bis zur Frist passiert.

Vermeiden Sie „zur Zufriedenheit des Kunden“ als einzigen Maßstab. Das lädt zum Streit ein, gibt dem Lieferteam kein reproduzierbares Ziel und lässt sich über Zeitzonen hinweg schwer verwalten. Vermeiden Sie ebenso die automatische Abnahme nach sehr kurzem Schweigen. Die Prüfung kann erst beginnen, wenn der Anbieter Code, Dokumentation, Testnachweise, Build-Anweisungen, Zugangsdaten, Verzeichnisse und sonstige geschuldete Unterlagen liefert.

Eine Abnahmematrix kann Rechtsbegriffe mit beobachtbaren Nachweisen verbinden:

1. Die Quellcodevollständigkeit ist erfüllt, wenn ein sauberer Klon das markierte Release baut; andernfalls folgen Ablehnung und Nachbesserung.
2. Die Rechtekette ist erfüllt, wenn das Mitwirkendenverzeichnis zum Commit-Verlauf passt; Lücken erfordern Dokumente oder Ersatzcode.
3. Die Abhängigkeitskonformität ist erfüllt, wenn Software-Stückliste und Hinweise zum Release passen; andernfalls sind Korrektur, Ersatz oder eine genehmigte Ausnahme nötig.
4. Sicherheit und Qualität sind erfüllt, wenn vereinbarte Tests dokumentierte erfolgreiche Ergebnisse liefern; andernfalls folgen Korrektur und erneuter Test.
5. Der Betrieb ist erfüllt, wenn der Kunde anhand schriftlicher Anweisungen in die vereinbarte Umgebung bereitstellt; andernfalls folgen Ablehnung und unterstützte Übergabe.

Halten Sie Zahlungsmeilensteine, Abnahme, Gewährleistung und Rechtsübergang in getrennten Klauseln mit bewussten Querverweisen. Eine häufige Struktur zahlt einen Teil bei Meilensteinlieferung und einen Teil bei Abnahme, während die Rechte nach der ausgehandelten Regel bei Entstehung oder Zahlung übergehen. Die Gewährleistungsfrist deckt anschließend nach Abnahme entdeckte Mängel. Wollen die Parteien etwas anderes, sollten sie es festhalten, statt eine Rechnung darüber entscheiden zu lassen.

Änderungskontrolle gehört hierher, weil unklarer Umfang zu unklarem Eigentum führt. Jeder Änderungsauftrag sollte neue oder geänderte Liefergegenstände, Abnahmekriterien, Preis, Zeitplan und neue vorbestehende oder fremde Materialien nennen. Eine Genehmigung per E-Mail kann für den Betrieb reichen, wenn der Hauptvertrag sie anerkennt, doch Rechtseinräumungen und örtliche Formvorschriften brauchen rechtliche Prüfung.

Die Abnahme darf versteckte Rechtsmängel, Schadcode, nicht offengelegte Abhängigkeiten, Vertraulichkeitsverstöße oder Betrug nie ausschließen. Technische Abnahme bedeutet, dass die gelieferte Version die genannten Tests bestand. Sie sollte keine Tatsachen bestätigen, die das Testteam des Kunden vernünftigerweise nicht entdecken konnte.

Übergabepflichten müssen vor Vertragsende prüfbar sein

Formulieren Sie die Übergabe als wiederkehrende Lieferpflicht mit einem abschließenden Austrittspaket, nicht als Zusage zur „Zusammenarbeit“ nach Vertragsende. Der Kunde sollte zu festgelegten Meilensteinen aktuellen Code, Dokumentation, Kontenkontrolle, Build- und Bereitstellungsunterlagen, Datenexporte, Abhängigkeitsnachweise und angemessene Übergangshilfe erhalten. Regelmäßige Lieferung verringert, was bei einem schlechten Ende zurückgehalten werden kann.

Listen Sie betriebliche Gegenstände auf, die Quellcodeklauseln oft vergessen: Cloud- und Hosting-Konten, Continuous-Integration-Definitionen, Artefakt- und Paket-Registries, Signaturzertifikate, Domain- und DNS-Kontrolle, App-Vertriebskonten, Überwachungsregeln, Backup-Verfahren, Infrastrukturzustand, Secret-Verzeichnisse, Betriebshandbücher, Architekturentscheidungen, Regeln für Testdaten, Modellkonfiguration und Supportkontakte des Anbieters. Der Kunde besitzt vielleicht nicht jedes Drittkonto, doch der Vertrag sollte bestimmen, welche Konten übertragen, welche ersetzt werden und wer zahlt.

Zugangsdaten brauchen Sorgfalt. Verlangen Sie keine Passwörter in einem Dokument oder Repository. Secrets sollten in einem vom Kunden genehmigten Manager liegen, der Kunde muss administrative Wiederherstellung haben, und die Übergabe sollte eine Rotation vorsehen. Persönliche Konten dürfen keine Produktivressourcen besitzen. Lässt eine Plattform keinen Kontentransfer zu, sollte der Anbieter die Ressource in ein vom Kunden kontrolliertes Konto migrieren helfen und das Ergebnis prüfen.

Bestimmen Sie Zeitpunkt, Format und Unterstützung. Eine brauchbare Klausel regelt, wann der Anbieter nach einer Mitteilung das aktuelle Paket liefern muss, wie viele Stunden Übergangshilfe enthalten sind, welchen Satz weitere Hilfe kostet, wer als Ersatzanbieter infrage kommt und wie lange Unterlagen erhalten bleiben. Sie sollte Löschung oder Zugriffsbehinderung während eines laufenden Streits verbieten und gesetzliche Aussetzungsrechte wahren, die die Rechtsberatung eng formuliert.

Die Beendigungsunterstützung muss bei Ablauf, ordentlicher Kündigung, Vertragsverletzung, Insolvenz und Personalproblemen des Anbieters funktionieren. Quellcode-Escrow kann helfen, wenn der Kunde keine laufende Kopie halten kann, besonders bei Lizenzprodukten, ersetzt aber bei Individualentwicklung den ständigen Repository-Zugriff schlecht. Hinterlegungen veralten, Freigabebedingungen werden streitig, und einem Archiv kann das betriebliche Wissen zur Bereitstellung fehlen.

Testen Sie den Ausstieg, solange die Beziehung normal ist. Lassen Sie einen Kundenentwickler oder ein unabhängiges Ersatzteam ohne privaten Anbieterzugriff bauen, bereitstellen, zurückrollen, ein Backup wiederherstellen, Zugangsdaten rotieren und eine kleine Änderung veröffentlichen. Erfassen Sie Lücken als Liefermängel. Eine Übergabeklausel wird greifbar, wenn der Nachweis zeigt, dass ein anderes fähiges Team das System betreiben kann.

Garantien und Rechtsbehelfe müssen Herkunftsmängel erfassen

Verlangen Sie konkrete Garantien, dass der Anbieter den Vertrag schließen darf, die eingeräumten Rechte besitzt oder kontrolliert, Übertragungen der Mitwirkenden eingeholt, vorbestehende und fremde Materialien offengelegt und nicht wissentlich Code eingefügt hat, der andere Pflichten verletzt. Vermeiden Sie das unmögliche Versprechen, Software könne nirgendwo jemals Rechte verletzen. Präzise Garantien verbessern die Prüfung und geben der Rechtsberatung klarere Tatsachen für die Risikoverteilung.

Eine IP-Freistellung sollte festlegen, welche Ansprüche Dritter sie erfasst, wer die Verteidigung führt, wie die Zustimmung zu Vergleichen funktioniert, welche Mitwirkung nötig ist und welche Ausnahmen gelten. Typische Ausnahmen betreffen Kundenmaterial, nicht genehmigte Kundenänderungen oder Kombinationen, die der Anbieter weder lieferte noch anordnete. Die Rechtsberatung sollte verhindern, dass Ausnahmen den Schutz für vorgesehene Systemintegrationen beseitigen.

Rechtsbehelfe sollten die Position des Kunden wiederherstellen und nicht nur einen Schadensersatzstreit erzeugen. Bei Verletzungsansprüchen oder einer Lücke in der Rechtekette muss der Anbieter möglicherweise fortgesetzte Rechte beschaffen, betroffenes Material ersetzen oder ändern, bei der Migration helfen und Gebühren erstatten, wenn keine vernünftige Abhilfe möglich ist. Fehlt die Übertragung eines Mitwirkenden, kann die Abhilfe in dessen Unterschrift oder in unabhängig erstelltem Ersatzcode mit dokumentierter Herkunft liegen.

Stimmen Sie diese Klauseln mit Haftungsgrenzen ab. Wenn die allgemeine Grenze nur einem kleinen Teil der Projektkosten entspricht und jeden Verstoß bei IP, Vertraulichkeit, Daten und Zugang erfasst, können die ausführlichen Schutzregeln wirtschaftlich wenig bewirken. Nicht jede Pflicht braucht deshalb unbeschränkte Haftung. Die Rechtsberatung sollte Grenzen, höhere Sondergrenzen oder Ausnahmen nach tatsächlichem Risiko und verfügbarer Versicherung aushandeln.

Prüfungsrechte sollten gezielt sein. Der Kunde braucht meist Unterlagen zu Mitwirkendenübertragungen, Abhängigkeitskonformität, Repository-Verwahrung und Löschung oder Rückgabe von Kundenmaterial. Selten braucht er unbeschränkten Zugriff auf sachfremde Systeme des Anbieters oder Informationen anderer Kunden. Regeln Sie Mitteilung, Häufigkeit, Vertraulichkeit, Umfang und Kostentragung, wenn eine Prüfung einen wesentlichen Verstoß findet.

Die Rechtswahl ersetzt keine örtliche Rechtsprüfung

Wählen Sie anwendbares Recht, Gerichtsstand, Streitverfahren und Sprache bewusst, rechnen Sie aber damit, dass zwingende örtliche Regeln diese Wahl überdauern. Eine kalifornische Rechtswahl entscheidet nicht automatisch, ob ein Entwickler in einem anderen Land Arbeitnehmer ist, künftige Rechte übertragen, auf Persönlichkeitsrechte verzichten oder eine bestimmte Vergütung erhalten kann. Rechtsberater in den einschlägigen Staaten sollten das tatsächliche Mitwirkendenmodell und nicht nur den Hauptvertrag zwischen Kunde und Anbieter prüfen.

Erfassen Sie jedes relevante Land: Gründungsorte der Kunden- und Anbietergesellschaften, Arbeitsort jedes Mitwirkenden, Ort des Zugriffs auf regulierte Daten und mögliche Durchsetzungsorte. Stellen Sie örtlichen Beratern dann konkrete Fragen. Können künftige Urheberrechte übertragen werden? Verlangt die Übertragung bestimmte Formulierungen, gesonderte Vergütung, Beglaubigung oder Registrierung? Auf welche persönlichen Rechte kann nicht verzichtet werden? Kann das gewählte Gericht wirksam gegen Anbieter oder Mitwirkende vorgehen? Ändern Arbeitsregeln das Eigentum ungeachtet der Vertragsbezeichnungen?

Verwenden Sie eine maßgebliche Vertragssprache und bestimmen Sie die Rolle von Übersetzungen. Eine Leseübersetzung hilft Mitwirkenden, ihre Pflichten zu verstehen, doch der Vertrag sollte, soweit rechtlich möglich, die vorrangige Fassung nennen. Machen Sie die Vertretungsbefugnis beider Gesellschaften sichtbar. Elektronische Signaturen können genügen, die Rechtsberatung sollte aber Formanforderungen für die betreffende Übertragung und Rechtsordnung bestätigen.

Grenzüberschreitende Entwicklung betrifft auch Vertraulichkeit, Datenschutz, Sicherheit, Exportkontrollen, Sanktionen und Branchenregeln. Diese Themen brauchen eigene Anlagen und Beratung. Packen Sie sie nicht in die IP-Klausel und nehmen dann vollständige Deckung an. Gesundheitssysteme etwa werfen Daten- und Regulierungsfragen auf, die Eigentumsformulierungen nicht beantworten.

SaaS Production koordiniert erfahrene Entwickler in Kalifornien, Kasachstan und Osteuropa. Deshalb behandeln wir das Mitwirkendenverzeichnis, das kundengesteuerte Repository und die geprüfte Übergabe als Entwicklungsarbeit statt als Papierkram für den Abschluss. Diese Arbeitsweise ersetzt keine örtliche Rechtsberatung. Sie gibt Beratern genaue Tatsachen und dem Kunden Nachweise, solange die Menschen, die das System geschaffen haben, noch erreichbar sind.

Vor der Unterschrift sollte die Rechtsberatung eine einfache Kette verfolgen können: Jeder Mitwirkende ist identifiziert, seine Rechte erreichen den Vertragspartner, die schriftliche Übertragung erreicht den Kunden, jede zurückbehaltene Komponente steht mit ausreichenden Lizenzrechten auf einer Liste, und jedes Repository sowie jeder Betriebsgegenstand hat einen Verantwortlichen. Vor der Schlusszahlung sollte der Kunde diese Kette am tatsächlichen Release erneut prüfen. Wenn Dokumente und Build nicht übereinstimmen, korrigieren Sie den Build oder die Dokumente, bevor sich das Team auflöst.

Häufig gestellte Fragen

Reicht „work made for hire“ bei Auslandsentwicklern aus?

Meist nicht. In den USA fällt beauftragte Arbeit selbstständiger Entwickler nur in begrenzten Kategorien darunter und braucht eine ausdrückliche schriftliche Vereinbarung. Nutzen Sie eine unterzeichnete sofortige Übertragung als Hauptmechanismus und lassen Sie sie örtlich anpassen.

Wann sollten die Quellcoderechte auf den Kunden übergehen?

Der Vertrag sollte Entstehung, Zahlung oder Abnahme als Zeitpunkt nennen. Kunden bevorzugen oft die Entstehung, Anbieter knüpfen den Übergang möglicherweise an die Zahlung. Entscheidend sind eine klare Regel und ihre Abstimmung mit Rechnungsstreitigkeiten.

Was ist vorbestehendes geistiges Eigentum im Softwarevertrag?

Das sind Materialien, die Anbieter oder Dritte schon vor dem Projekt besaßen, etwa interne Bibliotheken, Vorlagen und Bereitstellungswerkzeuge. Listen Sie jeden Gegenstand auf und geben Sie dem Kunden ausreichende Rechte für Betrieb, Änderung, Übertragung und Wartung.

Sollte der Kunde das Quellcode-Repository kontrollieren?

Der Kunde sollte das maßgebliche Repository und die administrative Wiederherstellung ab dem ersten Commit kontrollieren. Verwahrung beweist kein Urheberrecht, verhindert aber, dass nur der Anbieter auf das aktuelle System zugreifen oder es rekonstruieren kann.

Kann ein Vertrag Open-Source-Code verbieten?

Ja, doch ein pauschales Verbot verschlechtert meist die Offenlegung. Besser sind ein Verzeichnis, lizenzbezogene Freigaben, erhaltene Hinweise, Konformitätsnachweise und eine Pflicht zum Ersatz oder zur Korrektur unvereinbarer Komponenten.

Wie beeinflussen Subunternehmer die Rechte am Code?

Jeder Subunternehmer fügt der Rechtekette ein Glied hinzu. Verlangen Sie vorherige Genehmigung, ein Mitwirkendenverzeichnis, gleichwertige schriftliche Pflichten und den Nachweis, dass die Rechte jeder Person vor dem Zugriff den Anbieter oder Kunden erreichen.

Beweist die Softwareabnahme das Eigentum des Kunden?

Nein. Die Abnahme zeigt, dass die Lieferung Tests bestand; das Eigentum hängt von anwendbarem Recht und unterzeichneten Dokumenten ab. Trennen Sie Abnahme, Zahlung, Garantien und Rechtsübergang, damit eine verpasste Frist nicht alle Punkte entscheidet.

Was muss eine Software-Übergabeklausel enthalten?

Sie sollte Repositories, Build- und Bereitstellungsanweisungen, Dokumentation, Paket-Registries, Konten, Exporte, Secret-Rotation, Zertifikate, Betriebshandbücher und Übergangshilfe erfassen. Testen Sie vor dem letzten Meilenstein Build und Release ohne exklusiven Anbieterzugriff.

Löst die Wahl von US-Recht ausländische Rechtefragen?

Nicht allein. Zwingende Regeln am Arbeitsort können künftige Übertragungen, Persönlichkeitsrechte, Beschäftigungsstatus, Vergütung, Signaturen und Rechtsbehelfe beeinflussen. Stellen Sie örtlichen Beratern konkrete Fragen zur tatsächlichen Struktur.

Welche Nachweise sollte die Rechtsberatung vor Schlusszahlung prüfen?

Sie sollte unterzeichnete Dokumente und Listen vorbestehender Materialien mit Repository-Verlauf und Release-Verzeichnis vergleichen. Das Technikteam muss zudem zeigen, dass eine kundenkontrollierte Umgebung das abgenommene Release bauen, bereitstellen und betreiben kann.