Natively: Interview-Copilot mit lokalem Betrieb und BYOK, aber ohne klare Lizenz

Welches Problem Natively adressiert und für wen es gebaut ist

Der README benennt die Zielgruppe indirekt, aber deutlich: Menschen in Bewerbungsgesprächen, Vorlesungen und Meetings, die während des Gesprächs mitlesen wollen. Das Projekt positioniert sich als kostenlose Alternative zu Cluely, Otter, Granola, Final Round AI, Fireflies und Interview Coder und nennt als Preisvergleich 20 bis 149 US-Dollar pro Monat für die Konkurrenz. Der eigene Preis ist 0 für persönliche, nicht-kommerzielle Nutzung. Das ist die Kernaussage des Repositories, und sie ist eng mit einem zweiten Versprechen verknüpft: Der Betrieb läuft lokal, die Daten verlassen das Gerät nach Darstellung des README nicht, und es habe nie einen Datenvorfall gegeben. Ein dritter Punkt ist die Modellwahl. Natively bindet keine eigene Inferenz ein, sondern arbeitet nach dem BYOK-Prinzip: Der Nutzer bringt seinen eigenen API-Schlüssel mit. Wer diesen Schlüssel nicht hat oder nicht bezahlen will, bekommt von Natively keine Antworten. Das Projekt ist damit kein fertiges Produkt mit eingebautem Modell, sondern ein Client. Die Liste der Themen im Repository enthält neben technischen Stichworten auch Begriffe wie cheating und interview cheating tool. Das ist keine Nebensache, denn es beschreibt den tatsächlichen Anwendungsfall, für den ein Teil der Nutzer das Werkzeug installiert. Wer Natively einsetzt, sollte sich im Klaren sein, dass viele Arbeitgeber den Einsatz solcher Hilfsmittel in Bewerbungsgesprächen ausdrücklich untersagen.

Audio lokal, Antworten über eigene Schlüssel: der Aufbau laut README

Der README beschreibt die Architektur nur in Umrissen, und das ist eine Schwäche des Materials. Gesichert ist: Natively ist eine Desktop-Anwendung für macOS 12+ (Apple Silicon und Intel) und Windows 10/11, geschrieben in TypeScript. Die Audioaufnahme erfolgt nativ, der README nennt eine Latenz von unter 500 Millisekunden zwischen Aufnahme und Ergebnis. Transkription, Notizen, lokales RAG und die LLM-Anbindung laufen nach Darstellung des Projekts auf dem Gerät, wobei die eigentliche Inferenz beim jeweiligen Modellanbieter stattfindet, dessen Schlüssel der Nutzer hinterlegt. Genau an dieser Stelle wird die Beschreibung dünn. Der README sagt nicht, welcher Transkriptionsdienst verwendet wird, ob das Sprachmodell lokal läuft oder ausschließlich über eine API, und welche Daten dabei an welchen Anbieter gehen. Der Satz, dass alles lokal läuft, ist mit dem BYOK-Modell nur dann vollständig vereinbar, wenn der Modellaufruf selbst als ausgelagerter Schritt verstanden wird. Wer den Datenschutzversprechen folgen will, muss diese Frage vor dem Einsatz klären, und der README beantwortet sie nicht. Für ein Werkzeug, das Mikrofon und Bildschirm während eines Bewerbungsgesprächs mitschneidet, ist das eine relevante Lücke. Der Stealth-Modus, der das Overlay vor Bildschirmaufnahmen verbergen soll, wird genannt, aber nicht technisch erklärt.

Installation und Betrieb: was aus dem Repository belegbar ist

Der README beschreibt keinen Build aus dem Quelltext. Stattdessen verweist er auf die Releases-Seite mit fertigen Downloads für macOS und Windows, erreichbar über den Pfad /releases/latest im Repository. Das ist der offizielle Weg, den das Projekt nennt. Für den Quelltext selbst gibt der README keine Befehlsfolge an, also auch kein npm install, kein pnpm dev und kein Startskript. Wer aus dem Repository bauen will, muss sich die package.json im Wurzelverzeichnis ansehen, die im Material nicht enthalten ist. Das ist ein Unterschied zu vielen TypeScript-Projekten, die ihre Entwicklerumgebung im README dokumentieren. Für den Betrieb sind zwei Dinge belegt: Der Nutzer muss einen API-Schlüssel eines Modellanbieters hinterlegen, und die Anwendung läuft auf den genannten Betriebssystemversionen. Der README nennt außerdem einen Telegram-Chat und eine LinkedIn-Seite als Kontaktwege, aber keine Konfigurationsdatei, keinen Umgebungsvariablennamen und keinen Schlüssel für die Einstellungen. Diese Angaben fehlen im vorliegenden Material. Wer Natively produktiv nutzen will, muss die Konfiguration deshalb in der Anwendung selbst suchen. Die Versionshistorie zeigt Releases 2.6.0, 2.7.0 und 2.8.8 zwischen Mai und August, was auf eine aktive Pflege hindeutet, aber nichts über die Qualität der einzelnen Versionen aussagt.

Die Lizenz ist der kritischste Punkt am ganzen Projekt

Das Repository gibt als Lizenz NOASSERTION an. Der README spricht von Personal Use Source und von kostenloser Nutzung für persönliche, edukative, forschende und nicht-kommerzielle Zwecke. Das sind zwei verschiedene Aussagen, und keine davon ist eine anerkannte Open-Source-Lizenz. Der Begriff source-available, den das Projekt selbst verwendet, ist die ehrlichere Beschreibung: Der Quelltext ist einsehbar, aber die Nutzungsrechte sind eingeschränkt. Wer Natively in einem Unternehmen einsetzen will, um Meetings zu protokollieren, braucht dafür eine Erlaubnis, die aus dem README nicht hervorgeht. Wer den Code forken und weiterverbreiten will, ebenfalls. Das ist keine Formalie. Eine Anwendung, die Mikrofon und Bildschirminhalt verarbeitet, wird in vielen Unternehmen ohnehin durch eine Sicherheitsfreigabe müssen, und eine unklare Lizenz ist dabei ein häufiger Ablehnungsgrund. Der Hinweis auf 0 US-Dollar Kosten gilt entsprechend nur für den privaten Gebrauch. Ich gebe hier keine Rechtsberatung, und der README ersetzt sie nicht. Wer Klarheit braucht, muss die LICENSE-Datei im Repository lesen, die im vorliegenden Material nicht enthalten ist. Solange das nicht geschehen ist, ist jede Aussage über die Zulässigkeit des Einsatzes Spekulation.

Wo Natively an Grenzen stößt

Der auffälligste Mangel ist die fehlende technische Dokumentation. Der README erklärt nicht, wie das Overlay auf Betriebssystemebene eingebunden wird, wie die Bildschirmaufnahme mit der Audioaufnahme synchronisiert wird und wie das lokale RAG aufgebaut ist. Bei einer Anwendung, die in Echtzeit während eines Gesprächs mitliest, sind das die Fragen, die über Einsatzfähigkeit entscheiden. Ein zweiter Punkt ist die Modellabhängigkeit. Natively liefert kein Modell mit. Die Qualität der Antworten hängt vollständig von dem Anbieter ab, dessen Schlüssel der Nutzer hinterlegt, und von den Kosten, die dieser Anbieter berechnet. Der Preisvorteil gegenüber Cluely gilt damit nur für den Client, nicht für die Inferenz. Ein dritter Punkt ist die Plattformbindung. Es gibt keine Linux-Version, und der README nennt auch keine mobile Anwendung. Wer auf Linux arbeitet, kann Natively nicht einsetzen. Viertens: Der README wirbt mit Nutzerzahlen und einer Latenzangabe, nennt aber keine Messmethode. Die Angabe unter 500 Millisekunden ist ohne Bezugspunkt nicht überprüfbar, und sie beschreibt nur die Aufnahmeseite, nicht die Zeit bis zur fertigen LLM-Antwort. Wer ein Meeting in einer Sprache führt, die der Anbieter schlecht unterstützt, wird die Latenzangabe ohnehin nicht erreichen. Schließlich ist der Anwendungsfall selbst ein Risiko: In Bewerbungsgesprächen kann der Einsatz zum Ausschluss führen, unabhängig davon, wie gut die Software funktioniert.

Was eine Alternative anders macht: Otter im Vergleich

Otter gehört zu den Werkzeugen, die der README als Konkurrenz nennt, und der Unterschied liegt nicht im Funktionsumfang, sondern im Ort der Verarbeitung. Otter ist ein Cloud-Dienst: Das Audio wird in die Infrastruktur des Anbieters übertragen, dort transkribiert und in einem Web-Konto abgelegt. Das Transkript ist damit von jedem Gerät aus erreichbar und durchsuchbar, und die Zusammenarbeit im Team ist der eigentliche Zweck des Produkts. Natively geht den umgekehrten Weg. Die Aufnahme bleibt nach Darstellung des Projekts auf dem Gerät, es gibt kein Konto und keine Synchronisation zwischen Geräten. Wer ein Meeting protokollieren und das Ergebnis später im Browser öffnen will, ist bei Otter richtig und bei Natively falsch. Wer umgekehrt verhindern will, dass Gesprächsmitschnitte auf fremden Servern liegen, hat bei Natively zumindest die Absichtserklärung des Projekts auf seiner Seite, aber keine unabhängige Prüfung. Ein zweiter Unterschied ist die Preisstruktur. Otter verlangt ein Abonnement, Natively verlangt nichts für den Client, aber einen eigenen API-Schlüssel. Bei intensiver Nutzung können die Inferenzkosten die Abonnementgebühr übersteigen. Ein dritter Unterschied ist die Reife. Otter ist ein kommerzielles Produkt mit Support und einer dokumentierten Oberfläche. Natively ist ein Einzelprojekt mit drei Releases in vier Monaten und einer README-Datei, die mehr Marketing als Technik enthält.

Pflegeaufwand, Updates und was vor dem Einsatz zu prüfen ist

Die Release-Historie im Material zeigt drei Versionen: 2.6.0 im Mai, 2.7.0 im Juni und 2.8.8 im August. Der letzte Push liegt auf September 2026. Das spricht für einen aktiven Maintainer, aber die Abstände sind unregelmäßig, und ein einzelnes Projekt dieser Art kann jederzeit pausiert werden. Wer Natively einsetzt, sollte damit rechnen, dass Breaking Changes an der Modell-API eines Anbieters den Client unbrauchbar machen, bis ein Update erscheint. Ein automatisches Update ist im README nicht beschrieben. Der Upgrade-Pfad besteht damit aus dem manuellen Herunterladen einer neuen Version von der Releases-Seite. Auf der Kostenseite fallen neben dem eigenen API-Schlüssel keine Lizenzgebühren an, solange die Nutzung im persönlichen, nicht-kommerziellen Rahmen bleibt. Für Unternehmen ist der kommerzielle Einsatz durch die Personal-Use-Klausel nicht abgedeckt. Vor dem ersten Einsatz würde ich drei Dinge prüfen: die LICENSE-Datei im Repository, die Angaben zum Datenfluss in der Anwendung selbst, und ob der verwendete Modellanbieter die Gesprächsinhalte für Training oder Protokollierung nutzt. Keine dieser Fragen lässt sich aus dem README beantworten.

Redaktionelles Fazit

Wer einen Overlay-Copilot für Bewerbungsgespräche, Vorlesungen oder Meetings sucht, eigene API-Schlüssel mitbringt und macOS 12+ oder Windows 10/11 nutzt, findet in Natively ein installierbares Werkzeug mit lokalem Audio-Pfad. Wer eine rechtlich belastbare Lizenz für kommerziellen Einsatz, eine dokumentierte Datenhaltung oder eine Auditierbarkeit der Audioverarbeitung braucht, sollte zuerst die LICENSE-Datei und die Datenschutzerklärung von natively.software lesen. Ohne diese beiden Dokumente bleibt die zentrale Zusage des Projekts, dass keine Daten das Gerät verlassen, eine Behauptung aus dem README.

Offizielle Quellen

1. Issues
2. Natively-AI-assistant/natively-cluely-ai-assistant on GitHub
3. Project website
4. README
5. Releases