Urheberrecht in der IT: Was Unternehmen und Freelancer oft falsch machen.
Warum 80 % IT-Freelancer und Unternehmen das Urheberrecht falsch verstehen – und dabei massiv Geld verlieren
Ein fiktiver Fall zeigt, wie schnell es teuer werden kann.
Die meisten IT-Freelancer glauben, dass sie mit der Berechnung ihres Stundensatzes an ein Unternehmen die Rechte an ihrem Code automatisch an den Auftraggeber abtreten.Und die meisten Unternehmen glauben, dass sie nach Bezahlung der Honorarrechnung automatisch Eigentümer des gelieferten Codes sind.
Und zwar nicht ein bisschen, sondern fundamental.
Die rechtliche Realität in Deutschland ist:
Software ist ein urheberrechtlich geschütztes Werk.
Und der Urheber bleibt immer der Urheber (§§ 69a ff. UrhG).
Das gilt unabhängig davon, ob ein Vertrag existiert oder nicht.
Trotzdem kennen 80 % der Freelancer dieses Gesetz nicht – und 80 % der Unternehmen setzen sich täglich über diese Regeln hinweg, ohne es zu merken.
Warum ist das so?
Weil das Thema in der Branche kaum diskutiert wird und die meisten Dokumentationen juristisch, trocken und abstrakt sind.
Heute ändern wir das.
Dieser Artikel erklärt die Gesetzeslage verständlich – und zeigt anhand eines fiktiven, aber absolut realistischen Praxisfalls, wie schnell Unternehmen wie Freelancer in eine gefährliche Situation geraten.
1. Angestellte Entwickler vs. Freelancer
Angestellte Entwickler: Warum hier alle Rechte automatisch an den Arbeitgeber übergehen
Das deutsche Urheberrecht unterscheidet klar zwischen angestellten Entwicklern und externen Entwicklern.Viele Menschen glauben: „Ein Entwickler ist ein Entwickler, egal ob angestellt oder extern.“
Falsch.
Juristisch besteht ein gigantischer Unterschied.
Angestellte Entwickler
Wenn ein Mitarbeiter im Rahmen seines Arbeitsvertrags Software schreibt, gilt grundsätzlich:Alle Nutzungsrechte an dieser Software gehen automatisch auf den Arbeitgeber über.
Das ist üblich und notwendig, denn:
- die Firma trägt das wirtschaftliche Risiko,
- sie bezahlt Lohn & Arbeitsmittel,
- sie ist für Produkt, Haftung und Vermarktung zuständig.
aber das Unternehmen erhält die umfassenden Nutzungsrechte, die es benötigt.
Freelancer und externe Entwickler
Bei Freelancern passiert dies NICHT automatisch.Der Unterschied:
- Mitarbeiter: Rechteübertragung kraft Gesetz + Arbeitsvertrag
- Freelancer: Rechteübertragung nur durch ausdrückliche Vereinbarung
Ein Unternehmen kann den Code eines Mitarbeiters verändern.
Den Code eines Freelancers aber nicht.
Und das ist der Punkt, an dem 80 % der Firmen unbewusst in die Falle laufen.
2. Das große Missverständnis: „Wir haben doch bezahlt – also gehört es uns.“
Dieser Satz ist in der IT so verbreitet wie falsch.Bezahlung bedeutet Nutzungsrecht, nicht Eigentum.
Bezahlung bedeutet interne Verwendung, nicht Weiterentwicklung.
Bezahlung bedeutet Zugriff, aber niemals Übernahme des Urheberrechts.
Für Unternehmen hat das eine dramatische Konsequenz:
Wenn sie extern erstellten Code intern weiterbearbeiten, begehen sie juristisch eine Bearbeitung ohne Lizenz.
Das ist kein Kavaliersdelikt, sondern ein Verstoß gegen das Urheberrecht.
3. Das sagt das Gesetz – in einfachem Deutsch
Das deutsche Urheberrechtsgesetz ist überraschend klar:- Der Autor bleibt immer der Urheber
Er kann seine Urheberschaft nicht verlieren.
Auch nicht durch Bezahlung. - Der Kunde erhält nur die Rechte, die ausdrücklich eingeräumt wurden
Ohne Vertrag = nur einfaches Nutzungsrecht. - Der Kunde darf den Code nutzen – aber nicht verändern
Modifikation ist nur durch den Urheber oder durch diesen beauftragte Personen erlaubt. - Der Kunde darf den Code nicht weitergeben
Auch nicht intern an Tochterfirmen oder Partner. - Ohne Einräumung von Bearbeitungsrechten bleibt jede Änderung rechtswidrig.
4. Ein fiktiver Praxisfall (den fast jeder in der Branche kennt)
Ein externes Ingenieurbüro entwickelt für ein Unternehmen einen komplexen Java-Client zur Systemintegration.Die Arbeit zieht sich über Monate – der Code ist sauber, dokumentiert und technisch anspruchsvoll.
Die Geschäftsführung weiß wenig darüber.
Das mittlere Management glaubt:
„Maier? Ach, das ist der externe Coder im Entwicklerteam. Kurz vor der Rente.“
Eines Tages verkündet der Manager der Abteilung:
„Wir haben ab nächstem Jahr weniger Budget.
Wir setzen einen Junior auf den Code, der arbeitet das weiter.“
Was das Unternehmen nicht weiß:
- Der Code ist urheberrechtlich geschützt.
- Die Modifikation durch den Junior ist rechtswidrig.
- Jede Weiterentwicklung ohne Zustimmung verletzt die Lizenz.
- Der Hersteller haftet nicht für Schäden durch Fremdanpassungen.
- Das Unternehmen verliert im Zweifel sogar Supportansprüche.
Noch dramatischer:
Wäre der Junior im guten Glauben tätig, handelt trotzdem das Unternehmen fahrlässig.
Ein einziges professionelles Beratungsgespräch hätte dieses Risiko verhindert.
5. Die fünf größten Irrtümer in deutschen IT-Unternehmen
Irrtum 1: „Wir haben die Entwicklung bezahlt – also gehört uns der Quellcode.“Falsch.
Sie haben ein Nutzungsrecht erworben, kein Eigentum.
Irrtum 2: „Unsere internen Entwickler dürfen den externen Code natürlich weiterbearbeiten.“
Falsch.
Das ist eine urheberrechtlich relevante Bearbeitung.
Irrtum 3: „Wir speichern die Tools einfach im GitHub-Repo, dann können alle weiterarbeiten.“
Das ist eine unzulässige Vervielfältigung und Weitergabe an Dritte.
Irrtum 4: „Der externe Entwickler hat nie etwas gesagt, also dürfen wir es.“
Nein.
Rechte entstehen automatisch durch das Gesetz.
Irrtum 5: „Das betrifft nur komplexe Software.“
Falsch.
Jede Klasse, jedes Script, jedes Bash-Tool ist urheberrechtlich geschützt.
6. Wie Freelancer jedes Jahr Tausende Euro verschenken
Viele Freelancer schreiben:- keinen Lizenzheader
- keine Nutzungsrechte
- keine Regeln für Weiterentwicklungen
- keine AGB
- keine Einschränkung der Bearbeitung
- keine Hinweise auf Urheberrecht
Damit verschenken sie:
- Geld
- Einfluss
- zukünftige Beauftragungen
- Supportansprüche
- Wartungsverträge
- Eigentumsrechte
- Freelancer, die sauber mit Urheberrecht arbeiten, verdienen im Schnitt 20–40 % mehr – weil Unternehmen für Weiterentwicklungen zahlen müssen.
7. Was Unternehmen wissen müssen
Unternehmen handeln nicht böswillig.In den meisten Fällen ist es Unkenntnis – oft sogar komplette Blindheit für das Thema.
ABER:
Unternehmen tragen das Haftungsrisiko.
Deshalb müssen sie:
- verstehen, was ihnen gehört
- verstehen, was sie dürfen
- wissen, wo die Grenze liegt
- wissen, wann der Urheber eingebunden werden muss
- vertraglich klar regeln, welche Rechte sie benötigen
- Gutes Engineering braucht gute Governance.
8. Fazit: Urheberrecht ist kein Streitpunkt – sondern der Schutzschirm der IT-Qualität
Das Urheberrecht ist nicht gegen Unternehmen gerichtet.Es schützt die Integrität eines Systems.
Es sorgt dafür:
- dass Software konsistent bleibt
- dass Architektur nicht beschädigt wird
- dass Unternehmen planbar support erhalten
- dass kein Wildwuchs entsteht
- dass Qualität langfristig gesichert ist
Es ist das Sicherheitsnetz gegen Chaos.
Und genau deshalb sollten Freelancer, Ingenieure, Unternehmer und Manager dieses Thema unbedingt kennen.
9. Der Ausweg: Ein sauberer Lizenzvertrag schafft Klarheit für beide Seiten
Die gute Nachricht:Alle beschriebenen Probleme verschwinden sofort,
wenn ein sauberer Lizenz- und Nutzungsvertrag existiert.
Ein Lizenzvertrag ist kein bürokratischer Aufwand,
sondern eine technische Absicherung,
die Missverständnisse vermeidet und Kosten spart.
Was gehört in einen guten Lizenzvertrag zwischen Freelancer und Unternehmen?
Ein professioneller Lizenzvertrag sollte mindestens folgende Punkte enthalten:
1. Urheberbenennung und Urheberrechte
„Der Entwickler bleibt gemäß §§ 69a ff. UrhG der Urheber des Werks.“2. Art des Nutzungsrechts
- einfach oder ausschließlich
- zeitlich begrenzt oder unbegrenzt
- räumlich begrenzt (z. B. weltweit)
- inhaltlich begrenzt (z. B. interne Nutzung)
3. Regelung zur Weiterentwicklung (Kernpunkt!)
„Eine Bearbeitung oder Weiterentwicklung des Quellcodes ist nur mit Zustimmung des Urhebers zulässig.“
Oder in der erweiterten Variante:
„Das Unternehmen erhält ein einfaches Bearbeitungsrecht unter der Voraussetzung, dass Änderungen dokumentiert und dem Urheber zur Kenntnis gebracht werden.“
4. Regelung zur Weitergabe an Dritte
- Tochterfirmen
- Partnerunternehmen
- externe Dienstleister
- Nearshore-Teams
- Cloud-Integratoren
Ohne ausdrückliche Erlaubnis verboten!
5. Support- und Wartungsregelung
Optional:
- Beauftragung des Urhebers für Weiterentwicklung
- Reaktionszeiten
- Stundensätze
- Übergabeprozesse
6. Updates und zukünftige Versionen
„Änderungen in Abhängigkeiten, Frameworks oder Security-Standards erfordern erneute Beauftragung des Urhebers.“
7. Haftungsklarheit
Der Urheber haftet nur für seine originäre Arbeit – nicht für spätere Fremdänderungen.
8. Dokumentation und Zugang zu Repositories
„Repos sind nur zur Nutzung bestimmt, nicht zur Weiterentwicklung ohne Lizenz.“
10. Sonderfall: Gemischte Teams – der Standardfall in modernen IT-Projekten
Das ist der schwierigste und wichtigste Teil.Und fast niemand in der Branche weiß, wie man ihn rechtssicher löst.
Gemischte Teams bestehen aus:
- externen Freelancern
- internen Mitarbeitern
- externen Dienstleistern
- Nearshore-/Offshore-Teams
- Werkstudenten
- Praktikanten
- Subunternehmen
Das bedeutet:
1. Jedes Teammitglied ist Urheber seines Beitrags
Auch wenn es nur eine Klasse, ein Modul oder ein Script ist.2. Der Auftraggeber benötigt daher Rechte von allen Urhebern
Wenn auch nur ein Urheber seine Rechte nicht ordnungsgemäß einräumt,kann der gesamte Code lizenzrechtlich „kontaminiert“ sein.
3. Der Auftraggeber darf nur anpassen, was er selbst hergestellt hat
Die externen Teile dürfen nur bearbeitet werden, wenn ein Bearbeitungsrecht vorliegt.
4. Unternehmen verlieren oft den Überblick
Viele Firmen haben keine Ahnung, wer welche Zeile Code geschrieben hat.
Das ist ein massives Compliance-Risiko.
4. Unternehmen verlieren oft den Überblick
Viele Firmen haben keine Ahnung, wer welche Zeile Code geschrieben hat.Das ist ein massives Compliance-Risiko.
11. Lösung: So regelt man gemischte Teams rechtssicher
Unternehmen benötigen drei Dinge:A. Eine IP- und Lizenzrichtlinie für alle Teammitglieder
Ein Dokument, das festlegt:- Wer Urheber ist
- Welche Rechte eingeräumt werden
- Was modifiziert werden darf
- Was nicht verändert werden darf
- Wer Reviews durchführen darf
- Wie Übergaben erfolgen
B. Einen Rahmenlizenzvertrag für externe Entwickler
Ein Vertrag, der:- Nutzungsrechte klärt
- Bearbeitungsrechte klärt
- Weitergabe verbietet oder erlaubt
- Haftung und Support definiert
- IP-Konflikte verhindert
C. Eine Repository-Governance
Hier werden festgelegt:- Wer Commit-Rechte hat
- Wer Merge-Rechte hat
- Wer für fremden Code verantwortlich ist
- Wer nicht auf fremde Module zugreifen darf
- Wie Third-Party-Code gekennzeichnet wird
Beispiel für einen einfachen Governance-Satz:
„Interne Entwickler dürfen externe Module nicht bearbeiten. Änderungen erfolgen ausschließlich durch den Hersteller oder autorisierte Partner.“
12. Lösung für Freelancer: So schaffst du dir eine sichere Basis
Freelancer sollten IMMER folgendes tun:- Lizenzheader in jede Datei setzen
- Nutzungsrechte explizit formulieren
- Bearbeitungsrecht explizit ausschließen oder lizenzieren
- AGB oder individuellen Lizenzvertrag verwenden
- Dokumentieren, welche Teile von ihnen stammen
- Sich im Projekt als technischer Verantwortlicher positionieren
- Sicherstellen, dass Kunden bei gemischten Teams die Risiken verstehen
- Für Weiterentwicklung separate Verträge anbieten
13. Lizenzmodelle – Die wirtschaftliche Grundlage jeder Software
Nicht jeder Code ist gleich wertvoll.Nicht jede Anwendung dient dem gleichen Zweck.
Deshalb benötigen Softwarelizenzen immer ein zur Anwendung passendes Modell.
Hier sind die vier grundsätzlichen Anwendungsarten – und die dazu passenden Lizenzmodelle.
1. Anwendung nur für den Auftraggeber selbst (interne Nutzung)
Typisch für:- interne Tools
- Test-Clients
- Validierungssoftware
- Automatisierungsskripte
- Monitoring
- interne Schnittstellen
A) Einmalzahlung + eingeschränktes Nutzungsrecht
Beispiel:Der Kunde zahlt 10.000 Euro und nutzt die Software intern, aber darf sie nicht verändern.
B) Einmalzahlung + jährliche Wartungsgebühr
Für Updates, Framework-Anpassungen und Sicherheitskorrekturen.C) Nutzungsrecht zeitlich begrenzt
1 Jahr, 3 Jahre, 5 JahreIndustrie-Standard bei technischen Tools.
2. Anwendung wird Teil eines Produkts, das der Auftraggeber verkauft
Das ist wirtschaftlich eine völlig andere Liga.Beispiel:
Ein Kunde lässt einen Algorithmus entwickeln, den er anschließend in seiner SaaS-Lösung einsetzt.
Hier muss der Urheber eine Lizenz einräumen, die dem Kunden erlaubt:
- die Software in ein Produkt einzubauen
- Geld damit zu verdienen
A) Hohe Einmalzahlung (Buy-out)
Teuer, weil der Urheber damit alle wirtschaftlichen Chancen abtritt.B) Jährliche Vertriebs-/Produktionslizenz
Weit verbreitet in der Industrie.C) Umsatzbeteiligung / Royalty
Der eleganteste und fairste Weg bei Produkten.Beispiel:
5 % vom Umsatzanteil des funktionalen Moduls.
3. Kleine Tools, Hilfswerkzeuge, Nebenmodule
Diese Tools haben meist:- geringen Funktionsumfang
- aber hohe technische Bedeutung
- Validierungstools
- Deployment-Skripte
- Data-Converter
- Konfigurationsgeneratoren
A) Kleine Einmalzahlung
B) Update-Vergütung nach Aufwand
C) Lizenz pro Projekt oder Team
3. Anwendung, die direkt Geld für den Auftraggeber erzeugt
Das ist der wichtigste und sensibelste Fall.Beispiele:
- Matching-Algorithmus für Versicherung
- Pricing-Engine
- Fahrzeugbewertungen (wie manche DAT-Komponenten)
- Risk Engines
- Empfehlungslogiken
Wenn externe Software Teil des Geschäftsmodells wird,
dann kann der Urheber völlig andere Lizenzmodelle verlangen.
Passende Lizenzmodelle:
A) Umsatzbeteiligung
Standard in der Softwareindustrie.Beispiel: 2 % der Erlöse, die durch das Modul entstehen.
B) Lizenz pro Nutzung / API-Call / Vorgang
Beispiel:0,05 € pro Anfrage.
C) Lizenz pro Mandant
Typisch im B2B-Umfeld.D) Lizenz pro Fahrzeug / Vorgang / Datensatz
Sehr verbreitet in Automotive-, Versicherungs- und Bewertungsportalen.E) Mindestlizenz + variable Komponente
Beispiel:20.000 € jährlich + 3 % vom Umsatzanteil.
Für viele Freelancer wäre das ein Vermögen –
sie wissen nur nicht, dass sie diesen Anspruch haben.
14. Erweiterter Schluss: Der Weg nach vorn
Urheberrecht ist kein Hindernis.Es ist die Grundlage für:
- saubere Software
- klare Verantwortlichkeiten
- weniger Projektrisiken
- bessere Qualität
- weniger Konflikte
- sichere Budgets
wo auch die rechtlichen Fundamentsteine sauber gesetzt sind.
Lassen Sie uns kurz sprechen.
Kein Pitch.
Keine Verpflichtung.
Keine Vertriebsrhetorik
Nur 15 Minuten zur Einordnung Ihres Themas.
📞 +49 30 8687094010
✉️ uwe.richter@it-e-com.de
Manchmal reicht ein einziges Gespräch, um teure Fehler zu vermeiden.
Kein Pitch.
Keine Verpflichtung.
Keine Vertriebsrhetorik
Nur 15 Minuten zur Einordnung Ihres Themas.
📞 +49 30 8687094010
✉️ uwe.richter@it-e-com.de
Manchmal reicht ein einziges Gespräch, um teure Fehler zu vermeiden.
Copyright Ingenieurbüro 4WT, 4wt-it.com
Alle Artikel zum Thema: Deutsches Recht in der IT
- Warum Ingenieure oft die besseren Unternehmensberater für Geschäftsführer sind.
- Urheberrecht in der IT: Was Unternehmen und Freelancer oft falsch machen.
In welchem Blogartikel kommt folgendes Suchwort vor?
Video-Zusammenfassung dieser Seite:
Copyright Ingenieurbüro 4WT, 4wt-it.com
Weiterführende Links
Dieser Beitrag spiegelt die Perspektive von 4WT wider – einem Ingenieurbüro, das Unternehmen dabei unterstützt, komplexe IT-Landschaften wieder beherrschbar zu machen.
Unser Fokus liegt nicht auf schnellen Lösungen oder Methodentrends, sondern auf Klarheit, Entscheidungsfähigkeit und verantwortungsvoller Automatisierung an der Schnittstelle zwischen Unternehmertum und IT.
Wir verstehen IT nicht als Selbstzweck, sondern als Nervensystem des Unternehmens.
