Open Source ist überall -- verstehst du die Regeln?
Dein Startup nutzt React für das Frontend, Express für das Backend, PostgreSQL als Datenbank und dutzende npm-Pakete dazwischen. All das ist Open Source. Kostenlos. Aber nicht ohne Regeln.
Viele Gründerinnen und Gründer denken: Open Source heißt, ich darf alles damit machen. Das stimmt nicht. Jede Open-Source-Bibliothek steht unter einer bestimmten Lizenz, und diese Lizenz bestimmt, was du darfst und was nicht. Bei Startup Burgenland sehen wir immer wieder Startups, die kurz vor einer Investorenrunde feststellen, dass sie GPL-Code in ihrem proprietären Produkt haben -- und das kann richtig teuer werden.
Dieser Beitrag erklärt dir die wichtigsten Open-Source-Lizenzen, ihre Unterschiede und was du konkret tun musst, um compliant zu bleiben. Denn das Thema betrifft jedes Tech-Startup -- ausnahmslos.
Das Lizenz-Spektrum: Von permissiv bis Copyleft
Open-Source-Lizenzen lassen sich auf einem Spektrum von "sehr freizügig" bis "sehr restriktiv" einordnen. Das Verständnis dieses Spektrums ist der Schlüssel zum richtigen Umgang mit Open-Source-Software.
| Lizenz | Typ | Kommerzielle Nutzung | Copyleft | Risiko für Startups |
|---|---|---|---|---|
| MIT | Permissiv | Ja | Nein | Gering |
| BSD (2/3-Clause) | Permissiv | Ja | Nein | Gering |
| Apache 2.0 | Permissiv | Ja | Nein | Gering |
| ISC | Permissiv | Ja | Nein | Gering |
| LGPL 2.1/3.0 | Schwaches Copyleft | Ja (mit Bedingungen) | Teilweise | Mittel |
| MPL 2.0 | Schwaches Copyleft | Ja (mit Bedingungen) | Datei-basiert | Mittel |
| GPL 2.0/3.0 | Starkes Copyleft | Ja (mit Bedingungen) | Ja | Hoch |
| AGPL 3.0 | Stärkstes Copyleft | Ja (mit Bedingungen) | Ja, auch SaaS | Sehr hoch |
Die Grundregel: Je weiter rechts im Spektrum, desto mehr Pflichten hast du. Permissive Lizenzen lassen dir fast alle Freiheiten. Copyleft-Lizenzen fordern, dass du deine eigenen Änderungen unter der gleichen Lizenz weitergibst.
Die permissiven Lizenzen: MIT, BSD und Apache
MIT-Lizenz
Die MIT-Lizenz ist die populärste Open-Source-Lizenz überhaupt. Sie besteht aus wenigen Zeilen und ist extrem freizügig.
Was du darfst:
- Kommerziell nutzen, modifizieren, verbreiten, unterlizenzieren
- Den Code in proprietäre Software einbauen
- Den Code beliebig kombinieren
Was du musst:
- Den Copyright-Hinweis und den Lizenztext beibehalten
Was du nicht darfst:
- Den Autor haftbar machen
Das war's. Die MIT-Lizenz ist für kommerzielle Startups ideal. Du musst lediglich den Copyright-Hinweis irgendwo in deinem Produkt unterbringen -- in einer NOTICES-Datei, einem "Open Source"-Abschnitt in den Einstellungen oder in der Dokumentation. Kein Quellcode-Offenlegungspflicht, keine Einschränkungen bei der Verbreitung.
Apache 2.0
Die Apache-Lizenz ist ähnlich freizügig wie MIT, aber ausführlicher formuliert und enthält zwei wichtige Zusätze.
Unterschiede zu MIT:
- Explizite Patentlizenz: Contributor gewähren dir automatisch eine Lizenz an ihren Patenten, die den Code betreffen. Das schützt dich vor Patentklagen durch Contributor.
- Patent-Retaliationsklausel: Wenn du wegen Patenten klagst, die den Apache-Code betreffen, verlierst du automatisch die Patentlizenz.
- NOTICE-Datei: Änderungen müssen in einer NOTICE-Datei dokumentiert werden.
Für Startups in patent-sensitiven Branchen (Hardware, Biotech, Medizintechnik) ist Apache 2.0 die bessere Wahl als MIT. In den meisten Fällen sind beide aber gleichwertig unproblematisch.
BSD-Lizenzen
Die BSD-Lizenz gibt es in mehreren Varianten. Die 2-Clause BSD ist praktisch identisch mit MIT. Die 3-Clause BSD enthält eine zusätzliche "No-Endorsement"-Klausel: Du darfst den Namen des Projekts oder der Autoren nicht für Werbezwecke nutzen, ohne Genehmigung.
GPL: Der Copyleft-Effekt im Detail
Die GNU General Public License (GPL) verfolgt eine andere Philosophie als permissive Lizenzen: Software-Freiheit. Der "Copyleft"-Effekt bedeutet: Wenn du GPL-Code in deinem Produkt nutzt und das Produkt verbreitest, muss dein gesamtes Produkt unter GPL stehen -- und du musst den Quellcode veröffentlichen.
GPL 2.0 vs. GPL 3.0
| Aspekt | GPL 2.0 | GPL 3.0 |
|---|---|---|
| Copyleft | Ja | Ja |
| Patentlizenz | Implizit | Explizit |
| Tivoization-Schutz | Nein | Ja (Hardware muss modifizierbar sein) |
| Kompatibilität mit Apache 2.0 | Nein | Ja |
| Typische Projekte | Linux Kernel, viele ältere Projekte | Neuere GNU-Projekte |
Wann greift der Copyleft-Effekt?
Der entscheidende Punkt: Der Copyleft-Effekt greift bei Verbreitung (Distribution). Wenn du GPL-Software nur intern nutzt, aber nicht an Kunden weitergibst, musst du deinen Code nicht offenlegen. Das ist die sogenannte "private use exception".
| Szenario | Copyleft greift? | Erläuterung |
|---|---|---|
| GPL-Bibliothek in Desktop-App | Ja | Du verbreitest die App an Endnutzer |
| GPL-Bibliothek in Mobile App | Ja | Du verbreitest die App über den App Store |
| GPL-Tool auf deinem Server (intern) | Nein | Keine Verbreitung an Dritte |
| GPL-Bibliothek in SaaS-Backend | Nein | Keine Verbreitung, nur Zugriff über Netzwerk |
| AGPL-Bibliothek in SaaS-Backend | Ja! | AGPL schließt die SaaS-Lücke |
| Statisches Linking mit GPL-Code | Ja | Das Ergebnis ist ein "abgeleitetes Werk" |
| Dynamisches Linking mit LGPL-Code | Nein | LGPL erlaubt dynamisches Linking |
AGPL: Die SaaS-Falle
Die AGPL (Affero GPL) schließt die sogenannte "SaaS-Lücke" der GPL. Wenn du AGPL-Code auf einem Server nutzt und Nutzer über ein Netzwerk darauf zugreifen, gilt das als Verbreitung. Du musst dann den gesamten Quellcode deiner Anwendung veröffentlichen und unter AGPL stellen.
Für SaaS-Startups ist AGPL-Code ein echtes Problem. Wenn du eine AGPL-Bibliothek in deinem Backend verwendest, kann das bedeuten, dass du deinen gesamten Server-Code offenlegen musst. Das ist für die meisten kommerziellen SaaS-Startups inakzeptabel.
Typische AGPL-Projekte, die dir in der Praxis begegnen: MongoDB (ab Version 4.2 unter SSPL, davor teilweise AGPL), Grafana (Frontend), iText (PDF-Bibliothek), Nextcloud. Prüfe immer die Lizenz, bevor du eine Bibliothek einbindest.
LGPL und MPL: Die Mittelweg-Lizenzen
Zwischen permissiv und starkem Copyleft gibt es "schwache" Copyleft-Lizenzen, die einen Kompromiss bieten.
LGPL (Lesser GPL): Erlaubt dir, LGPL-Bibliotheken in proprietärer Software zu verwenden, solange du sie dynamisch linkst (als separate Bibliothek einbindest). Deine eigene Software muss nicht unter LGPL stehen. Aber wenn du die LGPL-Bibliothek selbst veränderst, musst du diese Änderungen unter LGPL veröffentlichen.
MPL 2.0 (Mozilla Public License): Arbeitet datei-basiert. Dateien unter MPL müssen unter MPL bleiben, aber du kannst sie mit proprietären Dateien in einem Projekt kombinieren. Weniger restriktiv als LGPL.
Für die meisten Startups sind LGPL und MPL beherrschbar -- solange du die Regeln kennst und einhältst.
Lizenzkompatibilität: Was passt zusammen?
Wenn du Code unter verschiedenen Lizenzen kombinierst, müssen die Lizenzen kompatibel sein. Hier die wichtigsten Regeln:
| Kombination | Kompatibel? | Ergebnis-Lizenz |
|---|---|---|
| MIT + MIT | Ja | MIT |
| MIT + Apache 2.0 | Ja | Apache 2.0 |
| MIT + GPL 3.0 | Ja | GPL 3.0 |
| Apache 2.0 + GPL 3.0 | Ja | GPL 3.0 |
| Apache 2.0 + GPL 2.0 | Nein | Inkompatibel |
| GPL 2.0 + GPL 3.0 | Nur wenn "or later" | GPL 3.0 |
| MIT + Proprietary | Ja | Proprietary (mit Hinweis) |
| GPL + Proprietary | Nein | Inkompatibel |
| AGPL + Proprietary | Nein | Inkompatibel |
Faustregel: Permissive Lizenzen sind mit fast allem kompatibel. GPL-Code "infiziert" alles, womit er kombiniert wird -- das kombinierte Werk muss unter GPL stehen. Proprietärer Code und GPL-Code lassen sich nicht in einem Programm mischen.
Compliance in der Praxis: Was du konkret tun musst
Schritt 1: Software Bill of Materials (SBOM) erstellen
Ein SBOM ist eine Inventarliste aller Software-Komponenten in deinem Produkt, inklusive ihrer Lizenzen und Versionen. Ohne SBOM hast du keine Übersicht und kannst keine Compliance-Aussage treffen.
Tools für die automatische SBOM-Erstellung:
| Tool | Sprache/Ökosystem | Kosten |
|---|---|---|
| license-checker (npm) | JavaScript/Node.js | Kostenlos |
| pip-licenses | Python | Kostenlos |
| Maven License Plugin | Java | Kostenlos |
| ScanCode Toolkit | Sprachunabhängig | Kostenlos (Open Source) |
| FOSSA | Alle Sprachen | Freemium |
| Snyk | Alle Sprachen | Freemium |
| Black Duck | Enterprise | Kostenpflichtig |
Schritt 2: Lizenzen kategorisieren
Teile alle gefundenen Lizenzen in drei Ampelkategorien ein:
- Grün (Permissiv): MIT, BSD, Apache, ISC -- unproblematisch, Copyright-Hinweis beibehalten
- Gelb (Schwaches Copyleft): LGPL, MPL -- prüfen, wie du die Bibliothek technisch einbindest
- Rot (Starkes Copyleft): GPL, AGPL -- genau prüfen, ob und wie du sie nutzt. Gegebenenfalls Alternative suchen
Schritt 3: Pflichten erfüllen
Für alle Open-Source-Lizenzen gilt mindestens:
- Copyright-Hinweise und Lizenztexte beibehalten und weitergeben
- In deinem Produkt zugänglich machen (NOTICES-Datei, About-Screen, Dokumentation)
- Bei Copyleft: Prüfen, ob du den Quellcode offenlegen musst
- Änderungen an Apache-lizenziertem Code in NOTICE-Datei dokumentieren
Schritt 4: Interne Open-Source-Policy etablieren
Erstelle eine Policy, die klar definiert:
- Welche Lizenztypen sind automatisch erlaubt (Grün)?
- Welche brauchen eine Prüfung vor Einbindung (Gelb)?
- Welche sind grundsätzlich verboten (Rot)?
- Wer entscheidet bei Zweifelsfällen?
- Wie wird das SBOM aktualisiert?
- Wie oft findet ein Audit statt?
Open Source und Investoren-Due-Diligence
Investoren achten bei der Due Diligence zunehmend auf Open-Source-Compliance. Typische Fragen, die du beantworten können musst:
- Habt ihr ein vollständiges und aktuelles SBOM?
- Nutzt ihr GPL- oder AGPL-Code in eurem Kernprodukt?
- Ist euer proprietärer Code sauber von Copyleft-Code getrennt?
- Habt ihr eine dokumentierte Open-Source-Policy?
- Gibt es Lizenz-Inkompatibilitäten in eurem Stack?
- Erfüllt ihr alle Attributionspflichten?
Wenn du diese Fragen nicht beantworten kannst, sinkt das Vertrauen -- und im schlimmsten Fall platzt der Deal oder die Bewertung wird reduziert. Mach die Compliance von Anfang an richtig, nicht erst vor der Funding-Runde.
Mehr zum Thema Urheberrecht an Software findest du in meinem Beitrag zum Urheberrecht für Software und Design.
Häufige Fehler im Umgang mit Open Source
Keine Lizenz prüfen, bevor du eine Bibliothek einbindest. Viele Entwickler installieren Pakete per npm install oder pip install, ohne die Lizenz zu lesen. Mach es zur Gewohnheit: Vor dem Einbinden die Lizenz auf GitHub oder im Package-Manager prüfen.
GPL-Code in proprietärer Desktop- oder Mobile-App. Das ist der Klassiker, der bei der Due Diligence auffliegt. Einmal eingebaut, musst du entweder deinen gesamten Code unter GPL stellen oder die GPL-Komponente durch eine Alternative unter permissiver Lizenz ersetzen.
Open-Source-Lizenzbedingungen ignorieren. Auch permissive Lizenzen haben Pflichten -- zumindest die Attribution (Copyright-Hinweis beibehalten). Wenn du keine NOTICES-Datei oder keinen Open-Source-Screen in deiner App hast, verletzt du die Lizenzbedingungen.
Eigenen Code ohne Lizenz veröffentlichen. Wenn du Code auf GitHub veröffentlichst, ohne eine Lizenzdatei beizufügen, ist der Code urheberrechtlich geschützt -- niemand darf ihn nutzen. Wähle bewusst eine Lizenz, wenn du Open Source beitragen willst.
Interne Forks von Open-Source-Projekten ohne Tracking. Wenn du einen Fork eines Open-Source-Projekts erstellst und intern weiterentwickelst, musst du die Lizenz des Originals weiterhin einhalten. Dokumentiere den Fork und seine Lizenz im SBOM.
Open Source und das österreichische Recht
In Österreich gibt es keine spezifische Gesetzgebung zu Open-Source-Lizenzen. Open-Source-Lizenzen werden als urheberrechtliche Lizenzverträge behandelt und unterliegen dem allgemeinen Vertragsrecht und dem UrhG.
Einige Besonderheiten im österreichischen Kontext:
- Haftungsausschlüsse in Open-Source-Lizenzen sind nach österreichischem Recht möglicherweise nicht in vollem Umfang wirksam. Die im anglo-amerikanischen Recht üblichen "AS IS"-Klauseln können nach österreichischem Verbraucherrecht eingeschränkt sein.
- Urheberrechtliche Zuordnung: Wenn deine Angestellten zu Open-Source-Projekten beitragen, gelten die Regeln des § 40b UrhG -- die Verwertungsrechte liegen beim Arbeitgeber. Stelle sicher, dass du als Arbeitgeber die Veröffentlichung unter einer Open-Source-Lizenz genehmigt hast.
- Contributor License Agreements (CLAs): Wenn du selbst ein Open-Source-Projekt betreibst, fordere von externen Contributors ein CLA, das dir die notwendigen Rechte zur Lizenzierung einräumt.
Dual Licensing: Open Source als Geschäftsmodell
Viele erfolgreiche Unternehmen nutzen Open Source strategisch: Sie bieten ihren Code unter einer Open-Source-Lizenz (oft AGPL oder GPL) an und verkaufen gleichzeitig kommerzielle Lizenzen an Unternehmen, die den Copyleft-Effekt vermeiden wollen.
Beispiele: MySQL (GPL + kommerzielle Lizenz), Qt (LGPL + kommerzielle Lizenz), GitLab (MIT für CE, proprietär für EE). Wenn du selbst eine Bibliothek oder ein Tool entwickelst, kann Dual Licensing ein interessantes Geschäftsmodell sein. Voraussetzung: Du musst alle Urheberrechte am Code halten -- deshalb sind saubere Contributor License Agreements (CLAs) wichtig.
Das Open-Core-Modell ist eine Variante: Die Basis-Version ist Open Source (oft MIT oder Apache), Premium-Features sind proprietär. GitLab, Grafana und viele andere nutzen dieses Modell erfolgreich. Es kombiniert Community-Wachstum mit kommerziellem Umsatz.
Mehr zu Lizenzmodellen und strategischen Überlegungen zur Monetarisierung von IP findest du in meinem Beitrag zu Lizenzmodellen für Startups.
Mehr zu Lizenzmodellen und IP-Monetarisierung findest du in meinem Beitrag zu Lizenzmodellen für Startups.
So gehst du jetzt weiter
Erstelle jetzt ein SBOM für dein Projekt. Nutze license-checker (npm), pip-licenses (Python) oder ScanCode und kategorisiere alle Lizenzen in Grün, Gelb und Rot. Wenn du GPL- oder AGPL-Code findest, prüfe sofort, ob das mit deinem Geschäftsmodell kompatibel ist. Suche bei Bedarf nach Alternativen unter permissiven Lizenzen.
Und für den großen Überblick: Die IP-Strategie von Anfang an zeigt dir, wie Open-Source-Compliance in deine gesamte IP-Planung passt.
Und wenn du dein geistiges Eigentum umfassend schützen willst, lies den Beitrag zu Geschäftsgeheimnissen -- denn dein proprietärer Code sollte ebenso sorgfältig geschützt sein wie deine Open-Source-Compliance.
Wenn du gerade erst anfängst, dich mit dem Thema zu beschäftigen, starte mit diesen drei Schritten: Erstens, installiere ein SBOM-Tool. Zweitens, kategorisiere alle Lizenzen in Grün, Gelb und Rot. Drittens, ersetze alle Rot-Komponenten durch Alternativen unter permissiven Lizenzen. Das dauert einen Nachmittag und erspart dir monatelange Probleme.
Open-Source-Compliance mag auf den ersten Blick wie eine lästige Pflicht wirken. Aber richtig umgesetzt ist sie ein Qualitätsmerkmal deines Startups -- und ein positives Signal an Investoren, Kunden und Partner. Sie zeigt, dass du professionell arbeitest und Risiken proaktiv managst.
Denke auch an die Community: Wenn du von Open Source profitierst, überlege, ob du selbst etwas zurückgeben kannst. Ein Pull Request, ein Bug Report oder ein finanzieller Beitrag zu den Projekten, die du nutzt, stärkt das Ökosystem -- und baut Goodwill in der Developer-Community auf.
Bei Startup Burgenland helfen wir dir, Open-Source-Risiken frühzeitig zu erkennen und die richtigen Entscheidungen zu treffen. Unsere Netzwerk-Anwälte und Tech-Coaches stehen dir zur Seite.
Startup Burgenland macht Gründung leistbar: EUR 10.000 Gründungszuschuss (nicht rückzahlbar, keine Eigenkapitalabgabe), 1:1 Coaching und ein Netzwerk aus Steuerberatern, Notaren und Rechtsanwälten. Flexibler Einstieg jederzeit. Schreib uns ein formloses E-Mail.
Über den Autor: Felix Lenhard ist Program Director und Startup Coach bei Startup Burgenland. Zuvor Managing Director beim 360 Innovation Lab, Innovation Manager bei RHI Magnesita und Serial Entrepreneur mit internationalen Exits. Über 15 Jahre Erfahrung in Innovation und Unternehmensaufbau.