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 deutschem Urheberrecht kann Quellcode als Ausdrucksform eines Computerprogramms geschützt sein, wenn das Programm das Ergebnis einer eigenen geistigen Schöpfung ist. Im Gegensatz zum Marken- und Patentschutz ist dafür 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. Durch eine Lizenz räumt der Urheber beziehungsweise Rechteinhaber weiteren Personen Nutzungsrechte ein und legt die Bedingungen fest, unter denen die Software beispielsweise verwendet, verändert oder weitergegeben werden darf. Wer diese Rechte in Anspruch nimmt, muss zugleich die Bedingungen der jeweiligen Lizenz beachten.
Das Urheberrecht schützt konkrete Ausdrucksformen eines Werks wie z. B. Quellcode, Objektcode, Entwurfsdokumente oder das Design grafischer 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.
Kriterien für Open-Source-Lizenzen
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 Open-Source-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 große Zahl verschiedener Open-Source-Lizenzen, die von der OSI anerkannt sind. Diese Lizenzen unterscheiden sich teils deutlich voneinander, lassen sich jedoch grundlegend in permissive Lizenzen und Lizenzen mit Copyleft einteilen.
Permissive Lizenzen, also freizügige Lizenzen, enthalten bei der Weitergabe typischerweise nur wenige Bedingungen. Häufig müssen Copyright- und Lizenzhinweise erhalten und der ursprüngliche Lizenztext mitgegeben werden. Die Lizenz des abgeleiteten Werks kann frei gewählt werden, auch proprietäre Lizenzen sind möglich. Ob eine Veränderung, Übersetzung oder Verbindung mit anderer Software rechtlich als Bearbeitung oder abgeleitetes Werk gilt, hängt vom Einzelfall und vom anwendbaren Recht ab. Lizenzen mit Copyleft (ein Wortspiel zur Verdeutlichung, dass das Urheberrecht zur Sicherung der gewährten Freiheiten genutzt wird) verlangen bei der Weitergabe, dass veränderte Versionen oder von der jeweiligen Lizenz erfasste kombinierte Werke wiederum unter den vorgegebenen freien Lizenzbedingungen bereitgestellt werden.
Die Unterschiede zwischen den beiden Kategorien wirken gering, haben in der Praxis jedoch erhebliche Auswirkungen. Integriert der Hersteller eines Elektronikgeräts, beispielsweise eines Infotainmentsystems im Fahrzeug, Komponenten unter einer Open-Source-Lizenz mit Copyleft in seine Steuerungssoftware, kann bei der Weitergabe die Pflicht entstehen, den korrespondierenden Quellcode der betroffenen Komponente oder eines von der Lizenz erfassten kombinierten Werks bereitzustellen. Verwendet der Hersteller stattdessen ausschließlich Softwarekomponenten unter permissiven Lizenzen, genügt es häufig, die jeweils geforderten Copyright- und Lizenzhinweise sowie den Lizenztext bereitzustellen. Maßgeblich sind stets die Bedingungen der konkreten Lizenz.
Die Auswirkung des Copyleft einer einzelnen Komponente (z.B. Softwarebibliothek) auf die gesamte Software wird oft als viraler Effekt bezeichnet. Um die Wirkung auf klar abgegrenzte Komponenten zu beschränken, wurden Lizenzen mit sogenanntem schwachen Copyleft entwickelt, im Gegensatz zum starken Copyleft. Hier muss typischerweise nur die betroffene Komponente selbst wieder unter den vorgegebenen Lizenzbedingungen bereitgestellt werden, nicht jedoch automatisch 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 sogenannte netzwerkbezogene Copyleft-Lizenzen wie die GNU Affero General Public License (AGPL). Wird ein AGPL-lizenziertes Programm verändert und ermöglicht die veränderte Version eine Interaktion über ein Netzwerk, muss den Nutzenden der Zugriff auf den korrespondierenden Quellcode dieser Version angeboten werden. Die konkrete Pflicht richtet sich auch hier nach dem Wortlaut der verwendeten Lizenz.
Die folgende Tabelle bietet eine vereinfachte Orientierung zur Weitergabe der Originalsoftware und zur Bereitstellung veränderter oder kombinierter Werke. Nicht dargestellt sind einzelne Pflichten wie die Beibehaltung von Copyright-Hinweisen oder die Weitergabe des Lizenztextes.
| ursprüngliche Lizenz | Weitergabe der Software | Veränderung der Software | Integration in andere Software |
|---|---|---|---|
| Permissive | Andere Lizenz möglich; ursprüngliche Hinweise bleiben erhalten | Andere Lizenz möglich; ursprüngliche Hinweise der veränderten Software bleiben erhalten | Andere Lizenz für das Gesamtwerk häufig möglich |
| schwaches Copyleft | Ursprüngliche Lizenz bleibt erhalten | Ursprüngliche Lizenz der veränderten Software bleibt erhalten | Andere Lizenz für das Gesamtwerk kann je nach Abgrenzung möglich sein |
| starkes Copyleft | Ursprüngliche Lizenz bleibt erhalten | Ursprüngliche Lizenz der veränderten Software bleibt erhalten | Ursprüngliche Lizenz bleibt für ein von der Lizenz erfasstes kombiniertes Werk erhalten |
Welche Pflichten im konkreten Fall entstehen, hängt von der jeweiligen Lizenz, der technischen Verbindung der Komponenten, der Art der Bereitstellung und dem anwendbaren Recht ab.
Bekannte Open-Source-Lizenzen und deren Kompatibilität
Viele der bekannten und weit verbreiteten Lizenzen gibt es in unterschiedlichen Versionen. Neuere Versionen greifen häufig technische Entwicklungen auf, präzisieren einzelne Bedingungen oder verbessern die Kompatibilität mit anderen Lizenzen.
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 Übersichtsgrafik 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 kann ein von einer Copyleft-Lizenz erfasstes kombiniertes Werk in der Regel nicht ausschließlich unter einer permissiven Lizenz weitergegeben werden. Die Copyleft-Lizenz verlangt für das erfasste Werk Bedingungen, die eine rein permissive Lizenzierung des Gesamtwerks nicht abbildet.
Ü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 ihrer 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 maschinenlesbarer Identifikator der verwendeten Lizenz zur Unterstützung der automatischen Erstellung von Softwarestücklisten. Mehr zur sogenannten Software Bill of Materials (SBOM) lernst du in der Einheit zur Erstellung von SBOM.