Einheit
Lizenzierung und Urheberrecht
Was ist Urheberrecht an Quellcode und was sind Open-Source-Lizenzen.
Lernziel
Nach dieser Einheit verstehst du, wie Softwareartefakte wie z.B. Quellcode rechtlich einzuordnen sind, wie sich Lizenzen darauf auswirken, welche unterschiedlichen Open-Source-Lizenzen es gibt und worauf bei der Lizenzierung zu achten ist.
Urheberrecht an Quellcode
Nach seiner Erstellung wird Quellcode als literarisches Werk durch das Urheberrecht geschützt. Im Gegensatz zum Marken- und Patentschutz ist für das Urheberrecht keine Eintragung erforderlich.
Das Recht zur Nutzung des Quellcodes liegt bei den Urhebern oder Rechteinhabern, die das Recht zur Nutzung von den Urhebern erhalten haben. Erst durch eine Lizenz erlaubt der Urheber bzw. Rechteinhaber die Nutzung entsprechend der in der Lizenz formulierten Bedingungen auch weiteren Personen. Die Lizenz gibt also Nutzungsrechte frei und schränkt sie nicht ein, wie oft angenommen wird.
Das Urheberrecht schützt konkrete Ausdrucksformen eines Werks wie z.B. Quellcode, Objektcode, Entwurfsdokumente oder Design der grafischen Oberflächen. Die Funktionalität der Software wird durch das Urheberrecht nicht geschützt. Sofern kein zusätzlicher Schutz durch Marken oder Patente besteht, darf eine Software mit identischer Funktionalität entwickelt werden. Dabei darf jedoch nicht der Quellcode oder das Design der grafischen Oberfläche übernommen werden.
Eine gute Einführung und Übersicht zum rechtlichen Schutz an Software bietet z.B. die Webseite der IHK Stuttgart.
Open-Source-Lizenz
In der Einführungseinheit wurden die leicht unterschiedlichen Sichtweisen der Open Source Initiative (OSI) und der Free Software Foundation (FSF) auf Open-Source-Software erklärt. Entsprechend legen sie auch leicht unterschiedliche Kriterien bei der Bewertung von Lizenzen an. In der Praxis erfüllen jedoch nahezu alle gebräuchlichen Lizenzen die Kriterien beider Organisationen. Im allgemeinen Sprachgebrauch wird mit dem Begriff Open-Source-Lizenz meist eine Lizenz bezeichnet, die den Kriterien der OSI genügt und auf deren Lizenzliste geführt wird.
Unterschiede zwischen Open-Source-Lizenzen
Es gibt eine Vielzahl verschiedener Open-Source-Lizenzen, die OSI hat aktuell mehr als 120 Lizenzen anerkannt. Diese Lizenzen unterscheiden sich teils deutlich voneinander, lassen sich jedoch kategorisieren. Zuerst in permissiven Lizenzen und Lizenzen mit Copyleft.
Permissive Lizenzen, also freizügige Lizenzen, erfordern bei der Weitergabe der Software bzw. eines daraus abgeleiteten Werks lediglich die Nennung der ursprünglichen Autorin bzw. des ursprünglichen Autors und die Weitergabe des ursprünglichen Lizenztextes. Die Lizenz des abgeleiteten Werks kann frei gewählt werden, auch proprietäre Lizenzen sind möglich. Der rechtliche Begriff abgeleitetes Werk kann zum Beispiel eine Anpassung des Quellcodes der Software, das Kompilieren in eine Binärdatei oder das Integrieren in eine andere Software sein. Lizenzen mit Copyleft (ein Wortspiel zur Verdeutlichung, dass das Urheberrecht zur Durchsetzung maximaler Freiheit genutzt wird) erfordern dagegen, dass nicht nur Autorin bzw. Autor und der Text der ursprünglichen Lizenz genannt werden, sondern ein abgeleitetes Werk unter der gleichen Lizenz veröffentlicht wird.
Die Unterschiede zwischen den beiden Kategorien wirken gering, haben in der Praxis jedoch erhebliche Auswirkungen. Hat der Hersteller eines Elektronikgeräts (z.B. Infotainmentsystem im Fahrzeug) in der Steuerungssoftware Komponenten, die einer Open-Source-Lizenz mit Copyleft unterliegen, integriert, so kann die Pflicht entstehen, den korrespondierenden Quellcode der betroffenen Komponente bzw. des abgeleiteten Werks den Kundinnen und Kunden bereitzustellen. Hat der Hersteller stattdessen lediglich Softwarekomponenten verwendet, die permissiven Lizenzen unterliegen, so genügt es die Autorinnen und Autoren zu nennen und den Lizenztext zur Verfügung zu stellen.
Die Auswirkung des Copyleft einer einzelnen Komponente (z.B. Softwarebibliothek) auf die gesamte Software wird oft als viraler Effekt bezeichnet. Um diesem entgegenzuwirken wurden Lizenzen mit sogenanntem schwachen Copyleft entwickelt (im Gegensatz zum ursprünglichen starken Copyleft). Hier muss lediglich die Komponenten selbst wieder unter der gleichen Lizenz veröffentlicht werden, nicht jedoch die gesamte Software.
Eine reine unternehmensinterne Nutzung einer Software mit Copyleft führt in der Regel nicht dazu, dass Quellcode gegenüber Dritten offengelegt werden muss. Schwieriger zu bewerten sind Grenzfälle, z.B. Bereitstellung als Software-as-a-Service (SaaS), bei der Kundinnen und Kunden Zugriff auf eine intern betriebene Software gewährt wird. Deshalb gibt es als Ergänzung zu Lizenzen mit starkem Copyleft sogenannte Netzwerk-protektive Lizenzen, die zusätzlich die Nutzung einer Software über Netzwerkverbindungen als Weitergabe im Sinne der Lizenz definieren, so dass Kundinnen und Kunden eines SaaS-Anbieters das Recht auf Herausgabe des Quellcodes einfordern können.
Die folgende Tabelle fasst die genannten Eigenschaften in Bezug auf Weitergabe der Originalsoftware und Bereitstellung abgeleitete Werke zusammen (nicht explizit erwähnt ist die Nennung der ursprünglichen Autorinnen und Autoren sowie des ursprünglichen Lizenztextes):
| ursprüngliche Lizenz | Weitergabe der Software | Veränderung der Software | unveränderte Integration in andere Software |
|---|---|---|---|
| Permissive | Lizenz frei wählbar | Lizenz frei wählbar | Lizenz frei wählbar |
| schwaches Copyleft | ursprüngliche Lizenz | ursprüngliche Lizenz | Lizenz frei wählbar |
| starkes Copyleft | ursprüngliche Lizenz | ursprüngliche Lizenz | ursprüngliche Lizenz |
Bekannte Open-Source-Lizenzen und deren Kompatibilität
Viele der bekannten und weit verbreitetem Lizenzen gibt es in unterschiedlichen Versionen, wobei neuere Versionen den Kern der Lizenz in der Regel nicht verändern, sondern lediglich Klarstellungen im Hinblick auf neue technische Entwicklungen oder zu Kompatibilitätsfragen mit anderen Lizenzen vornehmen.
Die folgende Tabelle ordnet die bekanntesten Open-Source-Lizenzen ein:
| Permissive | schwaches Copyleft | starkes Copyleft |
|---|---|---|
| MIT, Apache 2.0 | GNU Lesser General Public License (LGPL), Mozilla Public License (MPL), Eclipse Public License (EPL) | GNU General Public License (GPL) |
In der Praxis besteht eine Software oft aus vielen unterschiedlichen Komponenten (z.B. Bibliotheken) die in separaten Projekten entwickelt werden. Häufig haben die einzelnen Komponenten unterschiedliche Lizenzen, weshalb sich die Frage nach Kompatibilität, also Widerspruchsfreiheit, zwischen den Bedingungen der einzelnen Open-Source-Lizenzen ergibt.
Die nachfolgende Übersichtgrafik von David A. Wheeler veranschaulicht die Kompatibilität, also Kombinationsmöglichkeiten, der wichtigsten Open-Source-Lizenzen. Ein Pfeil von Lizenz A zu Lizenz B sagt aus, dass die kombinierte Software unter Lizenz B weiterlizenziert werden kann (eventuell mit Ergänzungen aus Lizenz A). Es ist zu erkennen, dass Komponenten, die unter einer permissiven Lizenz stehen, problemlos in eine Software unter Copyleft integriert werden können. Umgekehrt ist dies nicht möglich. Denn unterliegt eine Komponente einer Lizenz mit Copyleft, so kann diese nicht in eine Software mit permissiver Lizenz integriert werden, da die von permissiven Lizenzen gefordert Erlaubnis, das abgeleitete Werk unter beliebige andere Lizenzen zu stellen, nicht erfüllt werden kann.

Übersicht zur Lizenzkompatibilität von David A. Wheeler (CC BY-SA 3.0)
Eine wesentlich ausführlichere Erklärung der einzelnen Lizenztypen, ihrer Historie und den Kombinationsmöglichkeiten findet sich in den frei verfügbaren Lerninhalten des Linux Professional Institute (CC BY-NC-ND 4.0):
Nutzung von Open-Source-Lizenzen am Beispiel Apache 2.0
Um den Quellcode einer Software unter eine bestimmte Open-Source-Lizenz zu stellen, hat es sich etabliert, im Hauptverzeichnis eine Datei mit dem Namen LICENSE abzulegen, die eine exakte Kopie des Lizenztextes enthält und in einzelnen Quellcodedateien zusätzlich in einem einleitenden Kommentar eine verkürzte Fassung der Lizenz wiederzugeben.
Für die Apache 2.0-Lizenz gibt die Apache Foundation Hinweise, wie die Lizenz in Softwareprojekten wiedergegeben werden soll. Am Beispiel der Middleware für Interprozesskommunikation Eclipse iceoryx, lässt sich dies gut nachvollziehen. Im Projektrepository auf GitHub liegt im Hauptverzeichnis eine LICENSE-Datei und in einzelnen Quellcodedateien gibt es einleitende Kommentare:
// Copyright (c) 2021 by Apex.AI Inc. All rights reserved.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
//
// SPDX-License-Identifier: Apache-2.0
Am Ende des Kommentars findet sich ein maschinenlesbaren Identifikator der verwendeten Lizenz zur Unterstützung der automatischen Erstellung von Softwarestücklisten. Mehr zur sogenannten Software Bill of Material (SBOM) lernst du in der Einheit zur Erstellung von SBOM.