Die Frage nach Code-Eigentum lässt sich nicht allein durch den Speicherort beantworten. Relevant sind vertragliche Nutzungs- und Übertragungsrechte, Rechte an vorbestehenden Bestandteilen, Open-Source-Lizenzen und der tatsächliche Zugriff auf Repositories und Infrastruktur.
Dieser Beitrag ist keine Rechtsberatung. Konkrete Vertragsklauseln sollten fachkundig geprüft werden.
Rechte schriftlich festhalten
Der Vertrag sollte eindeutig regeln, welche Rechte an individuell erstelltem Code und weiteren Arbeitsergebnissen übertragen werden, zu welchem Zeitpunkt dies geschieht und ob die Nutzung zeitlich, räumlich oder inhaltlich beschränkt ist. Designs, Dokumentation, Tests und Infrastrukturcode sollten mitgedacht werden.
Vorbestehende Bibliotheken oder wiederverwendbare Bausteine benötigen eine gesonderte Regel. Sie können nicht stillschweigend wie individuell geschaffener Projektcode behandelt werden.
Repository unter Kontrolle
Ein Repository in der Kundenorganisation reduziert operatives Risiko. Persönliche Accounts, geschützte Hauptbranches, nachvollziehbare Reviews und klar geregelte Administratorrechte schaffen Transparenz. Liegt das Repository beim Anbieter, braucht es mindestens verlässlichen Zugriff und eine Exportregel.
Code allein reicht für Übernahme nicht. Build-Anweisungen, Abhängigkeiten, Deployments, Secrets und relevante Architekturentscheidungen gehören zum übergabefähigen Zustand.
Open Source dokumentieren
Abhängigkeiten bringen eigene Lizenzbedingungen mit. Ein gepflegtes Inventar und automatisierte Prüfungen helfen, unerwartete Einschränkungen zu vermeiden. Die bloße Verfügbarkeit eines Pakets bedeutet nicht, dass jede Verwendung ohne Prüfung passt.
Übergabe nicht auf das Ende verschieben
Regelmäßige Commits, laufende Dokumentation und gemeinsame Reviews machen Eigentum praktisch nutzbar. Ein großer Export am letzten Projekttag ist kein belastbarer Handover.