Cal.com schließt seinen Code: Warum das KI-Sicherheitsargument nicht trägt

Cal.com hat seinen kommerziellen Code geschlossen und die AGPL-3.0-Lizenz gegen eine proprietäre Lizenz eingetauscht. CEO Bailey Pumfleet begründet das mit KI-bedingten Sicherheitsrisiken – „Open Source ist tot", sagt er. Das ist eine These, die auf einem Argument beruht, das bereits in den 1990er Jahren gründlich widerlegt wurde. Und der Zeitpunkt ist kein Zufall: Der Lizenzwechsel erfolgte, nachdem das Produkt profitabel geworden ist. Was als Sicherheitsdebatte verpackt wird, ist in Wirklichkeit eine klassische Monetarisierungsentscheidung – und die Entwickler-Community durchschaut das.

Das Argument, das Pumfleet gegenüber Journalisten vorbrachte, klingt auf den ersten Blick plausibel: KI-Angreifer nutzen die Transparenz von Open-Source-Code aus. Er vergleicht offenen Code damit, „den Bauplan eines Banktresors auszuhändigen, während gleichzeitig 100-mal mehr Hacker diesen Bauplan studieren." Das klingt gefährlich. Es ist aber kein neues Argument – und es ist falsch.

Ein uraltes Argument in neuem KI-Gewand

„Security through Obscurity" – Sicherheit durch Verborgenheit – ist ein Konzept, das die Sicherheitsforschung seit Jahrzehnten ablehnt. Das Prinzip dahinter: Ein System ist nicht sicherer, weil niemand seinen Aufbau kennt. Es ist sicherer, wenn es robust gegen bekannte Angriffe ist. Greg Kroah-Hartman, einer der wichtigsten Maintainer des Linux-Kernels, hat auf genau dieses Argument reagiert: Es war in den 90er Jahren falsch, und es ist heute falsch.

Die empirische Evidenz gibt ihm Recht. Fast der gesamte kommerzielle Code, der heute in Produktion läuft, basiert auf Open-Source-Komponenten. Betriebssysteme, Webserver, Datenbankschichten, Kryptographie-Bibliotheken – der Kern dieser Infrastruktur ist offen einsehbar, von Tausenden Forschern geprüft und kontinuierlich verbessert worden. Wenn offener Code automatisch unsicherer wäre, wäre die gesamte globale IT-Infrastruktur längst kollabiert. Sie ist es nicht.

Pumfleets Argumentationslinie ist deshalb so schwach, weil sie einen kausalen Zusammenhang behauptet, der nicht existiert: dass das Offenlegen von Code Angreifer bevorzugt. Tatsächlich bevorzugt es Verteidiger. Wer Fehler findet und meldet, ist meistens kein Angreifer – sondern ein Forscher, ein Maintainer, ein Nutzer mit Interesse an stabiler Software.

Die OSSRA-Zahlen: Bedrohlich, aber differenziert zu lesen

Es wäre unehrlich, den Kontext komplett wegzulassen. Black Ducks Open Source Security and Risk Analysis (OSSRA) für 2026 dokumentiert einen Anstieg von 107 Prozent bei Open-Source-Schwachstellen pro Codebase. Jason Schmitt, CEO von Black Duck, bringt es auf den Punkt: Die Geschwindigkeit, mit der Software heute entwickelt wird, übersteigt die Fähigkeit vieler Organisationen, sie abzusichern.

Das ist ein reales Problem – aber es ist kein Argument gegen Open Source. Es ist ein Argument gegen schlechtes Security-Management. Der Anstieg an dokumentierten Schwachstellen hat mehrere Ursachen:

• Mehr Codebase durch beschleunigte KI-gestützte Entwicklung
• Bessere Erkennungstools, die vorher unsichtbare Lücken sichtbar machen
• Größere Abhängigkeit auf immer mehr externe Bibliotheken
• Wachsende Angriffsfläche durch Microservice-Architekturen

Keiner dieser Faktoren wird durch proprietäre Lizenzierung beseitigt. Ein geschlossener Codebase hat dieselben Lücken – er hat nur weniger Augen, die sie finden. Das ist das Gegenteil von Sicherheit.

Tokens statt Eyeballs: Die neue Sicherheitslogik

Tech-Stratege Drew Breunig hat die Verschiebung durch KI präzise formuliert: Code-Sicherheit ist zu einer Gleichung geworden. Um ein System zu härten, muss man mehr Tokens für das Auffinden von Exploits ausgeben, als Angreifer für deren Ausnutzung aufwenden werden. Das ist eine Neuformulierung von Linus's Law – „given enough eyeballs, all bugs are shallow" – für das KI-Zeitalter.

Dieser Gedanke ist entscheidend, weil er zeigt, wo Open Source strukturell im Vorteil ist. Simon Willison, Mitgründer von Django, zieht daraus eine klare Schlussfolgerung: Da Security-Exploits heute durch Token-Ausgaben gefunden werden können, ist Open Source wertvoller geworden. Open-Source-Bibliotheken können dieses Audit-Budget teilen – jede Organisation, die die Bibliothek nutzt, profitiert von den Sicherheitsprüfungen aller anderen. Proprietäre Software muss all diese Kosten alleine tragen, im Verborgenen, ohne externe Prüfung.

Das ist keine idealistische Argumentation. Es ist eine ökonomische. Wer in einer Welt, in der KI-gestützte Sicherheitsanalyse skaliert, den Code schließt, zieht sich aus einem kollektiven Sicherheitsnetz zurück und trägt die Last allein. Cal.com hat sich damit möglicherweise nicht sicherer gemacht – sondern teurer.

Was GPT-5.4-Cyber mit „Security by Obscurity" macht

Es gibt einen weiteren, besonders ungemütlichen Aspekt der Cal.com-Entscheidung. Peter Steinberger, Creator von OpenClaw, hat darauf hingewiesen: GPT-5.4-Cyber ist in der Lage, Closed-Source-Binaries zu reverse-engineeren und in lesbaren Quellcode zurückzuverwandeln. OpenAI selbst behauptet, das Modell könne Binaries zu Source Code dekompilieren. Wenn das stimmt – und die Fähigkeiten aktueller Modelle sprechen dafür –, dann ist „Security by Obscurity" nicht nur theoretisch überholt, sondern praktisch hinfällig.

Der Schritt, den Code zu schließen, schützt also nicht vor KI-gestützten Angriffen. Er reduziert lediglich die Zahl der Menschen, die zur Verteidigung beitragen können, während die Angriffswerkzeuge dieselben bleiben. Das ist ein schlechter Trade-off.

Auf Slashdot brachte es ein Kommentar treffend auf den Punkt: Wenn die Tools so gut sind, dass man befürchtet, sie werden die eigenen Sicherheitslücken aufdecken – dann sollte man diese Tools nutzen, um die Lücken selbst zu finden und zu schließen. Nicht den Code schließen und das Problem ignorieren. Mehrere Reddit-Nutzer wiesen zudem darauf hin, dass Cal.coms eigene Security-History keine Empfehlung ist: Vergangene Schwachstellen seien nicht das Ergebnis sophistizierter Angriffe gewesen, sondern fundamentaler Fehler in Authentifizierung und Access Control.

Was dagegen spricht: KI als echte Belastung für kleine Maintainer

Es wäre unredlich, die realen Herausforderungen von KI für Open Source komplett wegzureden. Es gibt ein ernst zu nehmende Problem, das nichts mit Cal.coms Argumentation zu tun hat, aber dennoch existiert: die Überflutung kleiner Open-Source-Projekte mit KI-generierten Bug-Reports und Pull Requests.

Anthropics Modell-Varianten werden bereits jetzt mit der Befürchtung verknüpft, Maintainer kleinerer Projekte in einer Flut automatisierter Berichte zu ertränken. Das ist ein Kapazitätsproblem, kein Sicherheitsproblem im Sinne von Pumfleets Argumentation – aber es ist real. Projekte wie Jellyfin haben bereits explizite KI-Policies eingeführt, weil minderwertige KI-generierte Beiträge den Review-Prozess belasten.

Was wirklich in Produktion wächst: Der stille Gegenbeweis

Während Cal.com Schlagzeilen macht, läuft im Hintergrund ein weitaus unspektakulärerer, aber aufschlussreicherer Prozess ab. Produktionskritische Open-Source-Infrastruktur wächst. Petabridge dokumentiert für zentrale Libraries wie React, Akka.NET und NServiceBus ein jährliches Wachstum zwischen 35 und 126 Prozent. Diese Zahlen sind kein Zufall: Sie spiegeln das Vertrauen wider, das Unternehmen in Systeme investieren, die über Jahre in Produktionsumgebungen gereift sind.

Was KI nicht replizieren kann, ist das institutionelle Gedächtnis eines Jahrzehnts an Produktions-Deployments. Ein von KI generierter Fork eines etablierten Open-Source-Projekts mag syntaktisch korrekt sein – er fehlt die Millionen von Edge-Case-Fixes, die Community-Diskussionen und die tiefe Integration in bestehende Ökosysteme. Genau das macht diese Libraries wertvoll, und genau das schützt sie vor Substitution.

Das Tailwind-Beispiel verdeutlicht den Unterschied zwischen einem Geschäftsmodell-Kollaps und einem Open-Source-Kollaps: Das Tailwind-Geschäftsmodell, das auf steilen Lernkurven und Premium-Templates basierte, geriet durch KI-gestützte Alternativen unter Druck. Die zugrundeliegende Tailwind-CSS-Bibliothek selbst gedeiht weiterhin. Wer beides in einen Topf wirft, verwechselt Produkt-Strategie mit Technologie-Schicksal – ein Fehler, den auch Pumfleet macht.

Für DACH-Unternehmen, die eigene Open-Source-Abhängigkeiten managen, bedeutet das konkret: Der Reifegrad einer Library ist ein robusteres Sicherheitsmerkmal als ihre Lizenzform. Ein gut gepflegtes, aktiv auditiertes Open-Source-Projekt schlägt eine proprietäre Black Box, deren interne Security-Prozesse nicht einsehbar sind. Die Frage sollte nicht lauten „Open Source oder proprietär?", sondern „Wie aktiv ist die Maintainer-Community, wie schnell werden CVEs gepatcht, und wie transparent ist der Prozess?"

So What? Was das für DACH-Entscheider bedeutet

Für Unternehmen im DACH-Raum, die KI in ihre Softwareentwicklung integrieren und dabei auf Open-Source-Komponenten setzen, liefert Cal.coms Entscheidung eine nützliche Lektion – aber eine andere, als Pumfleet beabsichtigt hat. Der Fall zeigt, was passiert, wenn ein Unternehmen Security-Rhetorik nutzt, um eine Monetarisierungsentscheidung zu legitimieren. Die Entwickler-Community erkennt das, und das Reputationsrisiko ist real.

Der EU AI Act ist in diesem Zusammenhang relevant: Seit August 2025 gelten GPAI-Regeln und Governance-Anforderungen. Ab August 2026 greift der Hauptteil des Regelwerks, inklusive Hochrisiko-KI-Anforderungen. Wer KI-gestützte Sicherheitsanalyse einsetzt – sei es für eigene Codebasen oder als Teil von Produkten –, muss die Transparenz- und Dokumentationspflichten im Blick behalten. Open-Source-Ansätze erleichtern Audits und Nachweispflichten erheblich; proprietäre Blackboxen erschweren sie.

Für DACH-Entscheider, die auf Scheduling- oder Productivity-Tools wie Cal.com setzen, hat Ryan Sipes, Mozilla Thunderbird Product Manager, auf Hacker News bereits eine klare Alternative formuliert: Thunderbird Appointment werde immer Open Source bleiben. Der Wettbewerb in diesem Segment ist groß genug, um proprietäre Alternativen nicht akzeptieren zu müssen.

Die strategische Implikation ist klar: Wer KI als Argument nutzt, um Open-Source-Commitments aufzugeben, sollte damit rechnen, dass die Community genau hinschaut – und dass die Argumentation standhält oder eben nicht. Im Fall von Cal.com tut sie es nicht.

Fazit: Open Source braucht KI-Strategie, keine Angst

Cal.com ist ein Einzelfall. Kein anderes Unternehmen oder Projekt hat bisher den Relicensing-Schritt nachvollzogen. Das ist kein Zufall, sondern ein Signal: Die Argumente überzeugen nicht, und die strukturellen Vorteile von Open Source – geteiltes Audit-Budget, kollektive Sicherheitsprüfung, Community-Reaktionsfähigkeit – werden durch KI eher gestärkt als geschwächt.

Die eigentliche Frage ist nicht, ob Open Source durch KI stirbt. Sie ist, wie Open-Source-Projekte mit den neuen Werkzeugen umgehen: KI-gestützte Sicherheitsanalyse aktiv einsetzen, Governance-Prozesse für automatisierte Beiträge schaffen und Ressourcen für Maintainer sichern. Das ist schwieriger als Code schließen – aber es ist der richtige Weg.

Prognose: Wenn KI-fähige Reverse-Engineering-Tools wie GPT-5.4-Cyber tatsächlich halten, was sie versprechen, wird die Zahl proprietärer Lizenzen in der Softwarewelt mittelfristig eher sinken als steigen. Denn wenn Closed Source keinen echten Schutz mehr bietet, bleibt nur der Gemeinschaftsvorteil von Open Source. Cal.com hat eine schlechte Wette zur falschen Zeit abgeschlossen.