Software mit vollen Rechten beauftragen: Quellcode, Rechteübertragung und Vertraulichkeit

Wenn du deine eigenen Server betreibst, hast du wahrscheinlich mehr Plugins und Apps installiert, als du zählen kannst. Die meisten davon sind lizenziert: Du erhältst das Recht, die Software unter bestimmten Bedingungen zu nutzen, aber der Code bleibt beim Autor. Das ist in Ordnung für ein Media-Server-Plugin, das du einmal installierst und dann vergisst. Zum Problem wird es, wenn ein Stück Software im Zentrum deines Setups steht — ein Jellyfin- oder Emby-Plugin, das zu deiner Bibliotheksstruktur passt, eine Nextcloud-App, die mit deinen internen Tools spricht, oder eine Integration, von der dein Geschäft abhängt.

Dieser Artikel erklärt das Modell hinter der Individuellen Entwicklung mit exklusiven Rechten: was du bekommst, was die Übertragung der Urheberrechte in der Praxis bedeutet, warum es keinen Lizenzschlüssel gibt, wie Vertraulichkeit gehandhabt wird und wann es sich lohnt, für Exklusivität zu zahlen. Er ist aus der Perspektive von jemandem geschrieben, der seit Jahren selbst gehostete Stacks wartet, und er ist allgemeine Information, keine Rechtsberatung.

Lizenziertes Produkt vs. exklusive Entwicklung

Ein lizenziertes Produkt ist etwas, das du nutzen darfst. Der Autor behält das Urheberrecht, darf dasselbe Produkt an andere verkaufen und kann es später ändern oder einstellen. Du bekommst in der Regel Updates, aber du entscheidest nicht, wohin sich das Produkt entwickelt.

Exklusive Entwicklung funktioniert anders. Du beschreibst, was du brauchst, wir bauen es, und nach vollständiger Zahlung gehen die wirtschaftlichen Rechte am Code auf dich über. Das Projekt wird nie weiterverkauft oder für andere wiederverwendet. In der Praxis heißt das: Die Software gehört allein dir — nicht eine Kopie eines Produkts, das auch andere betreiben.

Dieser Unterschied zählt vor allem dann, wenn die Software etwas für dich Spezifisches abbildet: dein Datenmodell, deine Workflows, deine Namenskonventionen. Wird der Code mit anderen Kunden geteilt, werden diese Besonderheiten meist wegverallgemeinert. Gehört er dir, können sie bleiben.

Voraussetzungen

Bevor du bestellst, halte Folgendes bereit:

Eine klare Beschreibung, was die Software tun soll und auf welcher Plattform (Emby, Jellyfin, Nextcloud oder eine Integration zwischen deinen eigenen Systemen).
Zugang zu den Personen, die eine Spezifikation und eine Schätzung freigeben können.
Eine grobe Vorstellung deines Budgets in Stunden, da die Leistung stundenweise mit mindestens 20 Stunden abgerechnet wird.
Falls dir Vertraulichkeit wichtig ist, ein Hinweis, dass du ein NDA möchtest — es wird auf Wunsch unterzeichnet.

Ein technisches Design musst du nicht vorbereiten. Die schriftliche Spezifikation ist Teil des Prozesses.

Schritt 1: Beschreibe, was du brauchst

Starte über das Kontaktformular, ein Ticket oder Telegram. Erkläre das Problem statt der Lösung: Wie sieht dein Server-Setup heute aus, was fehlt, und wie würde ein gutes Ergebnis aussehen? Je konkreter du bei Plattformen und Rahmenbedingungen bist, desto genauer wird die Schätzung.

Schritt 2: Schriftliche Spezifikation und Schätzung erhalten

Du erhältst kostenlos eine schriftliche Spezifikation mit der Stundenzahl. Es wird nichts berechnet, bis du zustimmst. Lies sie sorgfältig — dieses Dokument ist die Grundlage für alles Weitere, einschließlich des Umfangs der Rechteübertragung. Wenn etwas in deinem Setup in der Spezifikation nicht abgebildet ist, sag es jetzt, bevor Stunden gekauft werden.

Schritt 3: Stunden kaufen

Sobald du die Schätzung annimmst, kaufst du die Stunden auf der Produktseite. Das Minimum sind 20 Stunden; größere Projekte fügen Stunden hinzu, wie in der Schätzung vereinbart. Rechnungen werden von Stripe ausgestellt und sind in deinem Konto verfügbar.

Schritt 4: Entwicklung mit Berichten in Etappen

Während der Entwicklung erhältst du Test-Builds und zu jeder Etappe einen kurzen Bericht. Stunden werden in 15-Minuten-Schritten verbraucht, sodass du siehst, wohin die Zeit geht. Das ist der praktische Vorteil eines Stundenmodells bei individueller Arbeit: Du rätselst nicht, was zwischen Kickoff und Lieferung passiert ist.

Schritt 5: Übergabe

Am Ende erhältst du:

Den vollständigen Quellcode — das komplette Projekt mit Build-Anleitung. Du kannst ihn selbst ändern oder an andere Entwickler weitergeben.
Das Dokument zur Rechteübertragung — nach vollständiger Zahlung gehen die wirtschaftlichen Rechte am Code auf dich über.
Keinen Lizenzschlüssel und keine Serverbeschränkung — die App läuft auf so vielen deiner Server, wie du möchtest, ohne einen Lizenzdienst zu kontaktieren.

Der letzte Punkt verdient für Self-Hoster besondere Betonung. Es gibt keinen Aktivierungsserver, den du am Leben halten musst, keinen Schlüssel, den du rotieren musst, wenn du einen Host neu aufsetzt, und keine Phone-Home-Prüfung, die bricht, wenn sich dein Netzwerk ändert. Du stellst sie bereit wie alles andere auf deiner Infrastruktur.

Was die Übertragung der Urheberrechte in der Praxis bedeutet

Das Urheberrecht hat zwei Seiten: Urheberpersönlichkeitsrechte und wirtschaftliche Rechte. Nach EU- und rumänischem Recht bleiben Urheberpersönlichkeitsrechte (zum Beispiel die Namensnennung) grundsätzlich beim Autor und sind nicht übertragbar, während die wirtschaftlichen Rechte — das Recht, das Werk zu nutzen, zu vervielfältigen, zu bearbeiten und zu verbreiten — übertragen werden können. Das Übergabedokument deckt diese wirtschaftliche Seite ab: Nach vollständiger Zahlung gehört der Code dir zum Nutzen und Ändern, und wir verkaufen, veröffentlichen oder verwenden ihn nicht für andere weiter.

Ein paar praktische Konsequenzen:

Du kannst ihn forken. Wenn du später einen anderen Entwickler mit der Erweiterung der App beauftragen willst, kannst du Quellcode und Build-Anleitung weitergeben. Nichts in der Vereinbarung verpflichtet dich, zu uns zurückzukommen.
Du kannst ihn privat halten. Es besteht keine Pflicht, den Code zu veröffentlichen, und es gibt keinen Portfolio-Eintrag, der ihn zeigt.
Open-Source-Komponenten bleiben unter ihren eigenen Lizenzen. Wenn das Projekt Bibliotheken von Drittanbietern verwendet, behalten diese ihre ursprünglichen Bedingungen; die Übertragung gilt für den für dich geschriebenen Code. Frag danach in der Spezifikationsphase, wenn dein Projekt auf bestimmte Bibliotheken setzt.
Die Übertragung erfolgt nach vollständiger Zahlung, deshalb ist der Übergabeschritt daran gekoppelt.

Dies ist eine allgemeine Beschreibung, keine Rechtsberatung. Für deine konkrete Situation, besonders wenn du Rechte an einen Kunden oder Arbeitgeber weiterüberträgst, ziehe einen Anwalt hinzu.

Vertraulichkeit und Nennung

Das Projekt erscheint nicht in unserem Portfolio, und ein NDA wird auf Wunsch unterzeichnet. Wenn die Software Teil eines kommerziellen Angebots ist oder Details enthält, die du lieber nicht öffentlich machen möchtest, sag es am Anfang, damit das NDA steht, bevor die Spezifikation geschrieben wird.

Wann sich Exklusivität lohnt

Exklusivität ist nicht für jedes Plugin die richtige Wahl. Sie ist überlegenswert, wenn:

Die Software Geschäftslogik abbildet, die du nicht mit Wettbewerbern teilen möchtest.
Du erwartest, den Code über Jahre zu pflegen oder zu erweitern, und die Freiheit haben willst, selbst zu wählen, wer das macht.
Du sie auf vielen Servern brauchst, ohne Abhängigkeit von einer Lizenzierung.
Du die Option haben willst, das Projekt vollständig privat zu halten.

Für ein kleines Komfort-Plugin ohne sensible Logik lohnt es sich wahrscheinlich nicht, wo ein lizenziertes Produkt oder eine gewöhnliche individuelle Entwicklung den Job erledigen würde. Das Stundenmodell ist dasselbe; was sich ändert, ist das, was du am Ende bekommst.

Tipps und Fehlerbehebung

Scope Creep ist das Hauptrisiko. Halte dich an die schriftliche Spezifikation. Wenn sich Anforderungen ändern, vereinbare zuerst zusätzliche Stunden — größere Projekte fügen Stunden hinzu, wie in der Schätzung vereinbart.
Nicht verbrauchte Stunden verfallen nicht sofort. Sie bleiben 12 Monate in deinem Konto, was dir Raum für Folgearbeiten nach der Übergabe gibt.
Nach der Übergabe sind Änderungen normale Entwicklungsstunden — entweder bei uns oder bei wem du willst. Das ist der Sinn davon, den Code zu besitzen.
Bewahre die Build-Anleitung zusammen mit dem Quellcode auf. Lege beides gemeinsam in deinem eigenen Repository ab, damit ein künftiger Maintainer nicht raten muss.
Frag früh nach Komponenten von Drittanbietern, wenn deine Compliance-Regeln verlangen, dass du weißt, welche Lizenzen beteiligt sind.
Behandle die Schätzung nicht als Festpreis. Sie ist eine Schätzung in Stunden; die 15-Minuten-Abrechnung gibt es, damit du den Verbrauch verfolgen kannst.

Fazit

Lizenzierte Software gibt dir das Recht, etwas zu nutzen. Exklusive Entwicklung gibt dir die Sache selbst: den vollständigen Quellcode, die wirtschaftlichen Rechte nach vollständiger Zahlung, keinen Lizenzschlüssel und keine Serverbeschränkung sowie Vertraulichkeit, wenn du sie brauchst. Für Self-Hoster zeigt sich der praktische Unterschied erst Jahre später — wenn du ein Verhalten ändern, auf einen neuen Host umziehen oder das Projekt an jemand anderen übergeben willst.

Wenn du ein Projekt hast, das allein dir gehören soll, starte mit einer Beschreibung über die Kontaktseite und frag nach der schriftlichen Spezifikation. Du kannst auch in der Wissensdatenbank nach verwandten Anleitungen stöbern oder in den FAQ häufige Fragen zum Ablauf nachlesen.

Dieser Beitrag wurde mit KI-Unterstützung auf Grundlage unserer Produktdokumentation oder der aufgeführten Quellen verfasst und vor der Veröffentlichung automatisch geprüft.