URHEBERBLOG · PRAXISWISSEN
Auf dieser Seite · Vertiefung · Praxisbeispiele · Häufige Fragen · Beratung
Entwicklungsverträge, Quellcode, Lizenzmodelle und Pflichten beim Einsatz fremder Komponenten prüfen.
Bei Software sind Programme, Dokumentation, Benutzeroberflächen und Datenbestände getrennt zu bewerten. Schutz setzt die gesetzlich erforderliche Individualität voraus; Ideen und Grundsätze hinter einem Programm sind nicht als solche geschützt. Für Beschäftigtenprogramme, Dekompilierung und bestimmte bestimmungsgemäße Nutzungen gelten besondere Regeln.
Technik und Lizenzmodell gemeinsam bewerten
Open Source ist nicht gleichbedeutend mit uneingeschränkter Verwendung. Entscheidend sind Lizenzversion, technische Einbindung und Bereitstellung des konkreten Produkts.
Rechtliche Prüfung und Vertragsgestaltung
Wir gestalten Entwicklungs-, Pflege-, Lizenz- und SaaS-Verträge und prüfen die Rechte an Individualsoftware. Dazu gehören Spezifikation, Abnahme, Quellcodezugang, Nutzungsmetriken, Weiterentwicklung und der Einsatz externer Entwickler. Open Source bedeutet nicht Pflichtenfreiheit: Lizenztexte, Hinweise, Weitergabebedingungen und mögliche Copyleft-Effekte sind anhand der konkreten Komponenten und ihrer technischen Einbindung zu prüfen. Ein einheitliches Open-Source-Recht gibt es nicht.
Diese Unterlagen und Fragen helfen bei der Prüfung
- Komponenten und Lizenzversionen inventarisieren
- Rechte von Beschäftigten und Freelancern dokumentieren
- Bereitstellung, Distribution und Cloudbetrieb unterscheiden
- Quellcode, Dokumentation, Exit und Wartung vereinbaren
Typischer Praxisfall
Ein Unternehmen übernimmt eine Agentursoftware einschließlich Open-Source-Komponenten. Neben dem Entwicklungsvertrag müssen die Komponentenlizenzen und das geplante Vertriebsmodell geprüft werden, bevor das Produkt an Kunden ausgeliefert wird.
Vertiefung: Software & Open Source
Individualsoftware: Nutzung, Weiterentwicklung und Exit
Wer eine Entwicklung bezahlt, sollte nicht nur Funktionen und Abnahme vereinbaren. Wichtig ist, ob das Unternehmen den Code selbst ändern, durch Dritte warten, auf andere Systeme übertragen und an Kunden weitergeben darf. Bei Freelancern ersetzt die Beauftragung keine eindeutige Rechtevereinbarung. Zugang zu Repositories, Build-Anleitungen, Dokumentation und Zugangsdaten sollte organisatorisch abgesichert sein. Quellcodebesitz und rechtliche Befugnis zur Nutzung sind dabei getrennte Fragen.
Open-Source-Prüfung entlang des Auslieferungswegs
Eine Komponentenliste mit Lizenzversionen ist der Ausgangspunkt. Danach werden Verknüpfung, Änderungen und Weitergabe untersucht. Je nach Lizenz können Hinweise, Lizenztexte oder Quellcodebereitstellung erforderlich sein. Bestimmte Lizenzen enthalten auch Vorgaben für Netzwerkbereitstellung; andere knüpfen vor allem an die Weitergabe an. Die Aussage „Wir betreiben nur SaaS“ ersetzt deshalb keine Einzelprüfung. Für Releases empfiehlt sich ein Freigabeprozess, der neue Komponenten und Änderungen erfasst.
Weitere Praxisbeispiele
Die folgenden Beispiele sind fiktive Fallkonstellationen zur Veranschaulichung. Sie beschreiben keine konkreten Mandate und ersetzen keine Einzelfallprüfung.
Praxisbeispiel 1
SaaS wird On-Premises-Produkt
Ein bislang ausschließlich gehostetes Produkt soll beim Kunden installiert werden. Durch die Auslieferung können zusätzliche Lizenzpflichten entstehen. Vor dem Vertriebsstart werden Komponenten, Begleittexte und gegebenenfalls bereitzustellender Quellcode überprüft.
Praxisbeispiel 2
Dienstleister gibt nur fertige Dateien heraus
Nach Ende des Projekts fehlen Repository und Build-Prozess. Zunächst ist zu klären, was vertraglich geschuldet wurde und welche Rechte bestehen. Für die Fortführung werden technische Übergabe, Drittkomponenten und Wartungsbefugnisse zusammen betrachtet.
Praxisbeispiel 3
Lizenzaudit des Herstellers
Ein Anbieter beanstandet zu viele Nutzer oder Installationen. Maßgeblich sind vereinbarte Metriken, tatsächliche Nutzung und Prüfungsrechte. Inventardaten sollten gesichert und Abweichungen nachvollziehbar erklärt werden, bevor eine Nachlizenzierung akzeptiert wird.
Häufige Fragen
Muss bei jeder Open-Source-Nutzung eigener Code veröffentlicht werden?
Nein. Das hängt von Lizenz, Verbindung der Komponenten und Nutzungsszenario ab. Eine pauschale Aussage über sämtliche Open-Source-Lizenzen wäre unzutreffend.
Darf Software zur Fehlerkorrektur verändert werden?
§ 69d UrhG enthält Regeln zur bestimmungsgemäßen Benutzung einschließlich Fehlerberichtigung. Berechtigung, Erforderlichkeit und vertragliche Bestimmungen müssen im konkreten Fall geprüft werden.
So bereiten Sie die Beratung vor
01 · Anliegen
Beschreiben Sie die geplante Nutzung oder den konkreten Streit. Nennen Sie Beteiligte, betroffene Länder und laufende Fristen.
02 · Nachweise
Stellen Sie die oben genannten Unterlagen, Vertragsfassungen und Rechtebelege zusammen. Sichern Sie bei einer Beanstandung die Fundstellen.
03 · Entscheidung
Wir klären Prüfungsumfang und Kosten und besprechen, welche Rechte, Vereinbarungen oder Verfahrensschritte für Ihr Ziel benötigt werden.
Passende Themen zur weiteren Prüfung
Lizenzverträge & Nutzungsrechte · Games & digitale Inhalte · KI, Training & Text und Data Mining
Beratung durch unsere Fachanwälte
Michael Horak und Julia Ziegeler sind Fachanwälte für Urheber- und Medienrecht. Wir prüfen Ihr Anliegen und stimmen Umfang, Vorgehen und Kosten mit Ihnen ab. Hannover ist unser Hauptsitz; die Beratung erfolgt an unseren Standorten und per Videokonferenz. Unser Anwaltsteam · Beratung anfragen.
Rechtliche Anknüpfungspunkte: §§ 69a–69g UrhG. Maßgeblich bleibt die konkrete Fallgestaltung. Urheberrechtsgesetz im amtlichen Portal.
Grundlagen des Urheberrechts · Urheberrechtsverletzungen · Rechtsprechung und Beiträge