Open Source Lizenzen verstehen: GPL, MIT, Apache im Vergleich

Kreuztabelle: Kompatibilität / Kombinierbarkeit

Übersicht

Hier noch eine zusammenfassende Übersicht über die drei großen Open-Sorce-Lizenzmodelle:

GPL ist nicht GPL

Die GPL Version 2 und die GPL Version 3 verfolgen beide das Ziel, Softwarefreiheit sicherzustellen, unterscheiden sich jedoch in mehreren zentralen Aspekten. Die GPLv3, 2007 veröffentlicht, adressiert technische und rechtliche Entwicklungen, die in der GPLv2 von 1991 noch nicht berücksichtigt waren. Ein wichtiger Unterschied ist der Umgang mit Tivoization: Dabei stellen Hersteller zwar den Quellcode bereit, verhindern aber technisch, dass Nutzer modifizierte Versionen ausführen können. Ein klassisches Beispiel ist ein digitaler Videorekorder (wie der namensgebende TiVo), der zwar GPL‑Software verwendet, aber nur vom Hersteller signierte Firmware akzeptiert. Nutzer können den Code zwar einsehen und ändern, ihre Änderungen jedoch nicht auf dem Gerät installieren – ein klarer Widerspruch zum Geist der GPL. Dies verhindert die GPLv3 ausdrücklich.

Zudem stärkt die GPLv3 den Schutz vor Softwarepatenten, verbessert die Lizenzkompatibilität und berücksichtigt internationale Rechtsräume stärker. Insgesamt erweitert sie die Nutzungsfreiheit, während die GPLv2 als stabiler, aber weniger umfassend gilt.

Spezialfälle

Das AGPL-Dilemma: Schutz vs. Ökosystem

Der Wechsel zur Affero GnNU Public License (AGPL) oder gar zu spezifischen „Source Available“-Lizenzen – wie man es bei prominenten Beispielen wie MongoDB (SSPL) oder Elasticsearch (ELv2) beobachten konnte – erscheint auf den ersten Blick verlockend, um das eigene Geschäftsmodell gegen die kommerzielle Nutzung durch große Cloud-Provider abzusichern. In der Praxis erweist sich dieser Weg jedoch oft als riskant: Solche Lizenzen führen häufig zu rechtlicher Unsicherheit bei Unternehmenskunden, einer Fragmentierung der Entwickler-Community und dem Verlust des offiziellen „Open Source“-Status gemäß der OSI-Definition. Anstatt das Projekt nachhaltig zu schützen, besteht die Gefahr, genau die kollaborative Dynamik und das Vertrauen zu untergraben, die den ursprünglichen Erfolg der Software erst ermöglicht haben. Tatsächlich erleben wir vor allem bei großen Unternehmen immer wieder eine pauschale Ablehnung solcher Lizenzen. Insbesondere die AGPL findet man sehr häufig auf einer Blacklist.

LGPL – Lesser GPL

Die Lesser General Public License (LGPL) wurde ebenfalls von der Free Software Foundation (FSF) entwickelt. Die LGPL erlaubt es Entwicklern oder Firmen, unter LGPL stehende Software in eigene Projekte einzubinden, ohne dass diese durch ein sog. starkes Copyleft gezwungenermaßen ihren Quellcode insgesamt offen legen müssten. Endnutzern muss es aber möglich sein, den LGPL-lizenzierten Code zu ändern, weshalb dieser Code in proprietärer Software dann meist in dynamische Bibliotheken ausgelagert wird, die sich auch noch austauschen lassen, wenn das Program insgesamt nur im Binärcode vorliegt. Die Lizenz stellt einen Kompromiss zwischen den verschiedenen, strengen Copyleft-Lizenzen wie GPLv2 oder v3 auf der einen Seite und freizügigen Lizenzen wie MIT oder auch BSD-Lizenzen dar.

Steht eine Open-Source-Lizenz nicht jedem Geschäftsmodell entgegen?

Die klare Antwort ist „Nein!“ Zum einen ermöglichen Lizenzen wie MIT durchaus auch den Vertrieb von Software ohne den Quellcode offen zu legen, zum anderen zeigen tausende Projekte, dass man auch mit offenem Quelltext ein Geschäftsmodell abbilden kann. Ein typisches Beispiel heute sind SAAS-Angebote, die von einem kommerziellen Arm des Entwicklungsteams betreut werden. Die Entwicklung findet völlig Open-Source statt, aber ein Unternehmen kann die Software trotzdem beispielsweise gehostet als Service anbieten. Ein sehr bekanntes Beispiel wäre die Blogsoftware WordPress, die es kostenlos auf https://wordpress.org/ zum Download gibt – gleichzeitig bietet https://wordpress.com/ Hosting und kostenpflichtige Addons, Clouddienste, Backupspace usw. an. Auch gibt es einige Projekte, die als Dual-License vertrieben werden, wo also die offene Software unter einer echten freien Lizenz verfügbar ist, jedoch es auch eine kommerzielle Lizenz gibt, die Firmen samt Garantiezusagen etc. kaufen können. In den Communities weniger beliebt sind Open-Core-Modelle, wo es eine Community-Edition unter einer Open Source Lizenz gibt und parallel dazu eine „Vollversion“, die dann gekauft werden muss und eben nicht Open-Source ist. Diese Modelle führen aber auch oft dazu, dass es nur eine kleine Community gibt, die freiwillig zur Weiterentwicklung beiträgt. Neben diesen Modellen gibt es aber auch die Möglichkeit, Services rund um Open-Source zu verkaufen, so wie wir es bei credativ beispielsweise machen. Wir beraten Kunden gegen Honorar, wie sie ihre Infrastruktur mit Open Source umsetzen können und unterstützen im Betrieb. Trotzdem setzen wir in dem Kontext praktisch immer auf reine Open-Source-Software.

Aber ist Open Source Software nicht immer kostenlos?

Nein, Open Source Lizenzen verhindern nicht den kommerziellen Vertrieb von Software. Sie erzwingen aber teilweise, dass der Quellcode publiziert wird, was möglicherweise wettbewerbliche Produkte befördert, aber umsonst ist es nicht zwingend. Richard Stallman hat das mal als „Free as in free speech, not free beer.“  formuliert. Dazu kommt, dass in einer TCO-Betrachtung auch immer Kosten für das Konzeptionieren, Ausrollen und Betreiben anfallen. Diese sind bei proprietärerer Software aber genauso vorhanden. Open Source bietet aber den Vorteil, dass man mit dem Quellcode eine hohe Unabhängigkeit erhält, die dazu führt, dass man nicht in einer Vendor-Lock-Falle sitzen bleibt, wenn der Anbieter die Preise massiv anzieht.

Was ist mit einer Software ohne Lizenzangaben?

Software ohne ausdrückliche Lizenzangabe ist in den meisten Rechtsordnungen rechtlich vollständig geschützt („all rights reserved“). Das bedeutet, dass Nutzer*innen den Code weder verwenden, kopieren, verändern noch weitergeben dürfen, selbst wenn er öffentlich zugänglich ist, etwa auf GitHub. Für die erlaubte Nutzung ist daher stets eine explizite Lizenz notwendig.

Wer Software bewusst gemeinfrei stellen möchte, kann dies über CC0 (Creative Commons Zero) tun. CC0 verzichtet – soweit rechtlich möglich – auf urheberrechtliche Ansprüche und ermöglicht eine nahezu uneingeschränkte Nutzung ohne Bedingungen.

Wichtig ist die Unterscheidung zwischen Open Source / FOSS und Public Domain: Open Source bedeutet nicht „rechtsfrei“, sondern beschreibt lizensierte Software, die bestimmte Nutzungsfreiheiten gewährt (z. B. MIT, Apache, GPL). Die Public Domain hingegen ist tatsächlich frei von Urheberrechten, entweder durch Ablauf der Schutzfrist oder durch expliziten Verzicht wie bei CC0.

Was passiert, wenn Sie Open-Source-Lizenzen falsch verwenden?

Lizenzverletzungen können zu kostspieligen Rechtsstreitigkeiten, Schadenersatzforderungen und der Verpflichtung führen, Ihren eigenen Quellcode zu veröffentlichen. Häufige Fehler sind das Ignorieren von Copyleft-Bestimmungen, fehlende Lizenzhinweise und die Verwendung inkompatibler Lizenzen in einem Projekt. Vorbeugende Maßnahmen wie Lizenz-Audits schützen vor rechtlichen Problemen. Hier gibt es beispielsweise auch spezialisierte Dienstleister und Softwareangebote, die die Analyse des verwendeten Codes übernehmen.

Rechtliche Konsequenzen von Lizenzverletzungen sind vielfältig:

• Unterlassungsansprüche, die Ihre Softwareverteilung stoppen können
• Schadenersatzforderungen für entgangene Lizenzgebühren
• Verpflichtung zur nachträglichen Veröffentlichung des Quellcodes
• Anwalts- und Gerichtskosten

Häufige Fehler in der Praxis entstehen durch mangelndes Bewusstsein:

• GPL-Software in proprietären Produkten ohne Quellcodeveröffentlichung
• Entfernung oder Änderung von Copyright-Hinweisen
• Mischung inkompatibler Lizenzen ohne Beachtung der Auswirkungen
• fehlende Dokumentation verwendeter Open-Source-Komponenten

Unternehmen können sich schützen, indem sie regelmäßige Lizenz-Audits durchführen, Entwickler schulen und Tools zur automatischen Lizenzerkennung einsetzen. Eine klare Richtlinie für die Verwendung von Open-Source-Software hilft, Probleme von vornherein zu vermeiden.

Für Lizenz-Audits stehen auch verschiedene Softwaretools zur verfügung, die zum Teil kommerziell oder als SAAS angeboten werden. aber natürlich gibt es auch verschiedene Open-Source-Tools, die Sie beim Lizenz-Audit unterstützen. Beispielhaft möchte ich folgende hier nennen:

• FOSSology – ein Open Source Lizenz-Compliance-System, dass bereits im Entwicklungsstadium mit Codescannern unterstützt, keine unerwünschten Lizenzkombinationen einzuführen.
• AboutCode ScanCode bezeichnet sich selbst als industry-leading SCA code scanner und lässt sich auch in Build-Pipelines zum automatischen Code Scanning einbinden.
• license checker ist vor allem für Web- oder Web-nahe Entwickler spannend, da es sich in das npm / npx Universum nahtlos einfügt.

Die Liste hat natürlich keinen Anspruch auf Vollständigkeit und kann sich wie immer im Open-Source-Umfeld immer wieder ändern.

Wie credativ® bei Open-Source-Lizenzfragen hilft

Wir unterstützen Unternehmen bei der praktischen Verwendung von Open-Source-Software durch umfassende Beratung und praktische Implementierungshilfe. Unser Team aus Linux-Spezialisten und Open-Source-Experten kennt viele Fallstricke und hilft Ihnen, diese zu vermeiden, während Sie die Vorteile freier Software optimal nutzen.

Mit über 20 Jahren Erfahrung im Open-Source-Bereich verstehen wir sowohl die technischen als auch die rechtlichen Herausforderungen. Wir helfen Ihnen dabei, Open-Source-Software sicher und effektiv in Ihrer IT-Infrastruktur einzusetzen, ohne rechtliche Risiken einzugehen. Unsere umfassenden Services decken alle Aspekte der Open-Source-Beratung ab.

Kontaktieren Sie uns für eine unverbindliche Beratung zu Ihrem Open-Source-Einsatz. Gemeinsam entwickeln wir eine Strategie, die die Innovationskraft von Open-Source-Software für Ihr Unternehmen nutzbar macht.