Guide zum Software-Lizenz-Dschungel
Du hast Nächte durchgemacht, Literweise Kaffee getrunken und endlich funktioniert dein Tool. Stolz pushst du es auf GitHub. Alles super, oder?
Fast
Wenn du keine Lizenz hinzufügst, ist dein Code rechtlich gesehen „nackt“. Das bedeutet: Jeder darf ihn zwar anschauen (weil GitHub öffentlich ist), aber niemand darf ihn benutzen, verändern oder verbreiten. Dein geniales Skript ist rechtlich nutzlos für die Welt.
Aber wer hat schon Lust, 40-seitige EULAs zu lesen? Keine Sorge, für Hobby-Entwickler gibt es im Grunde nur drei Pfade, die 95% aller Fälle abdecken. Wir werfen den rechtlichen Jargon über Bord und schauen uns an, was du wirklich wissen musst.
1. Die „Mach-doch-was-du-willst“-Lizenz: MIT
Die MIT-Lizenz ist der absolute Klassiker auf GitHub. Sie ist so kurz, dass sie auf eine Postkarte passt. Wenn sie sprechen könnte, würde sie sagen: „Hier ist der Code. Nutz ihn, änder ihn, verkauf ihn, tanz damit Samba. Mir egal. Nenn einfach meinen Namen und verklag mich nicht, wenn er deinen Rechner in Brand setzt.“
Die nackten Fakten:
- Art: Extrem permissiv (freizügig).
| Vorteile | Nachteile |
| Super einfach: Jeder versteht sie sofort. | Null Schutz: Jemand kann deinen Code nehmen, leicht verändern und als teures Closed-Source-Produkt verkaufen. |
| Maximale Verbreitung: Firmen lieben MIT-Code, weil sie keine rechtlichen Risiken eingehen. | Du hast keinen Einfluss darauf, was mit Ableitungen passiert. |
Bekannte Projekte:
- React (Das UI-Framework von Meta, das halbe Web läuft damit).| Node.js (Damit JavaScript auch auf dem Server läuft).
2. Der „Sicherheits-Gurt“: Apache 2.0
Apache 2.0 ist wie die MIT-Lizenz, aber mit einem Anwalt im Schlepptau. Sie ist ebenfalls permissiv, aber rechtlich viel präziser.
Der wichtigste Unterschied: Sie enthält eine explizite Patentklausel. Das bedeutet: Wenn du deinen Code veröffentlichst, gibst du jedem Nutzer automatisch das Recht, etwaige Patente, die du auf diesen Code hast, kostenlos zu nutzen. Gleichzeitig schützt sie dich: Wenn dich jemand wegen Patentverletzung verklagt, verliert er sofort das Recht, deine Software zu nutzen.
Die nackten Fakten:
- Art: Permissiv mit rechtlichem Airbag.
| Vorteile | Nachteile |
| Rechtssicher: Schützt dich (und Nutzer) vor ekligen Patent-Trollen. | Längerer Text: Liest sich nicht ganz so flockig wie die MIT. |
| Firmenfreundlich: Wird oft für professionelle Open-Source-Software genutzt. | Etwas komplexer in der Handhabung, wenn man es korrekt machen will. |
Bekannte Projekte:
- Android (Das Betriebssystem, das auf den meisten Handys läuft).| Kubernetes (Das Ding, mit dem Firmen ihre Container-Anwendungen verwalten).
3. Die „Geben und Nehmen“-Lizenz (oder: Der Virus): GNU GPLv3
Die GPL ist der „Bad Boy“ unter den Lizenzen. Sie verfolgt ein ideologisches Ziel: Software muss dauerhaft frei bleiben. Wenn du GPL-Code nutzt und dein Projekt veröffentlichst, greift der „virale Effekt“: Dein gesamtes Projekt muss ebenfalls unter der GPLv3 stehen.
Unternehmen hassen die GPL. Sie haben Angst, dass sie versehentlich GPL-Code in ihre geheime Software kopieren und dann ihren gesamten Quellcode offenlegen müssen. Für Community-Projekte ist sie aber genial, um sicherzustellen, dass Verbesserungen der Allgemeinheit zugute kommen.
(Randnotiz: Es gibt auch die LGPL, die ist wie GPL-Light für Bibliotheken. Sie erlaubt das Einbinden in kommerzielle Software, aber Änderungen an der Bibliothek selbst müssen offenbleiben.)
Die nackten Fakten:
- Art: Starkes Copyleft (virale Weitergabe).
| Vorteile | Nachteile |
| Freiheit garantiert: Dein Code und alle Ableitungen bleiben für immer Open Source. | Geringere Verbreitung: Firmen meiden GPL-Code wie die Pest. |
| Community-Schutz: Verhindert, dass Konzerne deinen Code „klauen“ und einsperren. | Der rechtliche Text ist sehr lang und komplex. |
Bekannte Projekte:
- Linux Kernel (Ok, der nutzt GPLv2, aber das Prinzip ist ähnlich).| VLC Media Player (Der spielt alles ab, danke GPL).
Der Schnell-Vergleich für deine LICENSE-Datei
Du hast immer noch keine Lust zu lesen? Hier ist die Spickzettel-Matrix, um schnell zu entscheiden.
| Feature | MIT | Apache 2.0 | GNU GPLv3 |
| Ist locker drauf? | Ja | Geht so | Nein |
| Erlaubt kommerzielle Nutzung? | Ja | Ja | Ja (aber…) |
| Muss Code offengelegt werden? | Nein | Nein | Ja (viral) |
| Patent-Schutz? | Nein | Ja | Ja |
| Bester Kumpel für Firmen? | Ja | Ja | Nein, eher nicht |
Fazit: Die 2-Sekunden-Entscheidung
Welche soll es jetzt sein? Mach es dir nicht zu schwer. Als Hobby-Entwickler auf GitHub lautet die Faustregel:
- Im Zweifel: Nimm MIT. Damit machst du nichts falsch und die meisten Leute nutzen es gerne.
- Du hast Angst vor Patenten/willst es professioneller? Nimm Apache 2.0.
- Du willst, dass deine Verbesserungen für immer frei bleiben? Nimm GPLv3.
Und wie fügst du sie hinzu? Klick auf GitHub auf „Add file“, tipp „LICENSE“ ein und GitHub bietet dir an, ein Template auszuwählen. 3 Klicks, und dein Code ist nicht mehr nackt.