Lizenzarten in der Anwendungsentwicklung und ihre Unterschiede

Was ist eine Softwarelizenz?

Eine Softwarelizenz ist eine Reihe von Regeln, die festlegen, wie eine Anwendung oder ein Quellcode von anderen genutzt werden darf.

Durch eine Lizenz kann der Anwendungsentwickler bestimmen, ob andere:

• Die Anwendung kostenlos nutzen dürfen.
• Den Quellcode ändern dürfen.
• Die Anwendung weiterverkaufen dürfen.
• Den Code für kommerzielle Projekte nutzen dürfen.
• Abgeleitete Werke erstellen dürfen.
• Den Quellcode nach Änderungen schließen dürfen.
• Den geänderten Quellcode teilen müssen.

Selbst wenn Quellcode öffentlich auf GitHub verfügbar ist, bedeutet das nicht, dass der Code ohne Einschränkungen frei genutzt werden kann.

Ohne Lizenz gelten automatisch die Urheberrechtsregeln. Das bedeutet, der Codeinhaber behält alle Rechte, und andere haben im Wesentlichen keine Erlaubnis, den Code zu kopieren, zu ändern oder zu verbreiten.

Open Source bedeutet nicht frei ohne Regeln

Viele nehmen an, dass Open Source bedeutet, Quellcode könne bedingungslos für alles verwendet werden. In Wirklichkeit hat jede Open-Source-Lizenz unterschiedliche Regeln.

Im Allgemeinen erlauben Open-Source-Lizenzen die Nutzung, das Studium, die Änderung und die Weitergabe der Software. Einige Lizenzen gewähren jedoch sehr weitreichende Freiheiten, während andere verlangen, dass abgeleitete Anwendungen Open Source bleiben.

Softwarelizenzen werden üblicherweise in mehrere Hauptgruppen unterteilt:

1. Permissive Lizenz
2. Copyleft-Lizenz
3. Schwache Copyleft-Lizenz
4. Proprietäre Lizenz
5. Public-Domain-Lizenz

Vergleichstabelle der Softwarelizenzen

Lizenz	Typ	Kommerzielle Nutzung erlaubt	Änderung erlaubt	Kann geschlossen werden	Muss Quellcode offenlegen	Patentschutz	Geeignet für
MIT	Permissiv	Ja	Ja	Ja	Nein	Nicht explizit genannt	Bibliotheken, Anwendungen, persönliche Projekte
Apache 2.0	Permissiv	Ja	Ja	Ja	Nein	Ja	Unternehmensprojekte und -technologien
BSD 2-Clause	Permissiv	Ja	Ja	Ja	Nein	Nicht explizit genannt	Systeme, Bibliotheken und Anwendungen
BSD 3-Clause	Permissiv	Ja	Ja	Ja	Nein	Nicht explizit genannt	Projekte, die Namensschutz des Erstellers benötigen
ISC	Permissiv	Ja	Ja	Ja	Nein	Nicht explizit genannt	Kleine Projekte und JavaScript-Bibliotheken
GNU GPL	Starkes Copyleft	Ja	Ja	Nein für abgeleitete Werke	Ja, bei Weitergabe	Abhängig von Version	Vollständig Open-Source-Anwendungen
GNU LGPL	Schwaches Copyleft	Ja	Ja	Ja, unter bestimmten Bedingungen	Nur bestimmte Bibliotheksteile	Abhängig von Version	Open-Source-Bibliotheken
GNU AGPL	Starkes Netzwerk-Copyleft	Ja	Ja	Im Allgemeinen nein	Ja, einschließlich Netzwerkdienst	Ja bei AGPLv3	Server, SaaS und Webanwendungen
MPL 2.0	Datei-Copyleft	Ja	Ja	Ja, für separate Dateien	Nur geänderte MPL-lizenzierte Dateien	Ja	Gemischte Open-Source- und proprietäre Projekte
Unlicense	Public-Domain-ähnlich	Ja	Ja	Ja	Nein	Nein	Einfacher Code, der freigegeben werden soll
Proprietär	Geschlossener Quellcode	Nach Erlaubnis des Inhabers	Normalerweise nicht	Ja	Nein	Nach Vereinbarung	Interne Anwendungen und kostenpflichtige Produkte

1. MIT-Lizenz

Die MIT-Lizenz ist eine der einfachsten und flexibelsten Open-Source-Lizenzen.

Diese Lizenz erlaubt anderen:

• Die Software zu nutzen.
• Den Quellcode zu kopieren.
• Den Quellcode zu ändern.
• Die Software zu verkaufen.
• Den Code in kostenpflichtige Anwendungen einzubinden.
• Die Anwendung in Closed Source umzuwandeln.

Die Hauptanforderung ist, dass der Urheberrechtshinweis und der MIT-Lizenstext in allen Kopien oder wesentlichen Teilen der Software enthalten bleiben müssen.

Vorteile der MIT-Lizenz

• Lizenstext ist kurz.
• Leicht verständlich.
• Kommerziell nutzbar.
• Kann in Closed-Source-Anwendungen verwendet werden.
• Weit verbreitet in Bibliotheken und Frameworks.

Nachteile der MIT-Lizenz

• Andere können den Code nehmen, ändern und dann als Closed-Source-Anwendung verkaufen.
• Hat keinen so klaren Patentschutz wie Apache 2.0.
• Der Codeinhaber kann nicht verlangen, dass geänderte Versionen Open Source bleiben.

Geeignet, wenn

MIT ist geeignet für Entwickler, die möchten, dass ihr Quellcode so weit wie möglich genutzt wird, ohne viele Einschränkungen aufzuerlegen.

2. Apache License 2.0

Die Apache License 2.0 hat ähnliche Eigenschaften wie MIT. Die Software kann verwendet, geändert, verbreitet und in kommerzielle Anwendungen eingebunden werden.

Der Hauptunterschied besteht darin, dass Apache 2.0 Bestimmungen zu Patenten enthält. Diese Lizenz verlangt auch Namensnennung durch Dateien wie LICENSE und, falls vorhanden, NOTICE.

Vorteile von Apache 2.0

• Kann für kommerzielle Projekte verwendet werden.
• Kann in Closed-Source-Anwendungen eingebunden werden.
• Hat klareren Patentschutz und -bestimmungen.
• Geeignet für Unternehmensprojekte.
• Benutzer müssen wichtige Änderungen dokumentieren.

Nachteile von Apache 2.0

• Lizenstext ist länger im Vergleich zu MIT.
• Die Verwaltung von Namensnennung und der NOTICE-Datei kann komplexer sein.
• Verlangt nicht, dass abgeleitete Werke Open Source bleiben.

Geeignet, wenn

Apache 2.0 ist geeignet für professionelle Projekte oder Unternehmen, die eine flexible Lizenz mit klarerem Patentschutz wünschen.

3. BSD-Lizenz

Die BSD-Lizenz ist eine permissive Lizenz ähnlich wie MIT. Sie hat mehrere Versionen, aber die gebräuchlichsten sind BSD 2-Clause und BSD 3-Clause.

Beide erlauben die Nutzung, Änderung und Verbreitung sowohl im Quellcode als auch in binärer Form.

BSD 2-Clause

BSD 2-Clause wird auch als Vereinfachte BSD-Lizenz bezeichnet.

Die Hauptanforderungen:

• Der Urheberrechtshinweis muss enthalten bleiben.
• Der Lizenstext und der Haftungsausschluss müssen enthalten bleiben.

BSD 3-Clause

BSD 3-Clause hat eine zusätzliche Regel: Die Namen der Ersteller oder Mitwirkenden dürfen nicht zur Förderung abgeleiteter Produkte ohne Erlaubnis verwendet werden.

Vorteile der BSD-Lizenz

• Einfach und flexibel.
• Kommerziell nutzbar.
• Kann in Closed-Source-Anwendungen eingebunden werden.
• Geeignet für Bibliotheken und Systemsoftware.

Nachteile der BSD-Lizenz

• Codeänderungen müssen nicht geteilt werden.
• Hat keine so klaren Patentbestimmungen wie Apache 2.0.
• Andere können proprietäre Produkte mit dem Code erstellen.

4. ISC-Lizenz

Die ISC-Lizenz ist eine sehr prägnante permissive Lizenz. Funktional ist sie nahezu identisch mit MIT und BSD 2-Clause.

Benutzer dürfen die Software verwenden, kopieren, ändern und verbreiten, solange der Urheberrechtshinweis und der Erlaubnistext enthalten bleiben.

Vorteile der ISC-Lizenz

• Sehr kurzer Text.
• Einfach anzuwenden.
• Kommerzielle Nutzung erlaubt.
• Kann in Closed-Source-Anwendungen verwendet werden.

Nachteile der ISC-Lizenz

• Verlangt nicht, dass geänderte Versionen Open Source bleiben.
• Patentbestimmungen sind nicht so klar wie bei Apache 2.0.
• Weniger geeignet, wenn der Ersteller die Offenheit des abgeleiteten Codes wahren möchte.

ISC ist in Paketen und Bibliotheken des JavaScript-Ökosystems recht verbreitet.

5. GNU General Public License oder GPL

GNU ist kein einzelner Lizenzname. GNU hat mehrere Lizenztypen, wie:

• GNU GPL
• GNU LGPL
• GNU AGPL

Die GNU General Public License oder GPL ist eine starke Copyleft-Lizenz. Das bedeutet, wenn GPL-Software geändert und als abgeleitetes Werk verbreitet wird, muss der Quellcode dieser Anwendung ebenfalls unter einer kompatiblen GPL-Lizenz verfügbar gemacht werden.

GPL verbietet die kommerzielle Nutzung nicht. Entwickler können GPL-Software weiterhin verkaufen. Die Empfänger der Software müssen jedoch die von der GPL gewährten Rechte erhalten, einschließlich des Zugangs zum Quellcode unter den von der Lizenz geforderten Bedingungen.

Vorteile von GNU GPL

• Hält Software und ihre Ableitungen offen.
• Verbesserungen und Weiterentwicklungen können an die Gemeinschaft zurückfließen.
• Verhindert, dass andere den Code nehmen und den Quellcode abgeleiteter Werke schließen.
• Geeignet für gemeinschaftsbasierte Projekte.

Nachteile von GNU GPL

• Schwierig in proprietären Produkten zu verwenden.
• Vorsicht geboten bei der Kombination mit anderem lizenziertem Code.
• Weniger geeignet für Unternehmen, die den Quellcode ihres Produkts geschlossen halten möchten.

Muss interner Code offengelegt werden?

Nicht immer.

Wird eine GPL-Anwendung nur intern genutzt und nicht an andere weitergegeben, muss der Quellcode in der Regel nicht automatisch der Öffentlichkeit zugänglich gemacht werden.

Die Hauptpflicht der GPL entsteht normalerweise, wenn die Software oder abgeleitete Werke verbreitet werden.

6. GNU Lesser General Public License oder LGPL

LGPL ist eine flexiblere Copyleft-Version im Vergleich zu GPL.

Diese Lizenz wird normalerweise für Bibliotheken verwendet. Proprietäre Anwendungen können LGPL-Bibliotheken nutzen oder darauf verlinken, solange sie die Lizenzbedingungen einhalten. GNU gibt an, dass LGPL-Bibliotheken mit proprietären Anwendungen verlinkt werden können, im Gegensatz zu GPL, das eine stärkere Copyleft-Wirkung auf abgeleitete Werke hat.

Vorteile von GNU LGPL

• Geeignet für Open-Source-Bibliotheken.
• Kann von Closed-Source-Anwendungen genutzt werden.
• Änderungen an der LGPL-Bibliothek müssen weiterhin den LGPL-Regeln folgen.
• Erweitert die Nutzung der Bibliothek, ohne alle Copyleft-Schutzmechanismen aufzugeben.

Nachteile von GNU LGPL

• Integrationsregeln sind komplexer als bei MIT.
• Verlinkungs- und Verbreitungsmethoden müssen beachtet werden.
• Direkte Änderungen an der Bibliothek können Verpflichtungen zur Weitergabe des Quellcodes der Bibliothek auslösen.

Geeignet, wenn

LGPL ist geeignet, wenn Sie eine Bibliothek erstellen, die sowohl von Open-Source- als auch von proprietären Anwendungen genutzt werden soll.

7. GNU Affero General Public License oder AGPL

AGPL ist eine Copyleft-Lizenz, die speziell für Software entwickelt wurde, die über ein Netzwerk genutzt wird, wie:

• Webanwendungen.
• Software as a Service oder SaaS.
• APIs.
• Server.
• Online-Plattformen.

Bei regulärer GPL kann ein Unternehmen die Software modifizieren und auf einem Server ausführen, ohne die Anwendung zu verbreiten. In einer solchen Situation greift die Quellcode-Weitergabepflicht der GPL möglicherweise nicht.

AGPL fügt Verpflichtungen in Bezug auf die Nutzung von Software über ein Netzwerk hinzu. Benutzer, die über ein Netzwerk mit einer modifizierten Version der Software interagieren, müssen die Möglichkeit haben, auf den entsprechenden Quellcode zuzugreifen.

Vorteile von GNU AGPL

• Geeignet, um SaaS-Anwendungen Open Source zu halten.
• Verhindert, dass andere eine Serveranwendung modifizieren und deren Code schließen.
• Bietet stärkeren Copyleft-Schutz.

Nachteile von GNU AGPL

• Schwierig in proprietären Anwendungen zu verwenden.
• Wird oft von Unternehmen gemieden, die den Quellcode ihres Servers nicht öffnen möchten.
• Integration erfordert sorgfältige Prüfung.

8. Mozilla Public License 2.0

Die Mozilla Public License oder MPL 2.0 ist eine Datei-Copyleft-Lizenz.

Das bedeutet, dass Dateien, die bereits unter MPL stehen und später geändert werden, weiterhin unter MPL verfügbar bleiben müssen. Diese Dateien können jedoch weiterhin mit anderen proprietären Dateien in einer einzigen Anwendung kombiniert werden.

Daher liegt MPL zwischen permissiven Lizenzen wie MIT und starken Copyleft-Lizenzen wie GPL. MPL 2.0 ist ebenfalls eine von der Open Source Initiative anerkannte Open-Source-Lizenz.

Vorteile von MPL 2.0

• Flexibler als GPL.
• Geänderte Open-Source-Dateien bleiben offen.
• Kann mit Closed-Source-Code kombiniert werden.
• Geeignet für Projekte mit sowohl offenen als auch proprietären Modulen.

Nachteile von MPL 2.0

• Komplexer als MIT oder BSD.
• Entwickler müssen wissen, welche Dateien unter MPL stehen.
• Weniger geeignet, wenn die gesamte abgeleitete Anwendung Open Source bleiben soll.

9. Unlicense

Die Unlicense wird verwendet, wenn ein Ersteller Code in die Public Domain entlassen möchte, soweit gesetzlich zulässig.

Im Allgemeinen können Benutzer:

• Den Code kopieren.
• Den Code ändern.
• Den Code verkaufen.
• Den Code verbreiten.
• Den Code ohne Namensnennung nutzen.

Die Unlicense stellt sehr wenige Bedingungen an die Benutzer.

Vorteile der Unlicense

• Sehr frei.
• Fast keine Namensnennungspflichten.
• Geeignet für kleine Code-Snippets oder Beispielcode.

Nachteile der Unlicense

• Das Konzept der Public Domain kann in jedem Land unterschiedlich behandelt werden.
• Nicht ideal für Unternehmensprojekte.
• Bietet keinen klaren Patentschutz.
• Unternehmensmitwirkende bevorzugen möglicherweise MIT oder Apache 2.0.

10. Proprietäre Lizenz

Eine proprietäre Lizenz ist eine Lizenz für Closed-Source-Anwendungen. Die Rechte zur Nutzung der Software werden vollständig vom Anwendungsinhaber bestimmt.

Benutzer erhalten in der Regel nur die Erlaubnis, die Anwendung zu nutzen, nicht jedoch, den Quellcode zu besitzen oder zu ändern.

Beispiele:

• Abonnementanwendungen.
• Interne Unternehmenssoftware.
• Kostenpflichtige Kassensysteme.
• Hotelverwaltungssysteme.
• Kundenspezifische Anwendungen.
• Kostenpflichtige Desktop-Software.

Übliche Regeln

• Die Anwendung darf nicht kopiert werden.
• Konten dürfen nicht geteilt werden.
• Der Quellcode darf nicht eingesehen oder geändert werden.
• Die Anwendung darf nicht weiterverkauft werden.
• Die Nutzung ist auf Gerät, Benutzer, Unternehmen oder Zeit begrenzt.
• Die Nutzungsrechte enden, wenn das Abonnement eingestellt wird.

Geeignet, wenn

Eine proprietäre Lizenz ist geeignet, wenn die Anwendung ein Geschäftsprodukt ist und der Quellcode geschlossen bleiben muss.

11. Dual Licensing

Dual Licensing ist eine Methode, zwei Lizenzoptionen für dieselbe Software anzubieten.

Beispiele:

• Kostenlos mit GPL für Open-Source-Projekte.
• Kostenpflichtig mit einer kommerziellen Lizenz für Unternehmen, die die Software nutzen möchten, ohne der GPL zu folgen.

Dieses Modell ermöglicht es Softwareentwicklern, von der Open-Source-Community zu profitieren und gleichzeitig kommerzielle Lizenzen zu verkaufen.

Die Umsetzung von Dual Licensing ist jedoch einfacher, wenn das Urheberrecht am Quellcode vollständig bei einem einzigen Unternehmen oder einer einzigen Organisation liegt. Bei vielen Mitwirkenden muss die Verwaltung der Beitragsrechte klar festgelegt sein.

Kann Creative Commons für Quellcode verwendet werden?

Creative Commons oder CC ist eher geeignet für:

• Artikel.
• Bilder.
• Videos.
• Musik.
• Dokumentation.
• Lernmaterialien.
• Designs und kreative Inhalte.

Creative Commons empfiehlt nicht, CC-Lizenzen für Software und Hardware zu verwenden, da es spezifische Softwarelizenzen gibt, die Themen wie Quellcode, Verbreitung und Änderung angemessener behandeln.

In einem einzelnen Anwendungsprojekt können Sie verwenden:

• MIT, Apache oder GPL für den Quellcode.
• Creative Commons für Dokumentation, Bilder oder andere Materialien.

Stellen Sie sicher, dass jeder Teil separat erläutert wird, um Benutzer nicht zu verwirren.

Unterschiede zwischen Permissiv und Copyleft

Aspekt	Permissive Lizenz	Copyleft-Lizenz
Beispiele	MIT, Apache 2.0, BSD, ISC	GPL, AGPL
Kommerzielle Nutzung	Erlaubt	Erlaubt
Codeänderung	Erlaubt	Erlaubt
Kann Closed Source werden	Im Allgemeinen erlaubt	Im Allgemeinen nicht für abgeleitete Werke
Änderungen teilen	Nein	Ja, unter bestimmten Bedingungen
Einschränkungsgrad	Einfacher	Strenger
Geeignet für Unternehmen	Sehr geeignet	Hängt vom Geschäftsmodell ab
Geeignet für Open-Source-Community	Geeignet	Sehr geeignet
Schutz der Code-Offenheit	Niedrig	Hoch

Welche Lizenz sollten Sie wählen?

Verwenden Sie MIT, wenn

• Sie eine einfache Lizenz möchten.
• Der Code so weit wie möglich genutzt werden soll.
• Es Ihnen nichts ausmacht, wenn der Code in Closed-Source-Anwendungen verwendet wird.
• Sie eine Bibliothek oder ein persönliches Projekt erstellen.

Verwenden Sie Apache 2.0, wenn

• Sie die Freiheit von MIT möchten.
• Sie klarere Patentbestimmungen benötigen.
• Sie ein Unternehmensprojekt erstellen.
• Sie planen, viele Beiträge anzunehmen.

Verwenden Sie BSD, wenn

• Sie eine einfache permissive Lizenz möchten.
• Sie Systemsoftware oder eine Bibliothek erstellen.
• Sie nicht möchten, dass der Name des Erstellers zur Förderung abgeleiteter Produkte verwendet wird.

Verwenden Sie GPL, wenn

• Sie möchten, dass abgeleitete Anwendungen Open Source bleiben.
• Sie nicht möchten, dass Unternehmen den Code nehmen und dessen Quellcode schließen.
• Sie ein Gemeinschaftsprojekt erstellen.

Verwenden Sie LGPL, wenn

• Sie eine Bibliothek erstellen.
• Die Bibliothek auch von proprietären Anwendungen nutzbar sein soll.
• Sie möchten, dass Änderungen an der Bibliothek offen bleiben.

Verwenden Sie AGPL, wenn

• Sie eine SaaS- oder Serveranwendung erstellen.
• Sie möchten, dass Änderungen, die über ein Netzwerk genutzt werden, geteilt werden.
• Sie nicht möchten, dass Unternehmen modifizierte Versionen privat auf ihren Servern betreiben.

Verwenden Sie MPL 2.0, wenn

• Ein Teil des Codes offen bleiben soll.
• Sie dennoch Code mit proprietären Modulen kombinieren möchten.
• Sie einen Mittelweg zwischen MIT und GPL benötigen.

Verwenden Sie eine proprietäre Lizenz, wenn

• Der Quellcode nicht geöffnet werden kann.
• Die Anwendung für geschäftliche Zwecke erstellt wird.
• Sie die Softwarnutzung einschränken möchten.
• Die Anwendung über ein Lizenz- oder Abonnementsystem verkauft wird.

Beispiel für die Lizenzanwendung auf GitHub

Typischerweise wird der Lizenstext in der folgenden Datei gespeichert:

LICENSE

oder:

LICENSE.md

Diese Datei wird im Haupt- oder Stammverzeichnis des Repositorys abgelegt. GitHub empfiehlt auch, die Lizenzdatei direkt in das Repository aufzunehmen, damit sie verfügbar ist, wenn das Projekt geklont, heruntergeladen oder verbreitet wird.

Beispiel für eine Projektstruktur:

app-name/
├── app/
├── public/
├── src/
├── README.md
├── LICENSE
└── package.json

Kurzinfo kann auch in README.md hinzugefügt werden:

## Lizenz

Dieses Projekt ist unter der MIT-Lizenz lizenziert.
Weitere Informationen finden Sie in der LICENSE-Datei.

Dinge, die vor der Wahl einer Lizenz zu prüfen sind

Bevor Sie sich für eine Lizenz entscheiden, beachten Sie Folgendes:

1. Kann die Anwendung kommerziell genutzt werden?
2. Dürfen andere den Quellcode ändern?
3. Müssen Änderungen geteilt werden?
4. Können abgeleitete Werke Closed Source sein?
5. Wird die Anwendung als SaaS genutzt?
6. Verwendet das Projekt Bibliotheken von Drittanbietern?
7. Sind die Lizenzen aller Abhängigkeiten kompatibel?
8. Gibt es Code von anderen Mitwirkenden?
9. Wird Patentschutz benötigt?
10. Wird die Anwendung an Kunden verkauft?

Wählen Sie nicht einfach eine Lizenz, weil sie beliebt ist. Wählen Sie eine Lizenz basierend auf den Zielen des Projekts und der Art und Weise, wie die Anwendung genutzt wird.

Fazit

Jede Softwarelizenz gewährt unterschiedliche Rechte und Pflichten.

MIT, BSD und ISC eignen sich für Projekte, die den Benutzern weitreichende Freiheiten gewähren möchten. Apache 2.0 bietet ähnliche Freiheiten mit klareren Patentbestimmungen.

GPL eignet sich, um abgeleitete Anwendungen Open Source zu halten. LGPL ist eher für Bibliotheken geeignet, während AGPL zusätzlichen Schutz für Webanwendungen, Server und SaaS bietet.

MPL 2.0 kann ein Mittelweg sein, da es nur bestimmte Dateien offen halten muss. Eine proprietäre Lizenz ist dagegen eher für Geschäftsanwendungen geeignet, deren Quellcode geschlossen bleiben muss.

Die Lizenzauswahl sollte früh in der Entwicklung erfolgen. Neben dem Schutz des Anwendungsentwicklers hilft eine klare Lizenz auch Benutzern und Mitwirkenden zu verstehen, was erlaubt ist und was nicht.

Hinweis: Dieser Artikel bietet eine allgemeine Erklärung und stellt keine Rechtsberatung dar. Für groß angelegte kommerzielle Anwendungen, starke Abhängigkeitsnutzung oder Projekte mit vielen Mitwirkenden konsultieren Sie jemanden, der sich mit geistigem Eigentumsrecht bezüglich der Lizenzauswahl auskennt.