Neulich hatte ich ein Problem in Sachen Open-Source-Lizenzen, das mich echt nicht schlafen ließ.
Ich musste für ein Kundenprojekt sensible Daten aus PDFs schwärzen. PyMuPDF wäre perfekt gewesen – mächtig, zuverlässig, super dokumentiert.
Dumm nur: Das Ding läuft unter AGPL-Lizenz.
Meine erste Reaktion? „Müssen wir jetzt etwa unseren ganzen Code veröffentlichen?“ Keine Ahnung.
Wie wahrscheinlich die meisten Entwickler hatte ich jahrelang einfach MIT-Lizenzen in meine Projekte gepackt, ohne mir groß Gedanken zu machen, was die eigentlich bedeuten oder was es sonst noch gibt.
Diese Situation hat mich gezwungen, mich richtig mit Software-Lizenzen auseinanderzusetzen – und ehrlich gesagt war ich überrascht, was ich dabei gelernt habe.
Falls du auch schon mal vor einer Open-Source-Bibliothek gestanden hast und dir unsicher warst, ob du sie wegen der Lizenz verwenden darfst, ist dieser Artikel für dich.
Die zwei Welten: Permissive vs. Copyleft
Open-Source-Lizenzen lassen sich grob in zwei Lager einteilen: permissive (freizügig) und copyleft.
Den Unterschied zu kennen ist wichtig.
Permissive Lizenzen (MIT, BSD, Apache) geben dir alle Freiheiten. Du kannst den Code in kommerzieller Software verwenden, ändern wie du willst, und musst nichts zurückgeben.
Einzige Bedingung: Du musst den ursprünglichen Autor nennen.
Copyleft-Lizenzen (GPL, AGPL) haben einen Haken: Wenn du die Software weitergibst (oder bei AGPL: über ein Netzwerk anbietest), musst du deinen Quellcode unter der gleichen Lizenz veröffentlichen. Die Idee dahinter: Freie Software soll frei bleiben.
AGPL: Schlimmer als ihr Ruf?
Die GNU Affero General Public License (AGPL) hat in Unternehmen einen ziemlich miesen Ruf.
Ich kenne Entwickler, die AGPL-Code sofort ablehnen, ohne genau zu wissen warum (ich gehörte auch dazu).
Was AGPL wirklich verlangt: Wenn du AGPL-Software änderst und über ein Netzwerk anbietest, musst du den Nutzern den Quellcode zur Verfügung stellen.
Wichtig ist, was da nicht steht:
- „Veröffentliche deinen Code auf GitHub“
- „Mach dein ganzes Projekt Open Source“
- „Zeig deinen Code der ganzen Welt“
Der entscheidende Punkt: „Nutzer“ sind die Leute, die deine Software tatsächlich benutzen – nicht irgendwer im Internet!
Das war für mich der Aha-Moment.
Interne Tools? Kein Problem
Dieser Unterschied ist mega wichtig für interne Anwendungen.
Wenn du eine Webanwendung für deine Firma mit AGPL-Komponenten baust, ist das meistens unkritisch.
Die Nutzer sind deine Kollegen, und die können theoretisch den Quellcode anfordern. Aber da die Firma den Code eh besitzt, ist das kein Problem.
Laut Snyk’s AGPL Compliance Guide löst rein interne Nutzung normalerweise keine Offenlegungspflicht nach außen aus.
Wann AGPL zum Problem wird
AGPL wird kompliziert, wenn du:
- Ein SaaS-Produkt verkaufen willst – Deine Kunden können dann den Quellcode verlangen
- Den Code geheim halten willst – Geht nicht, Nutzer haben ein Recht auf den Code
- Software verkaufst oder verteilst – Dann greifen die Copyleft-Regeln voll
Permissive Lizenzen: Mach was du willst
Schauen wir uns die drei wichtigsten permissiven Lizenzen an:
MIT-Lizenz
Die MIT-Lizenz ist der Klassiker. Super simpel:
- Copyright-Hinweis drin lassen
- Lizenztext mitliefern
- Fertig
Du kannst den Code kommerziell nutzen, ändern, und musst nichts zurückgeben.
React, Node.js, Rails – alle MIT. Die beliebteste Lizenz auf GitHub.
BSD-3-Clause
BSD-3-Clause ist quasi MIT plus eine Kleinigkeit: Du darfst den Namen des Autors nicht für Werbung missbrauchen.
Heißt: Wenn du eine BSD-3-Bibliothek namens „FastPDF“ nutzt, darfst du nicht behaupten, dein Produkt sei „offiziell von FastPDF“ oder sowas.
In der Praxis juckt das niemanden, außer du machst was Unseriöses.
Apache 2.0
Apache 2.0 ist die Deluxe-Version der permissiven Lizenzen.
Alles was MIT und BSD bieten, plus expliziter Patentschutz.
Warum das wichtig ist: Stell dir vor, jemand patentiert einen Algorithmus, schreibt Code dafür und lizenziert ihn unter MIT. Du nutzt den Code. Später verklagt dich der Typ wegen Patentverletzung.
MIT schützt dich nicht – nur vor Urheberrechtsklagen, nicht vor Patentklagen.
Apache 2.0 gibt dir explizit Patentrechte. Deshalb nutzen Kubernetes, Android und Co. diese Lizenz.
Kann man dich wirklich verklagen?
Die Frage, die mich am meisten beschäftigt hat.
Kurze Antwort: Theoretisch ja, praktisch eher unwahrscheinlich.
Software-Lizenzen sind rechtlich bindend. Verstöße können zu Klagen führen.
Aber: Nur der Urheberrechtsinhaber kann klagen. Nicht irgendeine „Open-Source-Polizei“ (gibt’s nicht), nicht irgendwelche Aktivisten, nicht andere Entwickler.
Bei AGPL ist die Durchsetzung bei internen Tools extrem selten, weil:
- Niemand sieht, was auf deinen Servern läuft
- Rechteinhaber gehen eher gegen große kommerzielle Verstöße vor
- Die meisten Fälle werden außergerichtlich geklärt
- Klagen sind teuer und aufwändig
Heißt aber nicht, dass das Risiko null ist. Wenn du ein kommerzielles SaaS mit AGPL-Code baust und Kunden keinen Zugang zum Quellcode gibst, wird’s gefährlich.
Wie entscheidest du dich?
Als ich mich für oder gegen PyMuPDF (AGPL) entscheiden musste, habe ich mir diese Fragen gestellt:
1. Nur für interne Nutzung?
- Nur intern → AGPL wahrscheinlich okay
- Kommerzielles Produkt → Lieber permissive Lizenz
2. Können Nutzer den Code anfordern?
- Ja, kein Problem → AGPL geht klar
- Nein, muss geheim bleiben → Permissive Lizenz
3. Ist die Funktionalität den Aufwand wert?
- Ja, keine Alternative → AGPL in Kauf nehmen
- Nein, gibt Alternativen → Permissive Option
4. Wie risikoscheu ist der Kunde?
- Sehr (Bank, Behörde) → Die wollen oft keine AGPL
- Normal → Erklären und gemeinsam entscheiden
In meinem Fall haben wir PyMuPDF (AGPL) genommen, weil:
- Nur interne Nutzung
- Kunde besitzt den Code eh
- Echte PDF-Schwärzung war sicherheitskritisch
- Keine Kommerzialisierungspläne
Schnellübersicht
| Was geht? | MIT | BSD-3 | Apache 2.0 | AGPL |
|---|---|---|---|---|
| Kommerziell nutzen | ✅ | ✅ | ✅ | ✅ (mit Bedingungen) |
| Code ändern | ✅ | ✅ | ✅ | ✅ |
| Geheim halten | ✅ | ✅ | ✅ | ❌ (nicht für Nutzer) |
| Patentschutz | ❌ | ❌ | ✅ | ✅ |
| Änderungen teilen | ❌ | ❌ | ❌ | ✅ (mit Nutzern) |
| Namen für Werbung | ✅ | ❌ | ❌ | ❌ |
Was ich gelernt habe
Nach allem Recherchieren und Nachfragen – das hätte ich gerne vorher gewusst:
- Lizenz checken, bevor du codest – Nicht erst wenn’s schon integriert ist
- AGPL ≠ „alles veröffentlichen“ – Gilt nur für tatsächliche Nutzer
- Interne Nutzung ist safe – Durchsetzung fokussiert sich auf kommerzielle Fälle
- Dokumentier deine Entscheidung – Falls später Fragen kommen
Nützliche Links
- Choose a License – GitHubs Tool zur Lizenzauswahl
- TLDRLegal – Lizenzen in verständlich
- Open Source Initiative – Offizielle Lizenztexte
- FOSSA License Guide – Details zu AGPL
Fazit
Software-Lizenzen sind kein Hexenwerk.
Man muss nur verstehen, was sie wirklich verlangen – nicht was man befürchtet, dass sie verlangen.
AGPL ist nicht so schlimm wie ihr Ruf, vor allem bei internen Tools.
Permissive Lizenzen geben dir alle Freiheiten, aber keinen Patentschutz (außer Apache 2.0).
Und das Wichtigste: Nur Rechteinhaber können klagen, das praktische Risiko ist viel kleiner als das theoretische.
Wenn du das nächste Mal eine Library evaluierst: Schau nicht nur auf Features und Performance. Nimm dir fünf Minuten für die Lizenz. Dein zukünftiges Ich wird’s dir danken.
Disclaimer: Keine Rechtsberatung. Bei konkreten rechtlichen Fragen zu einem Anwalt gehen.