Was Discords Regeln dir tatsächlich zu bauen erlauben

Drei Dokumente regeln, was du auf Discord bauen darfst, sie decken Verschiedenes ab, und fast jede Frage danach, was erlaubt ist, wird in einem davon beantwortet. Das hier ist eine verständliche Landkarte, keine Rechtsberatung.

Drei Dokumente, drei Geltungsbereiche

Die Terms of Service regeln deine Nutzung von Discord und damit auch, wie du einen Server betreiben darfst. Die Developer Terms of Service regeln das Bauen von Anwendungen auf der API. Die Developer Policy ergänzt die konkreten Datenregeln: was eine App erheben darf, wie lange sie es behalten darf und was sie tun muss, wenn ein Nutzer fragt.

Betreibst du eine Community, bindet dich das erste. Beauftragst du einen Bot, binden den Erbauer alle drei — und die Pflichten gehen nicht dadurch auf ihn über, dass du bezahlt hast.

Zugang zu einem Server verkaufen

Für eine Rolle oder für den Eintritt Geld zu verlangen ist im Rahmen von Discords Monetarisierungsregeln erlaubt, aber diese Regeln sind konkret darin, was verkauft und wie es dargestellt werden darf. Lies die Monetization Policy, bevor du eine Stufe entwirfst, nicht danach — die Grenzen betreffen den Inhalt des Angebots, nicht nur den Zahlungsweg.

Der betriebliche Punkt, der untergeht: Monetarisierungsprivilegien hängen daran, dass der Server ohne Beanstandungen dasteht. Ein Verstoß gegen die Community-Richtlinien kostet nicht nur eine Verwarnung, sondern kann die Umsatzvereinbarung kosten.

Was ein Bot speichern darf

Hier ist die Developer Policy das maßgebliche Dokument, und ihre Linie ist einheitlich: Erhebe, was die angegebene Funktion braucht, behalte es nur so lange, wie diese Funktion es erfordert, sichere es, und lösche es, wenn ein Nutzer oder ein Server es verlangt. Sammeln auf Vorrat, weil es nützlich sein könnte, ist genau das, wogegen die Richtlinie geschrieben ist.

Nachrichteninhalte verdienen besondere Vorsicht, weil sie auf API-Ebene privilegiert und auf Richtlinienebene sensibel sind. Ein Bot, der Nachrichtentext speichert, braucht einen konkreten Grund und eine kurze Aufbewahrungsfrist — und sollte damit rechnen, dass dieser Grund bei der Verifizierung geprüft wird.

Scraping und Exporte

Die API mit einem Bot zu lesen, den ein Server installiert hat, ist der vorgesehene Weg. Ein Nutzerkonto zu automatisieren, um Daten zu sammeln, nicht — Selfbots sind untersagt, und das Verbot wird gegen das Konto durchgesetzt, nicht gegen den Code.

Das ist bei einer sehr gewöhnlichen Bitte relevant: eine Community umzuziehen und die Historie mitzunehmen. Die unterstützte Antwort ist, den Server zu behalten und umzubauen, statt Gespräche zu exportieren und wieder einzuspielen.

Weiterverkauf und White-Labelling

Einen Bot für einen Kunden zu bauen und zu übergeben ist normale Arbeit. Dieselbe Anwendung an viele Kunden weiterzuverkaufen macht daraus eine öffentliche App mit allen Pflichten der Skalierung — Verifizierung, Intent-Freigaben, Sharding und Supportlast. Das sind verschiedene Produkte mit verschiedener Ökonomie, und eines wie das andere zu behandeln ist ein verbreiteter Weg, sich festzufahren.

Für einen Kunden ist die praktische Frage einfacher: Gehört mir der Code oder eine Lizenz auf etwas, das die Agentur auch anderswo verkauft? Beides ist legitim. Nur eines lässt sich mitnehmen.

Löschung ist Pflicht, kein Feature

Verlangt ein Nutzer oder ein Server von einer App, seine Daten zu löschen, muss die App das können. Diese Anforderung entscheidet, wie der Bot gebaut sein muss — Daten nach Nutzer- und Server-Kennung geschlüsselt, mit einem Löschpfad — und sie ist als Entwurfsentscheidung am Anfang viel billiger als als Nachrüstung.

Wo das Risiko tatsächlich sitzt

Durchgesetzt wird auf Konto- und Plattformebene. Die realistischen Folgen sind eine Anwendung, die Verifizierung oder Intents verliert, ein Server, der die Monetarisierung verliert, oder ein Konto, gegen das vorgegangen wird. Für einen Bot, der still mehr gespeichert hat als angegeben, gibt es selten einen Warnschuss.

Das ist das Argument, die drei Dokumente einmal zu Projektbeginn zu lesen und aufzuschreiben, was das System speichert und warum. Diese Seite ist zugleich der größte Teil dessen, was du für ein Verarbeitungsverzeichnis brauchst — sie zahlt sich also doppelt aus.

Alters- und Inhaltsregeln prägen den Entwurf

Discord hat ein Mindestalter für seinen Dienst und eigene Regeln für altersbeschränkte Inhalte, einschließlich der Frage, welche Kanäle sie tragen dürfen und wer sie sehen darf. Für einen Community-Betreiber sind das keine abstrakten Richtlinien: Sie entscheiden, ob ein Kanal eine Altersmarkierung braucht und ob eine geplante Funktion überhaupt tragfähig ist.

Die Konsequenz ist, früh zu entscheiden. Eine Altersschranke nachträglich in eine laufende Community einzuziehen bedeutet, den Bestand zu prüfen — deutlich störender, als das Kanal-Flag am ersten Tag zu setzen.

Verifizierungs-Abzeichen und was sie nicht bedeuten

Ein Verifizierungs-Abzeichen an einer Anwendung signalisiert, dass Discord die Identität des Entwicklers geprüft und die beantragten Intents geprüft hat. Es bescheinigt nicht, dass der Bot gut gebaut ist, verantwortungsvoll mit Daten umgeht oder nächstes Jahr noch gepflegt wird.

Behandle es wie jeden Nachweis: als Aussage über das Verfahren, nicht über das Produkt. Die Fragen, die dir sagen, ob ein Bot installierbar ist, bleiben dieselben drei — Datenschutzerklärung, Aufbewahrungsfrist, Löschpfad.

Was mit einer Agentur schriftlich gehört

Vier Punkte erledigen das meiste. Wem der Quellcode alles Individuellen gehört und dass eine Kopie geliefert wird. Unter welcher Anwendung und welchem Entwicklerkonto der Bot läuft und wer die kontrolliert. Was der Bot speichert und wie lange. Und was mit dem Hosting passiert, wenn die Zusammenarbeit endet.

Der dritte Punkt ist der, nach dem Kunden fast nie fragen und den sie sich später wünschen — denn er ist zugleich die Antwort, die sie brauchen, wenn jemand wissen will, was ihre Community über ihre Mitglieder speichert.

Die eine Seite, die sich zu führen lohnt

Ein einziges Dokument, das jedes System auflistet, das Mitgliederdaten berührt: der Bot und was er speichert, jeder fremde Bot und seine Richtlinie, wo beides läuft, die Aufbewahrungsfrist und wer zuständig ist. Für die meisten Communities eine halbe Seite.

Sie beantwortet eine Datenschutzfrage, eine Prüfungsfrage und eine Übergabefrage auf einmal, und sie kostet einen Nachmittag, solange das Projekt frisch ist. Zwei Jahre später aus einem laufenden System rekonstruiert, kostet sie eine Woche.