Darknight Coffee Netzwerk

Carrabelloy ' Meine Hobbys sind so vielseitig wie meine Gedanken & die Welt

Politik & Software

Open Source & KI

Crow & Corax

Kategorie: KI & Open Source

  • Ollama zeigt Preise: Transparenz oder Vorspiel zum Vendor Lock-in?

    Seit September 2026 zeigt Ollama auf seiner neuen Cloud-Plattform transparente Preise pro Modell und Token. Das klingt nach Fortschritt. Aber während wir auf die Preisschilder starren, steht der Server in den USA – und die Frage nach der Souveränität ist nicht mit einem Kreditrahmen zu beantworten.

    Die Preise

    Modell Input (pro M Tokens) Output (pro M Tokens)
    Llama 3.3 70B $0.25 $0.50
    Llama 4 Maverick $0.20 $0.60
    Mistral Large 3 $0.50 $1.50
    DeepSeek V4 $0.50 $2.00
    Gemma 3 27B $0.25 $0.75
    Command R+ $0.15 $0.60
    Qwen3.5 32B $0.35 $0.60
    Nemotron $0.20 $0.20

    Ollama setzt auf NVIDIA Cloud Providers (NCPs) als Hosting-Partner. Die Versprechen: no logging, no training, zero data retention – vertraglich zugesichert.

    Was gut ist

    Endlich echte Preise. Kein undurchsichtiger Token-Pool, keine Flatrate die bei intensiver Nutzung plötzlich drosselt. Ollama zeigt pro Modell, was es kostet. Das ist echte Transparenz.

    Die lokale Software bleibt kostenlos und unbegrenzt – das ist das wichtigste Signal.

    Was kritisch bleibt

    Die Server stehen in den USA. No logging ist eine Zusage, keine technische Garantie. Und eine Plattform, die heute transparent wirkt, kann morgen die Konditionen ändern – sobald die Nutzerbasis groß genug ist.

    Vergleich mit Venice Pro Plus ($68/Monat flat, uncensored):

    • Ollama Cloud: ~$50-100/Monat bei moderater Nutzung
    • Venice Pro Plus: $68/Monat flat, alle Modelle, anonym
    • Selfhosted: Nur Hardwarekosten, aber Wartungsaufwand

    Fazit

    Ollama macht vieles richtig. Aber für echte digitale Souveränität führt kein Weg am Selbsthosting vorbei. Ollama Cloud ist eine Brücke – nicht das Ziel.

    Quelle: RECHERCHE_Ollama_Cloud_Pricing_2026-09-01.md | Entwurf: Corax, Endredaktion: Crow

  • OpenMDW: Eine offene Lizenz ist noch keine offene KI

    Zielseite: carrabelloy.darknight-coffee.eu Hinweis: Keine Rechtsberatung. Tatsachen, offene Fragen und redaktionelle Bewertung werden getrennt.

    Eine Lizenz kann eine rechtliche Tür öffnen. Sie kann aber keine fehlenden Trainingsdaten, keinen fehlenden Code und keine fehlende Dokumentation herbeizaubern. Genau deshalb ist OpenMDW interessant – und genau deshalb darf aus dem Namen kein Gütesiegel für vollständig offene KI gemacht werden.

    OpenMDW steht für „Open Model, Data and Weights“. Die aktuelle Fassung 1.1 ist eine permissive Lizenz, die eigens für Modelle des maschinellen Lernens und ihre Materialien entwickelt wurde. Sie kann Gewichte, Software, Dokumentation, Trainingsdaten und weitere Bestandteile eines Modellpakets unter einen gemeinsamen Rechtsrahmen stellen. Das trifft ein reales Problem: Ein KI-System besteht nicht nur aus klassischem Quellcode, und die üblichen Softwarelizenzen beantworten nicht automatisch jede Frage zu Gewichten, Datenbankrechten, Geschäftsgeheimnissen oder Modellausgaben.

    Doch die wichtigste Frage bleibt: Was wurde tatsächlich geliefert?

    Was OpenMDW leistet

    OpenMDW 1.1 räumt für die bereitgestellten Modellmaterialien weitreichende Rechte ein. Nach der Selbstdarstellung des Projekts sollen Nutzung, Veränderung und Weitergabe erleichtert werden. Die Lizenz adressiert verschiedene Schutzrechte und behandelt auch Modellausgaben ausdrücklich. Für Entwickler und Betreiber kann das mehr Klarheit schaffen als ein Modellpaket, dessen Gewichte, Code und Dokumentation unter widersprüchlichen Bedingungen stehen.

    Das ist ein Fortschritt. Wer ein Modell quantisieren, feinabstimmen, spiegeln oder in eine andere Infrastruktur integrieren will, braucht belastbare Rechte. Eine offen zugängliche Datei allein genügt nicht, wenn ihre Nutzung oder Weitergabe rechtlich unklar bleibt.

    Die Grenze formuliert das Projekt jedoch selbst: OpenMDW verlangt keine Vollständigkeit der Modellmaterialien. Die Lizenz gilt für das, was unter ihr bereitgestellt wird. Ein Anbieter kann also nur Gewichte und ein kleines Inferenzskript veröffentlichen und dieses Paket großzügig lizenzieren. Daraus folgt weder ein reproduzierbarer Trainingsprozess noch eine vollständige Datenherkunft.

    Eine offene Lizenz beschreibt, was ich mit vorhandenen Materialien tun darf. Sie beweist nicht, dass alle Materialien vorhanden sind, die ich zum Prüfen, Verändern und Nachbauen brauche.

    Lizenz und offene KI sind zwei Prüfungen

    Die Open Source AI Definition 1.0 der Open Source Initiative stellt vier Freiheiten in den Mittelpunkt: ein System nutzen, untersuchen, verändern und teilen. Dafür verlangt sie die bevorzugte Form zur Veränderung. Bei maschinellem Lernen umfasst das ausreichend genaue Informationen über die Trainingsdaten, den vollständigen Trainings- und Ausführungscode sowie die Modellparameter.

    Hier liegt der Unterschied:

    • OpenMDW ist ein Lizenzinstrument für bereitgestellte Modellmaterialien.
    • Die OSI-Definition fragt, ob die nötigen Freiheiten und Veränderungsgrundlagen praktisch vorhanden sind.

    Beides kann zusammenpassen. Beides ist aber nicht identisch.

    OpenMDW 1.1 wurde am 13. August 2026 zur Prüfung im öffentlichen OSI-Lizenzverfahren eingereicht. Zum Stand dieses Artikels ist diese Einreichung keine abgeschlossene Genehmigung. In der öffentlichen Diskussion wurde besonders die Beendigungsklausel angesprochen: Sie erfasst neben Patent- auch bestimmte Urheberrechtsklagen und könnte weiter reichen als vertraute Regelungen etablierter Open-Source-Lizenzen. Das ist keine Randnotiz. Es zeigt, weshalb ein neuer Lizenztext öffentlich geprüft werden muss, bevor Marketing aus ihm eine unumstrittene Auszeichnung macht.

    Selbst eine spätere OSI-Genehmigung der Lizenz würde nicht automatisch jedes OpenMDW-lizenzierte Modell zu „Open Source AI“ machen. Dafür muss weiterhin das konkrete Modellpaket geprüft werden.

    Open Weights sind wertvoll – aber nicht das Ganze

    Offene Gewichte sind ein erheblicher Gewinn gegenüber einer reinen Cloud-API. Sie ermöglichen lokalen Betrieb, unabhängige Sicherheitsforschung, Quantisierung und in manchen Fällen Feinabstimmung. Für kleine Betreiber und Communities kann das den Unterschied zwischen vollständiger Anbieterabhängigkeit und einer realen Ausweichmöglichkeit bedeuten.

    Gewichte allein erklären jedoch nicht, wie ein Modell trainiert wurde. Sie zeigen nicht automatisch, welche Daten eingeflossen sind, welche Inhalte gefiltert wurden, welche menschlichen Bewertungen das Verhalten geprägt haben oder welche bekannten Schwächen bei bestimmten Sprachen bestehen. Auch ein frei nutzbares Gewicht kann von einem proprietären Tokenizer, einer undokumentierten Promptvorlage oder einer zentralen Downloadplattform abhängig bleiben.

    Deshalb brauchen Modellveröffentlichungen eine Materialbilanz:

    • Welche Gewichte und Zwischenstände sind vorhanden?
    • Sind Trainings-, Ausführungs- und Evaluationscode vollständig?
    • Wie genau ist die Datenherkunft beschrieben?
    • Welche Bestandteile haben abweichende Drittbedingungen?
    • Welche Hardware und Formate werden benötigt?
    • Gibt es versionierte Releases, Prüfsummen und erlaubte Mirrors?
    • Kann ein unabhängiges Team den Dienst aus Sicherung und Dokumentation wiederherstellen?

    Das ist keine Bürokratie aus Prinzip. Es ist der Unterschied zwischen einem Download und einer belastbaren Infrastruktur.

    Der Serveralltag entlarvt das Etikett

    Ein lokaler Modellserver kann hinter Nginx laufen, während seine Websuche weiterhin jede Anfrage an einen externen Anbieter schickt. Dann liegen die Gewichte lokal, aber der Rechercheweg nicht. Ein Matrix-Bot kann ein offenes Modell verwenden und trotzdem komplette Raumtexte in einer fremden Cloud protokollieren. Dann ist die Modelllizenz offen, der Datenfluss aber nicht souverän.

    Auch Backups zeigen die Grenze. Wer nur das Gewicht und ein Container-Image sichert, hat noch keinen getesteten Wiederanlauf. Ohne Tokenizer, Chat-Template, Versionsstand, Modellkarte, Hashwerte und Laufzeitparameter kann das System nach einem Ausfall andere Ergebnisse liefern oder gar nicht starten. Ein echtes Backup beweist sich erst beim Restore auf einem getrennten System.

    OpenMDW gehört damit in die Rechtsschicht eines Prüfpfads. Daneben stehen mindestens Materialien, Datenfluss, Betrieb, Qualität, Wiederanlauf und Exit. Wer eine Lizenz als Antwort auf alle Ebenen verkauft, überfordert die Lizenz und unterschätzt den Betrieb.

    Europa braucht mehr als ein neues Logo

    Ein europäischer Anbieter oder Rechenstandort kann Risiken mindern. Er schafft aber noch keine digitale Souveränität. Wenn Datenexport, Modellwechsel und unabhängiger Weiterbetrieb unmöglich bleiben, wurde lediglich der Vermieter ausgetauscht.

    Souverän ist ein System, wenn Menschen und Organisationen handlungsfähig bleiben: Schnittstellen sind dokumentiert, Daten vollständig exportierbar, Lizenzen eindeutig zugeordnet, Backups getestet und ein anderer Betreiber kann übernehmen. Öffentliche Beschaffung muss diese Punkte als Abnahmekriterien verlangen. Ein Häkchen bei „Open Source“ reicht nicht.

    Gleichzeitig darf offene KI nicht als kostenloses Sparmodell missbraucht werden. Modelle brauchen Rechenleistung, Sicherheitsprüfungen, Übersetzungen, Dokumentation und langfristige Wartung. Eine Lizenz bezahlt keine Maintainer. Öffentlich finanzierte KI muss deshalb nicht nur veröffentlicht, sondern als nutzbares Gemeingut gepflegt werden.

    Bewertung

    Redaktionelle Bewertung: OpenMDW ist weder bloßes Openwashing noch der große Befreiungsschlag. Die Lizenz bearbeitet eine wichtige und bisher schlecht passende Rechtsschicht. Ihre tatsächliche Wirkung hängt davon ab, welche Materialien ein Anbieter unter ihr veröffentlicht.

    Die klare Sprache lautet deshalb: „offene Gewichte“, wenn nur Gewichte offen sind; „OpenMDW-lizenziert“, wenn bereitgestellte Materialien dieser Lizenz folgen; „Open Source AI“ erst dann, wenn die nötigen Freiheiten und Veränderungsgrundlagen wirklich vorliegen.

    Digitale Souveränität entscheidet sich nicht am Lizenzlogo. Sie beweist sich in dem Moment, in dem ein anderer Betreiber das System aus Dokumentation, offenen Materialien und Sicherung wieder hochbekommt – ohne den ursprünglichen Anbieter um Erlaubnis zu bitten.

    Quellen

    1. OpenMDW, Projektseite: https://openmdw.ai/
    2. OpenMDW, Lizenzfassung 1.1: https://openmdw.ai/license/
    3. OpenMDW, offizielle README und Vollständigkeitsgrenze: https://github.com/OpenMDW/OpenMDW/blob/main/README.md
    4. Open Source Initiative, Open Source AI Definition 1.0: https://opensource.org/ai/open-source-ai-definition
    5. OSI License Review, Einreichung und öffentliche Diskussion zu OpenMDW 1.1: https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2026-August/006126.html

    Podcast zur Analyse

    Die ausführliche Podcastfolge: OpenMDW: Eine offene Lizenz ist noch keine offene KI

    CTA

    Diskussion: https://treff.darknight-coffee.eu Podcast: https://podcast.darknight-coffee.org/pages/startseite Blog: https://carrabelloy.darknight-coffee.org/blog/

    Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

  • Vibe Code unter GPL? Ein Lizenzkopf ersetzt keine Herkunft

    Hinweis: Dieser Beitrag ist keine Rechtsberatung. Er trennt belegte Tatsachen, offene Rechtsfragen und redaktionelle Bewertung.

    Ein Pull Request bringt 800 neue Zeilen. Der Code sieht ordentlich aus, darüber steht „GPL“, doch der Einreicher kann zentrale Routinen nicht erklären. „Hat die KI gebaut“, sagt er. Ist das jetzt freie Software?

    Die ehrliche Antwort lautet: Ein Lizenzkopf allein reicht nicht. Freie Software nutzt das Urheberrecht als Werkzeug. Rechteinhaber erlauben Nutzung, Veränderung und Weitergabe; Copyleft bindet diese Freiheiten an Bedingungen. Wenn ein vollständig maschinell erzeugter Codeblock mangels menschlicher Schöpfung selbst keinen urheberrechtlichen Schutz genießt, kann dieser Hebel fehlen. Gleichzeitig kann derselbe Output fremden geschützten Code enthalten. Nicht selbst geschützt bedeutet deshalb nicht rechtlich risikolos.

    Das ist kein Argument gegen jedes KI-Werkzeug. Es ist ein Argument gegen die Vorstellung, Herkunft und Verantwortung ließen sich mit einem Etikett ersetzen.

    Was bei Software geschützt wird

    Artikel 1 der EU-Software-Richtlinie 2009/24/EG schützt ein Computerprogramm, wenn es eine eigene geistige Schöpfung seines Autors ist. Paragraf 69a Urheberrechtsgesetz setzt diesen Maßstab in Deutschland um. Geschützt ist die Ausdrucksform eines Programms, nicht die zugrunde liegende Idee oder Funktion. Paragraf 7 UrhG bestimmt den Urheber als Schöpfer des Werkes. Die geprüften Normen weisen einer Maschine keine Urheberschaft zu.

    Der Europäische Gerichtshof hat den Maßstab in mehreren Verfahren präzisiert. „Infopaq“ zeigt, dass auch Teile eines Werkes geschützt sein können, wenn sie die eigene geistige Schöpfung ausdrücken. „Painer“ stellt auf freie und kreative Entscheidungen ab. „SAS Institute“ trennt bei Software zwischen dem konkreten Code und ungeschützten Elementen wie Funktionalität, Programmiersprache oder Dateiformaten.

    Diese Urteile behandeln keinen LLM-generierten Quellcode. Sie liefern aber die entscheidende Leitfrage: Kommen freie kreative Entscheidungen eines Menschen im konkreten Ergebnis erkennbar zum Ausdruck?

    Eine bloße Aufgabenbeschreibung beantwortet das nicht. „Schreibe ein Backup-Skript für Synapse“ ist eine Anforderung. Sie sagt noch nicht, wer die konkrete Struktur des Skripts gestaltet hat. Anders kann es aussehen, wenn ein Mensch eigenen Ausgangscode einbringt, Architekturentscheidungen trifft, Vorschläge verwirft, Teile selbst neu schreibt und diese Arbeit dokumentiert. Eine feste Prozentgrenze für „genug Mensch“ gibt es in den geprüften Quellen nicht.

    Ein Prompt macht noch keinen Urheber

    Die Free Software Foundation Europe weist in ihrer Analyse vom 25. August 2026 darauf hin, dass ein Prompt zunächst eine Idee oder Anweisung ausdrückt. Der Nutzer kontrolliert normalerweise nicht vollständig, wie das Modell diese Vorgabe in konkreten Code übersetzt. Derselbe Prompt kann verschiedene Ergebnisse hervorbringen. Auch wiederholtes Prompten oder großer Zeitaufwand begründen deshalb nicht automatisch Urheberschaft am Output.

    Das Amtsgericht München hat am 13. Februar 2026 über drei KI-generierte Logos entschieden. Das Urteil betrifft Bilder, nicht Software, und ist erstinstanzlich. Seine Leitlinie ist trotzdem interessant: KI-Assistenz schließt Schutz nicht grundsätzlich aus, doch der menschliche Einfluss muss im konkreten Ergebnis objektiv erkennbar und prägend sein. Im entschiedenen Fall genügten Prompts und Auswahl nicht.

    Aus diesem Urteil lässt sich kein fertiger Softwaretest bauen. Es bestätigt nur, wie wichtig die Trennung ist: Das Werkzeug allein entscheidet nicht; der nachweisbare menschliche Ausdruck zählt.

    Die doppelte Gefahr: kein eigener Schutz, mögliche Fremdrechte

    Die populäre Abkürzung „KI-Code ist gemeinfrei“ ist zu grob. Selbst wenn ein Output keinen eigenen urheberrechtlichen Schutz erreicht, kann er geschützte Ausdrucksformen Dritter reproduzieren. Umgekehrt ist gleiche Funktionalität noch keine Verletzung. Eine übliche Schleife, eine Programmiersprache oder dieselbe Schnittstelle sind nicht automatisch geschützter Ausdruck.

    Für jedes ernsthafte Projekt ergeben sich zwei getrennte Prüfungen:

    1. Welcher menschliche Anteil ist nachvollziehbar und kann überhaupt lizenziert werden?
    2. Enthält der Output geschützten Fremdcode oder nur eine eigenständige Umsetzung einer ungeschützten Idee?

    Auch Trainingsrecht, Outputverletzung, Urheberschaft am neuen Code und Vertragsbedingungen des KI-Dienstes sind verschiedene Ebenen. Wer sie vermischt, macht aus offenen Fragen falsche Gewissheiten.

    Im Serveralltag wird das schnell konkret. Ein Chatbot kann einen Nginx-Block für Matrix-/.well-known erzeugen. Kurze Standarddirektiven mögen stark technisch vorgegeben sein. Der Betreiber muss trotzdem Header, Proxyziele, Timeouts und Caching prüfen. Ein formal freier Schnipsel kann technisch falsch oder sicherheitsgefährlich sein.

    Noch kritischer wird ein KI-Patch für Token-Widerruf und Sessionbereinigung. Vielleicht funktioniert der Happy Path, aber niemand versteht Race Conditions, Fehlerpfade oder das Logging sensibler Tokens. Dann prüft der Maintainer nicht nur Lizenzfragen. Er übernimmt auch die Sicherheits- und Wartungsarbeit, die der Einreicher eingespart hat.

    Provenienz ist kein Bürokratietick

    Die Software Freedom Conservancy empfiehlt für KI-assistierte FOSS-Beiträge unter anderem: Projektregeln respektieren, eingesetztes System und Art der Unterstützung offenlegen, Meta-Artefakte aufbewahren und den Code gründlich menschlich prüfen. Das sind Empfehlungen einer Interessenorganisation, keine Rechtsnorm. Betrieblich treffen sie aber den Kern.

    Ein nachvollziehbarer Beitrag braucht eine Herkunftskette. Dazu gehören mindestens:

    • Kennzeichnung der KI-Unterstützung im Commit oder Pull Request,
    • Modell oder Dienst und Version, soweit bekannt,
    • Markierung betroffener Dateien oder Abschnitte,
    • Aufbewahrung wesentlicher Prompts, Ausgangsdateien und Bearbeitungsschritte,
    • kleine, überprüfbare Patches,
    • selbst ausgeführte Tests und Sicherheitsprüfung,
    • eine Person, die den Code versteht und dafür ansprechbar bleibt.

    Bei einem Restore-Skript für Matrix-Räume reicht es nicht, dass die Befehle plausibel aussehen. Datenbank, Medien, Signaturschlüssel, Raumzustand und Föderationswarteschlangen müssen nach einem Test konsistent sein. Der dokumentierte Test ist für den Betrieb wertvoller als die Behauptung, der Code sei „von KI und daher frei“.

    Bewertung: Proprietäres Tempo, gemeinschaftliche Rechnung

    Eigene Bewertung: Das größte Risiko ist der Verlust der Herkunftskette. Proprietäre KI-Anbieter verkaufen Geschwindigkeit, während Trainingsquellen, Modellschichten und Entstehungswege oft geschlossen bleiben. Freie Projekte sollen anschließend prüfen, ob der Output sicher, wartbar und lizenzverträglich ist. Der Anbieter verdient am Zugang; die Community trägt einen erheblichen Teil der Folgekosten.

    Das ist eine Machtfrage. Die Zeitersparnis des Einreichers kann sich in unbezahlte Arbeit für Maintainer verwandeln. Wer einen großen Maschinenpatch einreicht, den er selbst nicht erklären kann, spendet dem Projekt keinen Code. Er liefert eine Prüfaufgabe ab.

    Der Einwand, Menschen kopierten ebenfalls und produzierten schlechten Code, stimmt. Menschliche Beiträge brauchen ebenfalls Review. Bei LLMs kommen aber Skalierung, unklare Quellen und nicht immer reproduzierbare Ausgaben hinzu. Eine besondere Offenlegung ist deshalb sachlich begründet.

    Ein vollständiges KI-Verbot kann für ein überlastetes Projekt legitim sein. Es ist jedoch nicht zwingend die einzige vernünftige Regel. Ein Projekt kann Assistenz erlauben, wenn Offenlegung, kleine Patches, Tests und menschliche Verantwortungsübernahme verbindlich sind. Entscheidend ist, dass die Community ihre Bedingungen selbst setzt – nicht der Anbieter des Codeassistenten.

    Was freie Projekte jetzt festlegen sollten

    Eine klare Beitragsregel muss nicht lang sein. Sie sollte vier Fragen beantworten:

    1. Ist KI-Assistenz erlaubt, eingeschränkt oder ausgeschlossen?
    2. Welche Angaben zur Herkunft sind verpflichtend?
    3. Welche menschlichen Tests und Erklärungen müssen mitgeliefert werden?
    4. Wann wird ein Beitrag wegen unklarer Rechte oder fehlender Wartbarkeit abgelehnt?

    Ein maschinenlesbarer Commit-Trailer könnte die Angaben vereinheitlichen. Er sollte aber nicht vorschnell als Rechtsgarantie verkauft werden. Er dokumentiert eine Aussage; er beweist nicht automatisch deren Richtigkeit. Vor einer konkreten Empfehlung müssen verschiedene Projektregeln verglichen und der Workflow technisch sowie juristisch geprüft werden.

    Offen ist außerdem der Rechtsmittelstand des Münchener Urteils. In den geprüften Quellen existiert kein höchstrichterliches deutsches oder unionsrechtliches Urteil speziell zur Schutzfähigkeit LLM-generierten Quellcodes. Auch die vertragliche Wirkung einer FOSS-Lizenz bei möglicherweise ungeschütztem Output bleibt einzelfallabhängig. Für strittige Beiträge und Veröffentlichungen ist fachjuristisches Gegenlesen notwendig.

    Fazit

    Vibe Code ist nicht automatisch frei, nicht automatisch verboten und nicht automatisch sicher. Der rechtliche Maßstab fragt nach menschlicher Schöpfung und konkretem Ausdruck. Der technische Maßstab fragt nach Funktion, Sicherheit, Testbarkeit und Wartung. Freie Projekte brauchen beides.

    Ein Lizenzkopf kann die Projektlizenz sichtbar machen. Er ersetzt aber keine Rechtekette. Ein Prompt kann eine Idee beschreiben, ohne den konkreten Output zum Werk des Nutzers zu machen. Ein möglicherweise ungeschützter Codeblock kann trotzdem fremde Rechte berühren. Und selbst rechtlich unproblematischer Code kann als ungeprüfte Wartungslast im Projekt landen.

    Meine klare Linie lautet: KI-Nutzung offenlegen, Code verstehen, kleine Patches liefern, Tests belegen und Verantwortung übernehmen. Transparenz über KI ist keine Beichte. Sie ist Teil einer belastbaren Software-Lieferkette.

    Quellen

    1. Free Software Foundation Europe: „Copyrightability of LLM-generated code: Can we license ‘vibe code’ into Free Software?“, 25.08.2026: https://fsfe.org/news/2026/news-20260825-01.en.html
    2. Software Freedom Conservancy: „Recommendations When Using LLM-backed Generative AI Systems for FOSS Contributions“: https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
    3. § 7 UrhG: https://www.gesetze-im-internet.de/urhg/__7.html
    4. § 69a UrhG: https://www.gesetze-im-internet.de/urhg/__69a.html
    5. § 69b UrhG: https://www.gesetze-im-internet.de/urhg/__69b.html
    6. Richtlinie 2009/24/EG, besonders Artikel 1: https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32009L0024
    7. Amtsgericht München, Urteil vom 13.02.2026 – 142 C 9786/25: https://www.gesetze-bayern.de/Content/Document/Y-300-Z-BECKRS-B-2026-N-1513
    8. EuGH, Infopaq, C-5/08: https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:62008CJ0005
    9. EuGH, Painer, C-145/10: https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:62010CJ0145
    10. EuGH, SAS Institute, C-406/10: https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:62010CJ0406

    CTA

    Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Podcast: https://podcast.darknight-coffee.org/pages/startseite Blog: https://carrabelloy.darknight-coffee.org/blog/

    Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

    Podcast zum Artikel

    Vibe Code unter GPL? – die vollständige Podcastfolge

  • Open Source KI:

    Kontrolle statt Abhängigkeit – was im Alltag wirklich zählt

    Auf Konferenzen klingt KI wie Limonade auf Eis. Im Alltag ist sie Strom, Wasser, Wartung – und eine Machtfrage über Kontrolle, Kosten und Abhängigkeit.

    Wer KI nur als Tool betrachtet, unterschätzt den Kern: Es geht nicht zuerst um Prompts, sondern um Infrastruktur. Um die Frage, wer deine Daten sieht, wer den Schalter umlegt, wenn Preise steigen, und wer am Ende bestimmt, was noch funktioniert und was nicht. Genau deshalb ist Open Source KI kein Nerd-Nebenthema, sondern eine strategische Entscheidung.

    Kontrolle ist keine Ideologie, sondern Betriebspraxis

    Wenn du ein geschlossenes System nutzt, kaufst du nicht nur Leistung ein, sondern Abhängigkeit mit. Das ist nicht automatisch falsch – aber es muss bewusst sein. Wer sich auf proprietäre KI verlässt, gibt zentrale Hebel aus der Hand: Modellwahl, Datenpfade, Kostenkurve, Wechselmöglichkeiten.

    Open Source bedeutet nicht, dass alles gratis oder einfach ist. Open Source bedeutet vor allem: nachvollziehbar, anpassbar, austauschbar. Du kannst Fehler untersuchen, Komponenten wechseln, Prozesse dokumentieren und notfalls den Betrieb selbst sichern. Genau das ist in kritischen Umgebungen der Unterschied zwischen „läuft gerade“ und „bleibt kontrollierbar“.

    Die eigentliche Kostenfrage beginnt nach dem Demo-Moment

    Viele rechnen KI mit dem Demo-Reflex: ein paar Requests, nettes Ergebnis, passt schon. Die Realität beginnt später:

    steigende Token-/API-Kosten
    Vendor-Lock-in über proprietäre Schnittstellen
    unklare Preisänderungen
    Zusatzkosten für Monitoring, Guardrails, Ausfallsicherheit
    Open Source KI verschiebt die Kostenstruktur: weniger Blackbox-Abhängigkeit, dafür mehr Verantwortung im Betrieb. Das ist kein Nachteil, sondern Ehrlichkeit. Du zahlst entweder mit Geld an den Anbieter oder mit Kompetenz im eigenen Setup. Der Unterschied ist: Im zweiten Fall bleibt die Entscheidungsmacht bei dir.

    Datenhoheit ist keine Checkbox

    „Datenschutzkonform“ als Marketing-Satz reicht nicht. Entscheidend sind konkrete Fragen:

    Wo liegen Eingaben und Logs?
    Wie lange werden Daten gehalten?
    Wer kann auf Metadaten zugreifen?
    Was passiert mit Fehlerprompts, Debug-Ausgaben, Anhängen?
    In offenen Setups kannst du diese Fragen technisch beantworten und prüfen. In geschlossenen Umgebungen bekommst du oft nur Vertragsprosa. Für private Projekte mag das noch tragbar sein. Für sensible Workflows, Redaktionsprozesse oder Community-Betrieb wird es schnell kritisch.

    Open Source heißt auch: Grenzen offen benennen

    Seriöse KI-Arbeit braucht keine Heilsversprechen. Auch offene Modelle halluzinieren, brauchen Pflege und können im falschen Setup Unsinn liefern. Der Vorteil ist nicht Perfektion, sondern Transparenz:

    Du kannst Evaluationskriterien offenlegen.
    Du kannst Fehler reproduzieren.
    Du kannst den Stack verbessern, statt nur Tickets zu schreiben.
    Das ist politisch relevant. Denn wer nur konsumiert, wird abhängig. Wer versteht und betreibt, wird handlungsfähig.

    Was im Alltag wirklich funktioniert

    Für viele Teams und Einzelprojekte funktioniert ein hybrider Weg am besten:

    Kritische Inhalte lokal oder kontrolliert verarbeiten
    Externe Modelle nur dort nutzen, wo Risiko und Nutzen klar bewertet sind
    Prozesse dokumentieren (Versionen, Prompts, Prüfpfade, Freigaben)
    Regelmäßig prüfen, ob Tooling noch zur eigenen Linie passt
    Diese Nüchternheit ist unspektakulär – aber sie trägt. Nicht der lauteste Stack gewinnt, sondern der, den man in sechs Monaten noch verantworten kann.

    Souveränität ist eine Praxis, kein Label

    Open Source KI ist nicht automatisch besser. Aber sie gibt dir die Chance, bessere Entscheidungen zu treffen – technisch, wirtschaftlich und politisch. Und genau darum geht es: nicht um KI als Showeffekt, sondern um KI als Infrastruktur unter eigener Kontrolle.

    Wer heute über digitale Souveränität spricht, muss über Modelle, Schnittstellen und Betriebsverantwortung sprechen. Alles andere ist PR.

    Diskussion: https://treff.darknight-coffee.eu
    Werkstatt: https://carrabelloy.darknight-coffee.eu/blog/
    Wenn dir das Projekt hilft: Spendenlinks sind im Blog.