Bei Open-Source-Software ist der Quellcode zugänglich, doch die Lizenz legt fest, was Sie damit tun dürfen und welche Bedingungen gelten. GPL, MIT und Apache gehören zu den verbreiteten Lizenzfamilien. Sie unterscheiden sich vor allem darin, wie stark sie Weitergabe und Änderungen regeln und welche Hinweise erhalten bleiben müssen.
Dieser Überblick hilft Ihnen, die Unterschiede einzuordnen. Er ersetzt keine Prüfung des konkreten Lizenztexts: Entscheidend sind die genaue Lizenzversion, die Art der Nutzung und die übrigen Bestandteile eines Softwareprojekts.
Open-Source-Lizenzen im Vergleich: die wichtigsten Unterschiede
Die drei Lizenzen erlauben grundsätzlich, Software zu verwenden, zu verändern und weiterzugeben. Der wesentliche Unterschied liegt darin, welche Pflichten bei der Weitergabe entstehen.
- MIT ist eine permissive Lizenz mit wenigen Bedingungen. Bei Weitergabe müssen der Copyright-Hinweis und der Lizenztext erhalten bleiben.
- Apache License 2.0 ist ebenfalls permissiv. Sie enthält unter anderem eine ausdrückliche Patentlizenz und zusätzliche Vorgaben für Hinweise und Änderungen.
- GPL ist eine Copyleft-Lizenz. Bei bestimmten Formen der Weitergabe abgeleiteter Software müssen Empfängerinnen und Empfänger die entsprechenden Rechte erhalten, einschließlich Zugang zum Quellcode unter den Lizenzbedingungen.
„Permissiv“ bedeutet nicht, dass keinerlei Pflichten gelten. Auch bei MIT und Apache müssen Lizenzbedingungen eingehalten werden. „Copyleft“ bedeutet ebenfalls nicht, dass jede interne Nutzung automatisch eine Veröffentlichungspflicht auslöst. Maßgeblich ist, ob und wie die Software weitergegeben wird. Wie sich freizügige und Copyleft-Lizenzen grundsätzlich unterscheiden, ordnet die Themenseite Open Source verstehen ein.
MIT: wenige Bedingungen, klare Hinweise
Die MIT-Lizenz räumt weitreichende Nutzungsrechte ein. Sie gestattet unter anderem, Software zu verwenden, zu kopieren, zu verändern, zusammenzuführen, zu veröffentlichen und weiterzugeben. Auch eine Einbindung in proprietäre Software ist grundsätzlich möglich.
Die zentrale Bedingung betrifft die Weitergabe. Der Copyright-Vermerk und der Lizenztext müssen in Kopien oder wesentlichen Teilen der Software enthalten bleiben. Dadurch erfahren nachfolgende Nutzerinnen und Nutzer, unter welchen Bedingungen der lizenzierte Code bereitgestellt wurde.
Was MIT für Unternehmen bedeutet
Für Unternehmen ist die MIT-Lizenz oft vergleichsweise einfach in bestehende Entwicklungsabläufe einzuordnen. Änderungen am Code müssen nicht allein wegen dieser Lizenz unter MIT veröffentlicht werden. Auch die Veröffentlichung des eigenen Quellcodes wird durch MIT nicht verlangt.
Das bedeutet jedoch nicht, dass ein Unternehmen den übernommenen Code ohne Hinweise weitergeben darf. Lizenz- und Copyright-Angaben müssen erhalten bleiben. Werden Komponenten gebündelt oder in ein größeres Softwareprodukt integriert, sollte die Dokumentation so organisiert sein, dass diese Hinweise nicht verloren gehen.
MIT enthält keine ausführliche, ausdrückliche Patentlizenz wie Apache 2.0. Daraus folgt nicht automatisch, dass jede Nutzung patentgeschützter Verfahren unzulässig wäre. Es bedeutet vielmehr, dass sich die Lizenz in diesem Punkt anders ausdrückt und eine gesonderte Prüfung sinnvoll sein kann, wenn Patentrechte für das Vorhaben relevant sind.
Apache License 2.0: permissiv mit Patentregelungen
Die Apache License 2.0 erlaubt, Software zu nutzen, zu verändern und weiterzugeben. Wie bei MIT kann der Code grundsätzlich auch in proprietären Produkten verwendet werden, ohne dass allein dadurch der eigene Quellcode unter Apache veröffentlicht werden muss.
Bei einer Weitergabe gelten jedoch Bedingungen für Lizenztexte, Copyright-Vermerke und Hinweise. Wenn das ursprüngliche Projekt eine NOTICE-Datei mitliefert, müssen deren einschlägige Hinweise in der vorgesehenen Form erhalten bleiben. Änderungen an Dateien sind kenntlich zu machen, sofern die Lizenz dies für die betroffenen Dateien verlangt.
Die Patentlizenz im Überblick
Ein markanter Unterschied zu MIT ist die ausdrückliche Patentlizenz. Sie räumt unter bestimmten Voraussetzungen Rechte an Patenten ein, die für Beiträge der jeweiligen Beitragenden relevant sind. Die Lizenz enthält außerdem eine Regelung, nach der bestimmte Patentklagen Auswirkungen auf die gewährte Patentlizenz haben können.
Diese Bestimmungen können für Organisationen wichtig sein, die Software in geschäftskritischen Produkten einsetzen oder eigene Entwicklungen weitergeben. Die Patentregelung ist kein allgemeines Versprechen, dass jede denkbare Patentfrage erledigt ist. Umfang und Anwendbarkeit hängen vom konkreten Sachverhalt und der Lizenzfassung ab.
Wie bei MIT bleiben die Bedingungen auch bei Apache verbindlich. Eine permissive Lizenz ist also keine lizenzfreie Software: Sie gewährt Rechte, knüpft diese aber an festgelegte Pflichten.
GPL: Weitergabe unter Copyleft-Bedingungen
Die GNU General Public License, kurz GPL, verfolgt einen anderen Ansatz. Sie erlaubt Nutzung, Veränderung und Weitergabe, verbindet die Weitergabe bestimmter abgeleiteter Werke jedoch mit Bedingungen, die die Freiheiten der Empfänger sichern sollen. Dazu gehört je nach Situation auch, den passenden Quellcode zugänglich zu machen und das Werk unter den geltenden GPL-Bedingungen weiterzugeben.
Die GPL verlangt nicht pauschal, dass jede Änderung öffentlich ins Internet gestellt wird. Wird Software ausschließlich intern verwendet und nicht an andere weitergegeben, greifen die Weitergabebedingungen im Allgemeinen nicht auf dieselbe Weise. Bei Verteilung an Dritte können hingegen Pflichten entstehen, die sorgfältig geprüft werden müssen.
GPL-Versionen nicht gleichsetzen
„GPL“ bezeichnet keine einzelne, unveränderliche Regelung. Zu den verbreiteten Fassungen zählen GPL-Version 2 und GPL-Version 3. Sie unterscheiden sich in einzelnen Bedingungen, etwa bei Patentfragen und den Voraussetzungen für die Bereitstellung des Quellcodes.
Prüfen Sie daher immer, welche Fassung für eine Komponente gilt und ob sie zusätzliche Berechtigungen enthält. Eine Lizenzangabe wie „GPL“ ohne Versionshinweis kann je nach Projektkontext Fragen offenlassen. Auch eine Option, spätere Fassungen zu verwenden, kann für die Beurteilung entscheidend sein.
Lizenzkompatibilität bei kombinierten Projekten
Softwareprojekte bestehen häufig aus eigenem Code und mehreren externen Komponenten. Die Lizenz jeder Komponente kann eigene Bedingungen mitbringen. Werden Bestandteile zusammengeführt oder gemeinsam weitergegeben, müssen die jeweiligen Bedingungen miteinander vereinbar sein.
Bei permissiven Lizenzen ist eine Kombination oft flexibler als bei Copyleft-Lizenzen. Trotzdem sollten Sie die konkreten Lizenztexte prüfen und nicht allein aus der Lizenzbezeichnung auf Kompatibilität schließen. Insbesondere GPL-Versionen und Apache License 2.0 lassen sich nicht in jeder Kombination gleich behandeln: Ob Code unter Apache 2.0 mit GPL-Code kombiniert werden kann, hängt unter anderem von der GPL-Version ab.
Eine praktische Bestandsaufnahme umfasst mehr als die Hauptdatei eines Projekts. Relevant sein können etwa eingebundene Bibliotheken, kopierte Codeabschnitte, generierte Dateien und mitgelieferte Dokumentation. Ebenso sollte festgehalten werden, welche Lizenz für welchen Bestandteil gilt und welche Hinweise bei einer Weitergabe erhalten bleiben müssen.
So wählen Sie eine Lizenz für eigenen Code aus
Wenn Sie eigenen Quellcode veröffentlichen möchten, beginnt die Auswahl mit einer Grundsatzfrage: Soll die Weitergabe möglichst wenig zusätzliche Vorgaben enthalten, oder sollen abgeleitete Versionen ebenfalls unter vergleichbaren Freiheiten weitergegeben werden?
- MIT passt zu einem permissiven Ansatz mit wenigen Weitergabebedingungen und einem erforderlichen Erhalt der Lizenz- und Copyright-Hinweise.
- Apache License 2.0 bietet ebenfalls permissive Bedingungen und enthält ausdrücklichere Regelungen zu Patentrechten, Hinweisen und Änderungen.
- GPL kommt infrage, wenn Copyleft-Bedingungen für weitergegebene abgeleitete Werke Teil des Lizenzziels sind.
Berücksichtigen Sie außerdem, welche Lizenzen in der vorgesehenen Umgebung bereits verwendet werden. Bei Bibliotheken, die in andere Projekte eingebunden werden sollen, kann die Kompatibilität für mögliche Nutzerinnen und Nutzer eine wichtige Rolle spielen. Bei gemeinschaftlich entwickeltem Code müssen zudem die Rechte an den Beiträgen geklärt sein, bevor eine Lizenz zuverlässig für das gesamte Projekt gewählt werden kann.
Die passende Wahl hängt somit nicht nur von einer allgemeinen Vorliebe für „offen“ oder „permissiv“ ab. Zweck, Verbreitungsform, Abhängigkeiten und gewünschte Weitergaberegeln gehören gemeinsam in die Entscheidung.
Lizenzpflichten im Arbeitsalltag im Blick behalten
Ein überschaubarer Prozess hilft, Lizenzbedingungen nicht erst kurz vor einer Veröffentlichung zu berücksichtigen. Erfassen Sie verwendete Komponenten und ihre Lizenzfassungen bereits bei der Aufnahme in ein Projekt. Bewahren Sie zugehörige Lizenztexte und erforderliche Hinweise in einer nachvollziehbaren Ablage auf.
Vor einer Weitergabe sollten Verantwortliche klären, welche Komponenten enthalten sind, ob Änderungen vorgenommen wurden und welche Quellcode- oder Dokumentationspflichten gelten. Das ist besonders wichtig, wenn Software als Paket, Gerät oder Bestandteil eines größeren Produkts an andere übermittelt wird. Bei Unsicherheit über konkrete Verpflichtungen sollten Sie qualifizierte rechtliche Beratung einholen. Wer quelloffene Software nicht weitergibt, sondern selbst betreibt, steht vor anderen Fragen; ein Beispiel ist der Selbstbetrieb von Nextcloud.
Fazit
MIT, Apache und GPL gewähren weitreichende Rechte, setzen aber unterschiedliche Schwerpunkte: MIT hält die Weitergabebedingungen knapp, Apache ergänzt ausdrückliche Patentregelungen, und GPL knüpft die Weitergabe abgeleiteter Software an Copyleft-Bedingungen. Prüfen Sie stets die genaue Lizenzfassung und alle enthaltenen Komponenten, bevor Sie Code kombinieren oder weitergeben.
Häufige Fragen
Schützt eine Open-Source-Lizenz automatisch den Namen oder das Logo eines Projekts?
Nein. Softwarelizenzen regeln in erster Linie Rechte am Code und an weiteren ausdrücklich erfassten Materialien. Marken- und Kennzeichenrechte sind davon grundsätzlich getrennt zu betrachten; prüfen Sie dafür die Hinweise des Projekts und lassen Sie offene Fragen fachkundig klären.
Kann ein Projekt gleichzeitig unter mehreren Lizenzen stehen?
Ja. Rechteinhaber können Software unter mehreren Lizenzoptionen anbieten, sodass Nutzende zwischen den vorgesehenen Bedingungen wählen können. Ob dies für ein konkretes Projekt gilt und welche Teile davon erfasst sind, muss anhand der Lizenzangaben geklärt werden.
Was gilt, wenn im Quellcode keine Lizenz angegeben ist?
Ein öffentlich einsehbarer Quellcode ist nicht automatisch zur freien Nutzung, Änderung oder Weitergabe freigegeben. Fehlt eine eindeutige Lizenzangabe, sollten Sie keine Nutzungsrechte unterstellen und die Rechteinhaber um Klärung bitten.
Sind Lizenzhinweise auch bei interner Nutzung erforderlich?
Die Antwort hängt von der jeweiligen Lizenz und der konkreten Verwendung ab. Pflichten, die ausdrücklich an eine Weitergabe geknüpft sind, werden nicht allein dadurch ausgelöst, dass Software innerhalb einer Organisation eingesetzt wird; andere vertragliche oder rechtliche Bedingungen können dennoch relevant sein.