Open Source

Was bedeutet Open Source für KI-Tools?

Open-Source-Software veröffentlicht Quellcode unter einer Lizenz, die Inspektion, Modifikation und (meist) Weiterverbreitung erlaubt. Bei KI-Tools können Sie lesen, wie Prompts, Logs und Credentials behandelt werden, das Produkt an Ihren Stack anpassen und es ohne Warten auf eine Cloud-Region des Anbieters betreiben.

Open Source ist nicht dasselbe wie kostenlos im Sinne von „free beer“, und nicht dasselbe wie self-hosted. Ein Apache-lizenziertes Projekt kann Sie trotzdem zu einer bezahlten gehosteten Control Plane drängen. Ein proprietäres Appliance kann self-hosted mit Lizenzschlüssel sein. Lesen Sie die Lizenzdatei und den Standard-Telemetriepfad, nicht das Marketingwort „open“.

Warum KI-Teams das wichtig finden

Prüfbarkeit. Ingenieure sehen Code, der Kundengespräche berührt — wichtig in Healthcare, Finance und Legal.

Anpassung. Geschlossene Produkte begrenzen Patches. Open Tools erlauben Auth, Retention, Modell-Routing und Integrationen nach Ihrem Zeitplan.

Kein Single-Vendor-Kill-Switch. Proprietäre APIs werden abgeschaltet. Sie können einen Git-Tag pinnen, forken oder eine alte Release weiterbetreiben.

Community-Tempo. Aktive Projekte bekommen oft schneller Security-Fixes und Adapter (LangChain, Kubernetes-Charts) als eine geschlossene Roadmap öffentlich zugibt.

Lizenzen, die Sie wirklich treffen

• MIT — Sehr permissiv. Copyright-Hinweis behalten. Kommerzielle Nutzung normal.
• Apache 2.0 — Permissiv plus ausdrückliche Patentgewährung. Üblich in enterprise-freundlicher KI-Infrastruktur.
• GPL v3 — Copyleft: Modifizierte Binaries weitergeben bedeutet meist Quellcode unter GPL.
• AGPL v3 — Copyleft, das viele Netzwerk-/SaaS-Deployments erreicht. Legal Review vor internem Produkt.
• Source-available / BSL / Open Core — Code lesbar, Rechte evtl. nicht wie gedacht. Nicht OSI-open bis Counsel zustimmt.

Open-Source-KI-Tool bewerten

1. Lizenzkompatibilität mit Ihrer Auslieferung (intern, SaaS, On-Prem).
2. Wer merged: Firma, Stiftung oder ein Maintainer ohne Backup.
3. Release-Kadenz, signierte Artefakte, Security-Kontakt.
4. Produktions-Docs: Compose/Helm, Backups, Upgrades, was nach Hause telefoniert.
5. Ob „open“ Trainingsdaten, Eval-Sets, Agent-Runtime oder nur einen dünnen Client umfasst.
6. Dual Licensing: welche Features hinter kommerzieller SKU.

Risiken

Ungepflegte Repos verrotten. AGPL in einem produktisierten Service kann ungeplante Source-Offenlegung erzwingen. „Open weights“ sind nicht dieselbe offene Anwendung. Crash-Reports und Lizenzchecks können Traces exfiltrieren. Forks ohne Maintainer-Plan werden Ihr On-Call.

Häufige Fragen

Wenn es auf GitHub ist, ist es Open Source?

Nur mit anerkannter Open-Source-Lizenz und wenn Sie die lizenzierten Dateien nutzen. „All rights reserved“ ist kein Open Source.

Apache-2.0-Code in kommerziellem Produkt?

Meist ja, auch in Closed Source, wenn Notice-/NOTICE-Bedingungen erfüllt sind. Counsel für Patente/Marken.

Müssen wir Modifikationen veröffentlichen?

Unter MIT/Apache 2.0 für typische interne oder SaaS-Nutzung meist nein. GPL/AGPL anders. Lizenz lesen vor Redistribution oder Netzwerkdienst.

Ist Open Source automatisch sicherer?

Nein. Sichtbarkeit hilft wenn jemand liest und patcht. Verlassenes Public Repo kann schlechter sein als Vendor mit Security-SLA.

Bezug zu Self-Hosted?

Open Source macht Self-Hosting möglich. Es betreibt den Cluster nicht für Sie. Siehe Tag Self-Hosted.