# Open-Source-Lizenzen für Entscheider: Was MIT, GPL, AGPL und BSL bedeuten

> Lizenzen entscheiden darüber, was Sie mit Software tun dürfen – und welche Pflichten folgen. Ein Überblick über die Lizenzfamilien, über die Lizenzwechsel bei HashiCorp, Redis und Elastic und über Compliance-Grundlagen.

- Rubrik: Open Source
- Format: Erklärstück
- Autor: Redaktion Umbrecher (umbrecher, https://umbrecher.com/ueber)
- Veröffentlicht: 2026-08-27
- Kanonische URL: https://umbrecher.com/artikel/open-source-lizenzen-fuer-entscheider

## Das Wichtigste in Kürze

- Permissive Lizenzen wie MIT, BSD und Apache 2.0 erlauben auch den Einbau in proprietäre Produkte und verlangen im Wesentlichen, Copyright-Hinweis und Lizenztext beizulegen.
- Copyleft-Lizenzen wie die GPL verlangen Offenheit erst bei der Weitergabe veränderter Software; die AGPLv3 erstreckt diese Pflicht auf Software, die als Netzdienst angeboten wird.
- Source-available-Lizenzen wie BSL, SSPL, RSALv2 und ELv2 sind nicht von der OSI als Open Source anerkannt, weil sie bestimmte Nutzungen einschränken.
- Lizenzwechsel wie bei HashiCorp, Redis und Elastic gelten nur für künftige Versionen und haben jeweils Community-Forks ausgelöst: OpenTofu, Valkey und OpenSearch.
- Ein gepflegtes Komponenteninventar mit SBOM in SPDX oder CycloneDX ist die Grundlage für Lizenz-Compliance und für die SBOM-Pflicht aus dem EU Cyber Resilience Act.

Eine Open-Source-Lizenz legt fest, was Sie mit einer Software tun dürfen und welche Pflichten Sie dabei übernehmen. „Open Source“ klingt nach einem einheitlichen Versprechen. In Wahrheit regeln Dutzende Lizenzen sehr unterschiedlich, was Sie mit einer Software tun dürfen und welche Pflichten Sie übernehmen. Für die meisten Unternehmen ist das im Alltag unkritisch – solange man die Grundfamilien kennt und weiß, wann genauer hinzusehen ist.

Dieser Beitrag ersetzt keine Rechtsberatung. Er soll Ihnen helfen, die richtigen Fragen zu stellen.

## Was eine Open-Source-Lizenz ausmacht

Als Open Source im engeren Sinn gelten Lizenzen, die die Kriterien der Open Source Definition erfüllen und von der Open Source Initiative (OSI) anerkannt sind. Kern ist: Jeder darf die Software für jeden Zweck nutzen, den Quellcode einsehen, verändern und weitergeben – ohne Diskriminierung bestimmter Personen oder Einsatzfelder. Die Unterschiede liegen vor allem in der Frage, **was passiert, wenn Sie die Software verändern und weitergeben**.

## Die Lizenzfamilien

### Permissive Lizenzen: MIT, Apache 2.0, BSD

Permissive („freizügige“) Lizenzen stellen kaum Bedingungen. Sie dürfen den Code nehmen, verändern, in eigene – auch proprietäre – Produkte einbauen und verkaufen. Pflicht ist im Wesentlichen, den Copyright-Hinweis und den Lizenztext beizulegen.

- **MIT** ist kurz und sehr verbreitet.
- **BSD** (meist in der 2- oder 3-Klausel-Fassung) ist ähnlich; die 3-Klausel-Variante verbietet zusätzlich, mit dem Namen der Urheber zu werben.
- **Apache 2.0** ergänzt eine ausdrückliche Patentlizenz und Regeln zum Umgang mit Änderungshinweisen. Für Unternehmen ist die Patentklausel oft ein Pluspunkt.

### Copyleft: GPL und LGPL

Copyleft-Lizenzen sichern, dass Software frei bleibt: Wer veränderte Versionen **weitergibt**, muss sie unter derselben Lizenz und mit Quellcode weitergeben.

- **GPL** (GNU General Public License, verbreitet in Version 2 und 3) ist „starkes“ Copyleft. Wird GPL-Code in ein eigenes Programm eingebaut und dieses verteilt, muss in der Regel das Gesamtwerk unter der GPL stehen. Der Linux-Kernel steht beispielsweise unter der GPLv2.
- **LGPL** (Lesser GPL) ist „schwächer“: Sie dürfen eine LGPL-Bibliothek aus eigener, auch proprietärer Software heraus nutzen, solange Änderungen an der Bibliothek selbst offengelegt werden und die Bibliothek austauschbar bleibt.
- Zur schwachen Copyleft-Familie zählt auch die **MPL 2.0** (Mozilla Public License), die auf Dateiebene greift.

Wichtig: Die Pflichten der GPL entstehen bei der **Weitergabe**. Wer GPL-Software nur intern nutzt, auch verändert, muss nichts veröffentlichen.

### Netzwerk-Copyleft: AGPL

Genau hier setzt die **AGPLv3** (Affero GPL) an. Sie erweitert die GPL um den Fall, dass Nutzer über ein Netzwerk mit der Software interagieren – also typischerweise bei Webanwendungen und SaaS. Wer eine veränderte AGPL-Software als Dienst für andere anbietet, muss den Nutzern den Quellcode der Änderungen zugänglich machen. Beispiele sind Nextcloud oder der Matrix-Server Synapse. Für die rein interne Nutzung unveränderter Software ändert sich in der Regel nichts; für Anbieter, die Software als Dienst vermarkten, ist die AGPL dagegen eine gewichtige Bedingung.

### Source-available: BSL, SSPL, RSAL und Co.

Daneben gibt es Lizenzen, bei denen der Quellcode einsehbar ist, die aber **nicht** von der OSI als Open Source anerkannt sind, weil sie bestimmte Nutzungen einschränken. Man spricht von „Source-available“.

- **Business Source License (BSL/BUSL 1.1):** Die Nutzung ist mit Ausnahmen erlaubt, die der Hersteller festlegt – oft das Verbot, ein konkurrierendes Angebot zu betreiben. Nach einem festgelegten Datum wandelt sich jede Version automatisch in eine Open-Source-Lizenz um.
- **Server Side Public License (SSPL):** 2018 von MongoDB eingeführt. Sie verlangt, dass wer die Software als Dienst anbietet, den Quellcode des gesamten Dienstes – inklusive Verwaltungs-, Überwachungs- und Backup-Software – unter der SSPL offenlegt. Die OSI erkennt sie nicht als Open-Source-Lizenz an.
- **Redis Source Available License (RSALv2)** und **Elastic License 2.0 (ELv2):** herstellereigene Lizenzen, die vor allem verhindern sollen, dass Dritte die Software als konkurrierenden Managed Service anbieten.

Für die meisten Anwenderunternehmen, die solche Software intern nutzen, sind diese Einschränkungen oft unproblematisch. Riskant werden sie, wenn Sie selbst Dienste für Kunden anbieten – oder wenn Ihre Exit-Strategie darauf baut, dass ein Dritter den Betrieb übernehmen kann.

## Drei Lizenzwechsel und ihre Folgen

Source-available-Lizenzen sind vor allem durch Lizenzwechsel bekannt geworden: Projekte, die von einem Unternehmen getragen wurden, wechselten von Open Source zu einem restriktiveren Modell.

**HashiCorp/Terraform:** Am 10. August 2023 kündigte HashiCorp an, künftige Versionen seiner Produkte – darunter das Infrastruktur-Werkzeug Terraform – nicht mehr unter der MPL 2.0, sondern unter der BSL 1.1 zu veröffentlichen. Als Reaktion entstand der Fork OpenTF, der im September 2023 als OpenTofu unter das Dach der Linux Foundation ging. Am 10. Januar 2024 erschien mit OpenTofu 1.6.0 die erste stabile Version; im April 2025 wurde das Projekt als Sandbox-Projekt in die Cloud Native Computing Foundation (CNCF) aufgenommen. HashiCorp selbst gehört seit Februar 2025 zu IBM. Eine Rückkehr zu einer Open-Source-Lizenz für Terraform hat die Redaktion bis Redaktionsschluss nicht feststellen können.

**Redis:** Am 20. März 2024 kündigte Redis an, ab Version 7.4 von der BSD-Lizenz auf eine Doppellizenz aus RSALv2 und SSPLv1 zu wechseln. Wenige Tage später, am 28. März 2024, kündigte die Linux Foundation den Fork Valkey an, der auf Redis 7.2.4 aufsetzt, unter der BSD-Lizenz bleibt und unter anderem von AWS, Google Cloud und Oracle unterstützt wird. Am 1. Mai 2025 folgte die Kehrtwende: Mit Redis 8 bietet Redis die OSI-anerkannte AGPLv3 als zusätzliche Lizenzoption an.

**Elastic:** Bereits im Januar 2021 hatte Elastic angekündigt, Elasticsearch und Kibana ab Version 7.11 nicht mehr unter Apache 2.0, sondern unter SSPL und Elastic License anzubieten. AWS startete daraufhin 2021 den Fork OpenSearch auf Basis der letzten Apache-lizenzierten Version. Im September 2024 übergab AWS OpenSearch an die neu gegründete OpenSearch Software Foundation unter dem Dach der Linux Foundation. Am 29. August 2024 kündigte Elastic an, die AGPL als weitere Lizenzoption hinzuzufügen.

Die Lehre für Entscheider: Ein Lizenzwechsel gilt nicht rückwirkend – bereits veröffentlichte Versionen bleiben unter ihrer alten Lizenz nutzbar. Aber künftige Updates können anderen Regeln folgen. Projekte, die von einer neutralen Stiftung und mehreren Unternehmen getragen werden, sind gegen solche Kurswechsel besser geschützt als Projekte eines einzelnen Herstellers, der sich Rechte über eine Beitragsvereinbarung (Contributor License Agreement, CLA) sichert. Wie Firmen hinter Open-Source-Projekten wirtschaften, erklärt [Wie Open-Source-Firmen sich finanzieren](/artikel/wie-open-source-firmen-sich-finanzieren).

## Die Lizenzen im Überblick

| Lizenz | Familie | OSI-anerkannt | Kernpflicht bei Weitergabe | Besonderheit |
|---|---|---|---|---|
| MIT | permissiv | ja | Copyright-Hinweis beilegen | sehr kurz und einfach |
| BSD (2/3-Klausel) | permissiv | ja | Copyright-Hinweis beilegen | 3-Klausel: kein Werben mit Urhebernamen |
| Apache 2.0 | permissiv | ja | Hinweise, Änderungsvermerke | ausdrückliche Patentlizenz |
| MPL 2.0 | schwaches Copyleft | ja | geänderte Dateien offenlegen | Copyleft auf Dateiebene |
| LGPL | schwaches Copyleft | ja | Änderungen an der Bibliothek offenlegen | Einbindung in proprietäre Software möglich |
| GPL v2/v3 | starkes Copyleft | ja | Gesamtwerk unter GPL mit Quellcode | Pflichten erst bei Weitergabe |
| AGPLv3 | Netzwerk-Copyleft | ja | Quellcode auch bei Bereitstellung als Netzdienst | relevant für SaaS-Anbieter |
| BSL 1.1 | source-available | nein | herstellerspezifische Nutzungsgrenzen | wird nach Frist zu Open Source |
| SSPL | source-available | nein | Offenlegung des gesamten Dienst-Stacks | von MongoDB eingeführt |
| RSALv2 / ELv2 | source-available | nein | kein konkurrierender Managed Service | Herstellerlizenzen |

## Compliance-Grundlagen

Lizenz-Compliance klingt aufwendig, lässt sich aber mit wenigen Bausteinen beherrschen:

1. **Inventar führen:** Wissen, welche Open-Source-Komponenten in welchen Versionen in Ihren Produkten und Systemen stecken.
2. **SBOM erstellen:** Eine Software Bill of Materials (Stückliste der Software) listet alle Komponenten samt Lizenz maschinenlesbar auf. Etablierte Formate sind SPDX und CycloneDX. Viele Build-Werkzeuge können SBOMs automatisch erzeugen.
3. **Lizenzrichtlinie festlegen:** Welche Lizenzen sind ohne Prüfung erlaubt (meist permissive), welche brauchen eine Freigabe (Copyleft, AGPL), welche sind ausgeschlossen?
4. **Pflichten erfüllen:** Lizenztexte und Hinweise mitliefern, bei Copyleft Quellcode bereitstellen.
5. **Lizenzänderungen beobachten:** Vor allem bei Komponenten, hinter denen ein einzelnes Unternehmen steht.

Die SBOM ist längst nicht mehr nur ein Compliance-Werkzeug. Der EU Cyber Resilience Act (Verordnung (EU) 2024/2847) verpflichtet Hersteller von Produkten mit digitalen Elementen künftig unter anderem, eine SBOM zu erstellen; die meisten Pflichten gelten ab dem 11. Dezember 2027. Wer jetzt Ordnung in sein Komponenteninventar bringt, löst damit zwei Aufgaben auf einmal. Wie der CRA mit Open-Source-Projekten umgeht, beleuchtet unser Essay [Wer pflegt das Fundament?](/artikel/wer-pflegt-das-fundament)

Dieser Beitrag ersetzt keine Rechtsberatung.

## Häufige Fragen

### Muss man bei interner Nutzung von GPL-Software den Quellcode veröffentlichen?

Nein. Die Pflichten der GPL entstehen erst bei der Weitergabe der Software. Wer GPL-Software nur intern nutzt, auch in veränderter Form, muss nichts veröffentlichen. Anders ist es bei der AGPLv3: Wer eine veränderte AGPL-Software als Netzdienst für andere anbietet, muss den Nutzern den Quellcode der Änderungen zugänglich machen. Im Einzelfall rechtlich prüfen lassen.

### Was ist der Unterschied zwischen Open Source und Source-available?

Open-Source-Lizenzen sind von der Open Source Initiative (OSI) anerkannt und erlauben Nutzung, Einsicht, Veränderung und Weitergabe für jeden Zweck. Bei Source-available-Lizenzen wie BSL, SSPL, RSALv2 oder Elastic License 2.0 ist der Quellcode zwar einsehbar, bestimmte Nutzungen sind aber eingeschränkt – oft das Betreiben eines konkurrierenden Managed Service. Die OSI erkennt sie deshalb nicht als Open Source an.

### Was passiert mit bestehenden Versionen, wenn ein Projekt seine Lizenz wechselt?

Sie bleiben unter ihrer alten Lizenz nutzbar, denn ein Lizenzwechsel gilt nicht rückwirkend. Künftige Updates können jedoch anderen Regeln folgen. Nach den Wechseln bei HashiCorp, Redis und Elastic entstanden die Forks OpenTofu, Valkey und OpenSearch. Projekte, die von einer neutralen Stiftung und mehreren Unternehmen getragen werden, sind gegen solche Kurswechsel besser geschützt als Projekte eines einzelnen Herstellers.

### Ist Terraform noch Open Source?

Nein, nach Stand der Recherche nicht. Im August 2023 kündigte HashiCorp an, künftige Versionen von Terraform unter der Business Source License 1.1 statt unter der MPL 2.0 zu veröffentlichen; eine Rückkehr zu einer Open-Source-Lizenz hat die Redaktion bis Redaktionsschluss nicht festgestellt. Als offene Alternative entstand der Fork OpenTofu, der im April 2025 als Sandbox-Projekt in die Cloud Native Computing Foundation aufgenommen wurde.

### Was ist eine SBOM und wofür braucht man sie?

Eine SBOM (Software Bill of Materials) ist eine maschinenlesbare Stückliste aller Softwarekomponenten samt Lizenz. Etablierte Formate sind SPDX und CycloneDX; viele Build-Werkzeuge erzeugen SBOMs automatisch. Die SBOM ist Grundlage der Lizenz-Compliance. Zudem verpflichtet der EU Cyber Resilience Act Hersteller von Produkten mit digitalen Elementen künftig unter anderem zur Erstellung einer SBOM; die meisten Pflichten gelten ab dem 11. Dezember 2027.

## Quellen

1. [Open Source Initiative – Liste anerkannter Lizenzen](https://opensource.org/licenses)
2. [HashiCorp – HashiCorp adopts Business Source License (10.08.2023)](https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license)
3. [IBM Newsroom – IBM completes acquisition of HashiCorp (27.02.2025)](https://newsroom.ibm.com/2025-02-27-ibm-completes-acquisition-of-hashicorp,-creates-comprehensive,-end-to-end-hybrid-cloud-platform)
4. [OpenTofu – OpenTofu is going GA (10.01.2024)](https://opentofu.org/blog/opentofu-is-going-ga/)
5. [CNCF – OpenTofu Projektseite](https://www.cncf.io/projects/opentofu/)
6. [Redis – Redis Adopts Dual Source-Available Licensing (20.03.2024)](https://redis.io/blog/redis-adopts-dual-source-available-licensing/)
7. [Redis – Redis is now available under the AGPLv3 open source license (01.05.2025)](https://redis.io/blog/agplv3/)
8. [Linux Foundation – Launch der Valkey-Community (28.03.2024)](https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community)
9. [Elastic – Licensing change (14.01.2021)](https://www.elastic.co/blog/licensing-change)
10. [Elastic – Elasticsearch is Open Source. Again! (29.08.2024)](https://www.elastic.co/blog/elasticsearch-is-open-source-again)
11. [Linux Foundation – Ankündigung der OpenSearch Software Foundation (16.09.2024)](https://linuxfoundation.org/press/linux-foundation-announces-opensearch-software-foundation-to-foster-open-collaboration-in-search-and-analytics)
12. [MongoDB – Server Side Public License](https://www.mongodb.com/legal/licensing/server-side-public-license)
13. [SPDX – Software Package Data Exchange](https://spdx.dev/)
14. [CycloneDX](https://cyclonedx.org/)
15. [Verordnung (EU) 2024/2847 (Cyber Resilience Act) – EUR-Lex](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)