Open-Source-Software bezeichnet Programme, deren Quellcode öffentlich einsehbar ist und die eine Lizenz mitbringen, die Nutzung, Veränderung und Weitergabe ausdrücklich erlaubt. Nach dem Open Source Monitor 2025 des Digitalverbands Bitkom, für den 1.152 deutsche Unternehmen mit mindestens 20 Beschäftigten befragt wurden, setzen inzwischen 73 Prozent der Unternehmen Open-Source-Software ein, zwei Jahre zuvor waren es 69 Prozent. Wie jede Entscheidung für eine Softwaregrundlage bringt auch diese sowohl handfeste Vorteile als auch Risiken mit sich, die sich mit etwas Recherche vermeiden lassen.
Geringere Lizenzkosten und mehr Kontrolle über den Code
Weil der Quellcode öffentlich vorliegt, zahlen Unternehmen für Open-Source-Software in der Regel keine Lizenzgebühren pro Arbeitsplatz. Das Land Schleswig-Holstein hat diesen Kostenvorteil 2021 zum Anlass genommen, rund 30.000 Arbeitsplätze in der Landesverwaltung schrittweise von Microsoft Office auf LibreOffice und von Windows auf Linux umzustellen. Neben den Lizenzkosten spielte dabei auch die Unabhängigkeit von einem einzelnen Hersteller eine Rolle: Wer den Quellcode selbst anpassen darf, ist nicht darauf angewiesen, dass ein Anbieter eine gewünschte Änderung überhaupt umsetzt. Welche Rechte und Pflichten damit verbunden sind, regelt die jeweilige Lizenz. Bei permissiven Lizenzen wie MIT oder Apache 2.0 dürfen Unternehmen den Code frei in eigene, auch proprietäre Produkte einbauen. Die GNU General Public License (GPL) verlangt dagegen, dass wer ein darauf basierendes Programm weitergibt, auch dessen Quellcode unter derselben Lizenz offenlegt, ein Prinzip, das als Copyleft bekannt ist.
Offener Code wird geprüft, aber nicht immer schnell genug
Das Argument, offener Quellcode sei sicherer, weil ihn viele Menschen mitlesen können, stimmt nur, wenn tatsächlich jemand mitliest. Die Sicherheitslücke Heartbleed in der weitverbreiteten Verschlüsselungsbibliothek OpenSSL blieb 2014 zwei Jahre lang unentdeckt, obwohl der Code frei einsehbar war, weil das Projekt nur von wenigen ehrenamtlichen Entwicklern gepflegt wurde. Ähnlich verlief es 2021 mit Log4Shell, einer kritischen Lücke in der Java-Bibliothek Log4j, die in unzähligen Unternehmensanwendungen weltweit steckte und erst durch einen gezielten Fund publik wurde. Beide Fälle zeigen: Offener Code verschafft die Möglichkeit zur Prüfung, ersetzt aber nicht die Frage, ob ein Projekt über genügend zahlende Nutzer oder Sponsoren verfügt, um seine Wartung dauerhaft zu finanzieren.
Höherer Einarbeitungsaufwand und uneinheitliche Standards
Weil an einem Open-Source-Projekt oft viele voneinander unabhängige Entwickler mitarbeiten, unterscheiden sich Dokumentation und Bedienkonzept selbst innerhalb eines Themenfelds spürbar. Wer etwa eine Linux-Distribution einführt, muss sich entscheiden, ob Softwarepakete über apt (Debian, Ubuntu), dnf (Fedora) oder pacman (Arch Linux) verwaltet werden, drei technisch unterschiedliche Systeme, die sich nicht ohne Weiteres austauschen lassen. Für IT-Abteilungen bedeutet das häufig eine steilere Lernkurve als bei einem einzelnen kommerziellen Anbieter mit einheitlicher Produktlinie.
Support kommt aus der Community oder gegen Aufpreis
Anders als bei proprietärer Software gibt es bei den meisten Open-Source-Projekten keine automatische Herstellerhotline. Fragen landen in Community-Foren oder auf Plattformen wie GitHub, wo die Antwortzeit von der Motivation der Mitwirkenden abhängt statt von einem vertraglich vereinbarten Reaktionszeitfenster. Unternehmen, die verbindliche Reaktionszeiten benötigen, kaufen deshalb oft ein kommerzielles Supportpaket dazu. Red Hat etwa verkauft mit Red Hat Enterprise Linux eine kostenpflichtige, vertraglich abgesicherte Version des freien Betriebssystems Linux und finanziert damit einen erheblichen Teil seiner Entwicklungsarbeit.
Lizenzpflichten, die beim Weiterverbreiten leicht übersehen werden
Wer Open-Source-Code in ein eigenes Produkt einbaut und dieses Produkt weitergibt, muss die Lizenzbedingungen des eingebauten Codes einhalten, auch wenn das eigene Produkt selbst nicht quelloffen sein soll. Wie ernst das genommen wird, zeigt ein Rechtsstreit aus dem Jahr 2015: Der Linux-Kernel-Entwickler Christoph Hellwig verklagte zusammen mit der Organisation Software Freedom Conservancy den Virtualisierungsanbieter VMware vor einem Hamburger Gericht, weil dessen Produkt ESXi Code aus dem GPL-lizenzierten Linux-Kernel und der Software BusyBox enthielt, ohne den laut GPL erforderlichen Quellcode offenzulegen. Ein Berufungsgericht wies die Klage 2016 aus verfahrensrechtlichen Gründen ab, ohne die zugrunde liegende Rechtsfrage zu klären, was zeigt, wie unklar die Durchsetzung solcher Pflichten in der Praxis bleiben kann. Für Unternehmen heißt das: Ein Blick in die jeweilige Lizenz lohnt sich vor dem Einsatz von Fremdcode, nicht erst beim Weiterverkauf des fertigen Produkts.
Open-Source-Software ist damit weder grundsätzlich sicherer noch grundsätzlich riskanter als proprietäre Alternativen. Sie verschiebt nur die Fragen, die ein Unternehmen vorher klären sollte: von der Lizenzgebühr hin zur Lizenzpflicht, und vom Herstellersupport hin zu der Frage, wer ein Projekt eigentlich pflegt.
Häufig gestellte Fragen
Wie verbreitet ist Open-Source-Software in deutschen Unternehmen?
Nach dem Open Source Monitor 2025 des Digitalverbands Bitkom, einer Befragung von 1.152 deutschen Unternehmen mit mindestens 20 Beschäftigten, setzen inzwischen 73 Prozent der Unternehmen Open-Source-Software ein. Zwei Jahre zuvor waren es 69 Prozent.
Was unterscheidet permissive Lizenzen wie MIT von der GPL?
Bei permissiven Lizenzen wie MIT oder Apache 2.0 dürfen Unternehmen den Code frei in eigene, auch proprietäre Produkte einbauen. Die GNU General Public License verlangt dagegen, dass wer ein darauf basierendes Programm weitergibt, auch dessen Quellcode unter derselben Lizenz offenlegt, ein Prinzip, das als Copyleft bekannt ist.
Macht offener Quellcode Software automatisch sicherer?
Nicht automatisch, wie die Sicherheitslücken Heartbleed und Log4Shell zeigen. Heartbleed blieb 2014 zwei Jahre lang in der frei einsehbaren Bibliothek OpenSSL unentdeckt, weil das Projekt nur von wenigen ehrenamtlichen Entwicklern gepflegt wurde. Offener Code verschafft nur die Möglichkeit zur Prüfung, ersetzt aber nicht die Frage, ob ein Projekt genügend Ressourcen für seine Wartung hat.
Welche rechtlichen Pflichten entstehen beim Einbau von Open-Source-Code in eigene Produkte?
Wer Open-Source-Code in ein eigenes Produkt einbaut und weitergibt, muss dessen Lizenzbedingungen einhalten, auch wenn das eigene Produkt selbst nicht quelloffen sein soll. Im VMware-Rechtsstreit von 2015 warf der Linux-Kernel-Entwickler Christoph Hellwig dem Unternehmen vor, GPL-lizenzierten Code aus dem Linux-Kernel und BusyBox verwendet zu haben, ohne den dafür laut GPL nötigen Quellcode offenzulegen.