Kitabı oku: «Praxishandbuch Open Source», sayfa 2

Kapitel I Free and Open Source Software (FOSS) – Idee und Risiken

1

Der technische Einsatz von Free and Open Source Software (FOSS) ist weit verbreitet, das gilt jedoch nicht im gleichen Umfang für die rechtliche Einhaltung der Lizenzvorgaben. Hier treffen zwei Welten aufeinander, die allen Beteuerungen zum Trotz lieber nebeneinander koexistieren möchten, als sich allzu weit zu überschneiden. Software-Entwickler möchten die langen Lizenztexte am liebsten auf eine einzeilige If-then-else-Formel reduzieren und Juristen wollen für die Lizenzbedingungen keine Software-Architektur analysieren.

2

Basic: Free and Open Source Software (FOSS) (siehe Rn. 63ff.)

Die wesentlichen Merkmale von FOSS sind, dass die Software von jedermann frei und ohne Zahlung von Lizenzgebühren verwendet werden kann, der Source Code der Software zugänglich ist und der Nutzer die Software selbst verändern und an Dritte weitergeben darf. Freeware, Shareware und auch Public Domain Software sind keine FOSS im klassischen Sinne; letztere kann jedoch nach denselben Maßstäben beurteilt werden.

FOSS Komponenten stehen regelmäßig unter klassischen FOSS Lizenzen, die von der FSF1 oder der OSI2 nach deren Kriterien anerkannt wurden (zu diesen Organisationen siehe Rn. 50ff.). Sie lassen sich meist der bei der Organisation SDPX verfügbaren Lizenzliste entnehmen.3 Wir verwenden in diesem Buch für alle FOSS Lizenzen als Bezeichnungen die in dieser Liste vorgesehenen SPDX Identifier, also die vereinheitlichten Kurzbezeichnungen. SPDX ist ein Projekt, das sich die einheitliche Bezeichnung und Übermittlung von FOSS nach einheitlichen Standards auf die Fahne geschrieben hat.4

3

Man kann sich damit begnügen, alle GPL-artigen Lizenzen auf eine rote Liste zu setzen und schlicht nach passenden Komponenten unter liberalen Lizenzen zu suchen. Dabei werden die Entwickler jedoch schnell feststellen, dass gerade die häufig benötigten, gewollten oder schlicht am besten geeigneten Komponenten unter „gefährlicheren“ Lizenzen stehen. Diese können häufig nur eingesetzt werden, wenn bei der Verwendung genaue technische Vorgaben eingehalten werden. Insofern ist es für eine vertiefte Auseinandersetzung unerlässlich, entsprechendes Technikwissen zu haben. Damit lässt sich ein Einsatz oft lizenzkonform gestalten, auch wenn die erste rechtliche Bewertung zunächst ein höheres Risiko ausgibt. Um solche Fälle zu beurteilen, braucht man technische und rechtliche Grundlagen, die ein wenig über das Allgemeinwissen hinausgehen.

4

Die Schnittstelle zwischen den Juristen und Entwicklern ist dabei oft die Sollbruchstelle. Fähige Entwickler können den Code für Lizenzkonformität anpassen, wenn sie wissen, welche Software-Architektur den Lizenzvorgaben gerecht wird. Gute Juristen können Lösungen für technisch nicht anders umsetzbare Architekturen finden, wenn sie die dahinter liegenden Code Mechanismen, beispielsweise zur Interaktion verschiedener Komponenten miteinander, verstanden haben. In den folgenden Kapiteln dieses Buches finden beide Parteien die entsprechenden Grundlagen aus dem rechtlichen und technischen Bereich praxisnah aufbereitet. Ziel ist, das Zusammenspiel von Technik und Recht zu optimieren und so den lizenzgerechten Einsatz von FOSS zu gestalten.

1 https://www.gnu.org/licenses/license-list.html.en. 2 https://opensource.org/licenses. 3 https://spdx.org/licenses/. 4 https://spdx.dev/.