Letzten Monat habe ich eine kuratierte Liste freier Open-Source-Werkzeuge für Generative Engine Optimization gebaut. Über jeden Eintrag entschied eine einzige Regel: Das Projekt muss selbst betreibbar sein und unter einer OSI-approbierten Lizenz stehen. Alles andere ergab sich daraus.
Ich wollte nicht aus dem Gedächtnis auswählen, also habe ich die Auswahl als Verfahren aufgeschrieben und laufen lassen. Das hier ist dieses Verfahren, mit den Zahlen eines frischen Durchlaufs vom 14. August 2026. Es ist nicht auf GEO beschränkt — dieselben vier Schritte funktionieren in jedem Ökosystem, in dem man wissen muss, worauf man sich rechtlich stützen darf.
Schritt 1: sweepen, nicht browsen
Wer auf GitHub browst, bekommt das, was bei Leuten beliebt ist, die über GitHub schreiben. Ein Such-Sweep liefert auch den langen Schwanz. Ich habe fünfzehn Queries benutzt — acht Topic- und sieben Keyword-Queries — und je zwei Seiten tief paginiert.
for q in \
"topic:generative-engine-optimization" "topic:answer-engine-optimization" \
"topic:llms-txt" "topic:ai-visibility" "topic:ai-seo" "topic:llm-seo" \
"topic:ai-search" "topic:aeo" \
"llms.txt generator in:name,description,readme" \
"generative engine optimization in:name,description" \
"answer engine optimization in:name,description" \
"AI visibility tracking in:name,description" \
"ai crawler robots.txt in:name,description" \
"schema.org json-ld generator in:name,description" \
"brand mentions LLM in:name,description"
do
for page in 1 2; do
curl -s -H "Accept: application/vnd.github+json" \
--get --data-urlencode "q=$q" --data "per_page=100&page=$page" \
https://api.github.com/search/repositories \
| jq -r '.items[] | [.full_name, .stargazers_count, .archived,
.pushed_at, (.license.spdx_id // "none")] | @tsv'
sleep 7
done
done | sort -u > repos.tsvDie sieben Sekunden Pause sind das Rate-Limit der unauthentifizierten Such-API, zehn Anfragen pro Minute. Mit Token sind es dreißig und man kann auf zwei runter. Die fünfzehn Queries lieferten 1.434 unique Repositories.
Das meiste davon ist Rauschen. Besonders die Keyword-Queries ziehen User-Agent-Parser, Telegram-Bots und an einer Stelle ein C#-Cheatsheet herein, das llms.txt einmal erwähnt. Genau dafür sweept man breit — gefiltert wird danach, und man sieht, was man gefiltert hat.
Schritt 2: die Filtermatrix
Vier Felder, die die Such-API alle schon mitliefert, das kostet also keine zusätzlichen Requests. Alles Archivierte fliegt raus, denn ein archiviertes Repo ist eine tote Abhängigkeit. Alles ohne Push in zwölf Monaten fliegt raus, was für sich kein Qualitätssignal ist, aber gepflegt von aufgegeben trennt. Alles unter 30 Sternen fliegt raus, und darauf komme ich zurück. Die SPDX-Lizenzkennung bleibt für Schritt 3, denn das ist das Feld, das die eigentliche Arbeit macht.
unique Treffer 1434
nicht archiviert 1425
Push in den letzten 12 Monaten 1353
mindestens 30 Sterne 133
OSI-approbierte SPDX-Kennung 94Die Sternschwelle ist der grobe Schnitt. Sie entfernt 1.220 Repositories auf einen Schlag, und einige davon sind gut — ein neues Werkzeug von jemandem, der es noch nicht beworben hat, sieht genauso aus wie ein aufgegebenes Experiment. Ich habe sie behalten, weil ich keine 1.353 READMEs lesen konnte, und ich nenne den willkürlichen Schnitt lieber, als die Liste als vollständig auszugeben. Wer das mit einer Schwelle von 10 wiederholt, sollte mit etwa dreimal so viel Lesearbeit rechnen.
Schritt 3: die Lizenzprüfung, und warum sie keine Formalie ist
Von den 133 Repositories, die übrig blieben, tragen 94 eine OSI-approbierte Lizenz. Die übrigen 39 zerfallen in zwei Gruppen, die getrennt beschrieben gehören, weil es beiden gegenüber unfair wäre, sie zu vermischen.
23 haben gar keine Lizenzdatei. Nach geltendem Urheberrecht heißt das: alle Rechte vorbehalten. Es gibt kein eingeräumtes Recht, den Code zu nutzen, zu verändern oder weiterzugeben, egal wie öffentlich das Repository ist und wie offensichtlich die Autoren es anders gemeint haben. Das größte davon hat 3.534 Sterne. Mehrere gehören einem kommerziellen Scraping-Anbieter, der Beispielcode veröffentlicht — dort ist das Weglassen vermutlich Absicht. Andere sind erkennbar ein Versehen von jemandem, der ein README angelegt hat und weitergezogen ist.
16 haben eine Lizenzdatei, die GitHub keiner SPDX-Kennung zuordnen kann. GitHub meldet die als NOASSERTION, und das ist ein ganz anderer Befund. Meist steckt ein eigener Text dahinter, eine Creative-Commons-Variante oder ein Hinweis auf Doppellizenzierung. Die muss man lesen, nicht ausschließen. Zwei davon sind nach dem Lesen auf der Liste gelandet.
Dazu kommt die Kategorie, die das SPDX-Feld nicht erwischt: source-available Lizenzen, die auf den ersten Blick wie Open Source aussehen. BSL, FSL und SSPL veröffentlichen alle den Quellcode und schränken alle ein, was man damit bauen darf. Die Functional Source License wandelt sich nach zwei Jahren in Apache-2.0 um, was eine vernünftige unternehmerische Entscheidung ist und heute trotzdem kein Open Source. Eine AEO-Monitoring-Plattform mit 99 Sternen ist genau daran gescheitert.
Nichts davon ist ein Vorwurf. Eine fehlende Lizenzdatei ist meistens ein Versehen, und eine source-available Lizenz zu wählen ist eine legitime Geschäftsentscheidung. Aber wenn eine Liste sich open source nennt, ohne zu prüfen, trägt das Etikett keine Information mehr, und irgendwer baut auf dieser Grundlage eine Abhängigkeit.
Die Lizenzverteilung unter den 94, die durchkamen, ist schmaler als erwartet: 62 MIT, 19 Apache-2.0, 6 AGPL-3.0, 3 CC0-1.0 sowie je einmal GPL-3.0, GPL-2.0 und MPL-2.0.
Schritt 4: das README von allem lesen, was übrig bleibt
Eine Repository-Beschreibung ist Werbetext des Autors. Eine Zusammenfassung in einem fremden Blog ist derselbe Text, paraphrasiert von jemandem, der das Werkzeug ebenfalls nicht ausgeführt hat.
Der deutlichste Fall, den ich hatte: Ein Visibility-Tracker steuert die echten Chat-Oberflächen im Browser, statt die Modell-APIs aufzurufen. Das ist der ganze Grund seiner Existenz — API-Completions unterscheiden sich regelmäßig von dem, was die Chat-Oberfläche einem Nutzer anzeigt — und es steht nicht in der Repository-Beschreibung. Ich hätte ihn neben sechs API-basierte Tracker einsortiert und damit falsch beschrieben.
Außerdem habe ich die Ausreißer gegengeprüft. Bei einem brandneuen SEO-Skill-Repository mit 12.000 Sternen lohnt ein Blick auf das Verhältnis von Sternen zu Forks und auf das Erstellungsdatum, bevor man öffentlich dafür geradesteht. Der letzte Schritt war mechanisch: jeden Link vor der Veröffentlichung per curl auf 200 prüfen. Alle 64. Zwei waren umgezogen.
Was das kostet und was es bringt
Der Sweep läuft in etwa vier Minuten. Das Filtern sind ein paar Zeilen jq. Die READMEs von allem zu lesen, was übrig bleibt, hat den größeren Teil eines Tages gebraucht, und dort sitzt der ganze Wert — der automatisierte Teil entscheidet nur, was man lesen muss.
Herausgekommen sind 62 Einträge. Die Zahl, zu der ich immer wieder zurückkomme, ist die andere: 17 % der gepflegten, nicht-trivialen Projekte in diesem Feld dürfen von niemandem rechtssicher genutzt werden. Das ist kein GEO-Problem. Wer dieselben vier Schritte auf das Ökosystem anwendet, von dem er abhängt, sieht, was zurückkommt.
Die Maintainer anschreiben
Nach der Veröffentlichung habe ich eine Handvoll Mails verschickt, und die Rahmung war wichtiger als der Inhalt. Die zwei kalten Anfragen aus dem Juli blieben unbeantwortet, was für eine Nachricht ohne Gegenwert das richtige Ergebnis war. Jemandem mitzuteilen, dass er aufgenommen wurde, und zu fragen, ob ich sein Projekt richtig beschrieben habe, ist eine andere Nachricht. Sie ist nützlich zu bekommen, und eine Korrektur ist etwas, worauf man antworten kann.
Ich habe zehn der 58 gelisteten Maintainer nach Antwortwahrscheinlichkeit ausgewählt, nicht nach Prominenz: eine Einzelperson statt einer Organisation, weil eine Person entscheidet und antwortet; zwischen 30 und 800 Sterne, weil Sichtbarkeit in dieser Größe noch zählt; ein kürzlicher Push, weil ein aktiver Maintainer seine Mails liest; eine öffentliche Kontaktadresse oder ein echter Blog; und thematische Nähe, damit aus einer Antwort ein Gespräch werden kann.
Drei Mails sind rausgegangen. Beantwortet ist bisher keine, was ich dazuschreibe, weil die Alternative wäre, nur die Outreach-Zahlen zu veröffentlichen, die der Methode schmeicheln.
Heißt eine fehlende Lizenzdatei, dass der Code gemeinfrei ist?
Nein, das Gegenteil. Ohne ausdrückliche Lizenz gilt als Standard: alle Rechte vorbehalten. Ein öffentliches Repository ohne LICENSE-Datei räumt einem also gar keine Rechte ein, so frei es auch veröffentlicht wurde.
Ist source-available dasselbe wie Open Source?
Nein. BSL, FSL und SSPL veröffentlichen den Quellcode, schränken aber ein, was man damit bauen darf, und scheitern damit an der OSI-Definition. FSL wandelt sich nach zwei Jahren in Apache-2.0, ein konkretes Release wird also irgendwann Open Source, das aktuelle ist es nicht.
Was bedeutet NOASSERTION auf GitHub?
Dass GitHub eine Lizenzdatei gefunden, sie aber keiner bekannten SPDX-Kennung zuordnen konnte, meist weil es ein eigener Text oder eine Variante ist. Das ist eine Aufforderung, die Datei zu lesen, kein Beleg dafür, dass das Projekt unlizenziert ist.
