Lizenzen

Heinzel Pro wird als Abonnement verkauft. Die Installation prüft einen signierten Lizenzschlüssel offline. Viermal am Tag holt sie sich einen verlängerten Schlüssel bei heinzel-pro.de und schickt dafür nur den Schlüssel, den sie hat; das lässt sich abschalten. Womit sich eine Installation verbindet, steht in security.md, "Was die Installation verlässt".

Die Lizenzseite und der Kasten „Betrieb“ unter Installation, Protokoll sagen, wann das zuletzt geklappt hat, oder seit wann und warum es scheitert. Nach einem Tag ohne Erfolg bekommen die Administratoren der Installation eine Mail, und in den letzten 14 Tagen vor dem Datum des Schlüssels zeigt ihnen ein Banner es auf jeder Seite. Abhilfe ist HTTPS (Port 443) zu heinzel-pro.de, oder der Schlüssel aus der Mail, von Hand eingetragen.

Für Kunden

• Ohne Schlüssel läuft die Installation 14 Tage als Testphase mit drei Plätzen.
• Ein Platz ist jedes aktive Mitglied und jede Admin-Person eines Mandanten, auch wer nur zuschaut. Eine offene Einladung belegt keinen, bis sie angenommen ist.
• Der Schlüssel trägt eine Zahl von Plätzen für die ganze Installation. Wo die Installation mehrere Mandanten hat, kann jeder eine eigene Zahl darunter bekommen, siehe administration.md, „Plätze pro Mandant“. Eine Person zählt für den Schlüssel einmal, in wie vielen Mandanten sie auch handelt. Für Server gilt dasselbe: Der Schlüssel trägt eine Zahl für die Installation, jeder Mandant kann eine eigene darunter bekommen.
• Nach Ablauf des Schlüssels gibt es 14 Tage Kulanz mit Hinweisbanner. Danach starten keine neuen Sessions oder geplanten Läufe; alles Aufgezeichnete bleibt lesbar.
• Schlüssel werden unter Installation, Einstellungen, Lizenz eingefügt.

Tarife

Eine Installation beginnt mit fünf Tarifen. Sie sind Vorlagen: Was ein Mandant bekommt, ist seine eigene Kopie, und ein später geänderter Tarif lässt sie, wie sie ist (siehe administration.md, „Tarife“).

Die parallelen Sessions gelten für alle im Mandanten zusammen, wie viele Plätze er auch hat. Gezählt wird jede Session, an der Heinzel gerade arbeitet, auch die eines Rollouts oder Zeitplans: Ein Rollout auf drei Servern zugleich belegt drei. Eine Session, die auf eine Freigabe oder auf die nächste Nachricht wartet, zählt nicht, und ein freigegebener Befehl läuft weiter, auch wenn alle in Arbeit sind.

Sind alle in Arbeit, wird ein neuer Auftrag nicht abgelehnt. Das Nachrichtenfeld sagt es schon vor dem Senden; der Auftrag wartet dann in der Reihe, der älteste zuerst, seine Session zeigt seine Nummer in der Reihe mit „Zurücknehmen“, und er startet, sobald eine andere Session fertig ist, auch nach einem Neustart. Dafür muss niemand auf der Seite bleiben.

Rollouts und Zeitpläne über mehrere Server nehmen nur Sessions, auf die niemand wartet: Nachrichten von Menschen gehen immer vor. Ein Rollout läuft auf bis zu vier Servern gleichzeitig, wenn so viele frei sind, sonst auf weniger; einer seiner Server läuft aber immer, damit er an einem vollen Tag langsamer wird und nicht stehen bleibt. Sessions, die zusammenarbeiten, starten gleichzeitig und brauchen deshalb beim Start eine freie Session je Server.

Der Reiter Läuft in der Sessions-Liste zeigt die Belegung, etwa „4/4“, und darunter zwei Abschnitte: was in Arbeit ist, und was in welcher Reihenfolge auf eine freie Session wartet, zuerst die Aufträge von Menschen, dann die Server jedes Rollouts oder Zeitplans, jeder in seiner eigenen Zeile. Ein Kästchen pro Session zeigt in seiner Farbe, wessen Session sie ist: die einer Person, eines Rollouts oder eines Zeitplans. Dieselben Abschnitte stehen auf der Übersicht unter „Laufende Sessions“; die Seite eines Rollouts, der auf freie Sessions wartet, sagt das und nennt seine Nummer in der Reihe.

Seit dem 30. Oktober 2026 gelten die parallelen Sessions oben auch für Mandanten, die vorher bestellt haben, und auf der gehosteten Installation auch Plätze und Server. Eine Grenze, die von Hand niedriger gesetzt ist, bleibt, und kein Mandant verliert einen Platz oder Server, den er schon nutzt. Ein Team-Mandant mit einem gültigen API-Token behält die API.

Ohne API lehnt die Schnittstelle jeden Token mit 403 ab und nennt den Grund. Die Tokens bleiben erhalten und gelten wieder, sobald der Tarif die API enthält.

Ohne „Mehrere Server“ arbeitet eine Session mit einem Server. Unter Neue Session stehen „Mehrere zusammen“ und „Dasselbe auf vielen“ ausgegraut da, mit einem Link zu den Tarifen; ein Rollout und eine Session über mehrere Server werden abgelehnt.

Free zählt Arbeitszeit: 1 Stunde je Kalenderwoche (Montag 0 Uhr bis Sonntag, Berliner Zeit), vom ersten Tag an. Gezählt wird, solange Heinzel arbeitet oder jemand eine Seite des Mandanten vor sich offen hat; jeder Moment zählt einmal, auch wenn zwei Sessions laufen oder jemand seiner eigenen Session zusieht. Ein Tab im Hintergrund zählt nicht, eine Session, die auf eine Freigabe, die nächste Nachricht oder eine andere Session wartet, auch nicht, ein Neustart oder Absturz auch nicht. Ist die Stunde aufgebraucht, bleiben die Seiten offen und eine bestehende Session geht weiter; nur eine neue Session (von einer Person, einem Zeitplan oder einer Warnung) und ein neuer Zeitplan warten auf die nächste Woche. Der Knopf „Neue Session“ steht dann ausgegraut da. Darunter zählt „Restzeit im Free-Tarif“ die Minuten der Woche bis zum nächsten Reset herunter, dessen Datum und Uhrzeit darunter stehen, grün über der Hälfte, gelb über einem Fünftel, rot darunter; auf dem Telefon zeigt die Leiste oben dieselbe Zahl. Gezählt wird erst, wenn ein Modell verbunden ist und Heinzel sich auf einem Server angemeldet hat; ein Server, der noch eingerichtet wird, zählt nicht. Bis dahin steht die Anzeige grau still. Die anderen Tarife zählen keine Zeit.

Tarif bestellen und wechseln

Auf einer gehosteten Installation bestellen die Administratoren eines Mandanten unter Einstellungen, Tarif selbst: Tarif, monatlich oder jährlich (zehn Monatspreise). Jeder Preis enthält die Plätze des Tarifs, pro Platz kommt nichts dazu: Solo 1, Team 3, Business 35, Enterprise 100. Bevor bestellt wird, steht dort, was es kostet. Alle Preise sind netto, dazu kommt die Umsatzsteuer, wo sie anfällt. Das Formular fragt nach der Rechnungsadresse und, falls vorhanden, der USt-IdNr.; beides bleibt für die nächste Bestellung stehen.

• Stichtag. Ein Abo beginnt an jedem beliebigen Tag; dieser Tag ist sein Stichtag, und jeder Zeitraum beginnt an ihm. Fehlt er in einem Monat, beginnt der Zeitraum am letzten Tag dieses Monats; danach gilt wieder der Stichtag. Ein Zeitraum kostet den vollen Preis, ob er 28 oder 31 Tage hat.
• Nach oben (größerer Tarif, mehr Plätze, Monat zu Jahr) gilt sofort. Der Rest des Zeitraums wird tagesgenau verrechnet: neuer Preis minus alter Preis, je für die übrigen Tage.
• Nach unten gilt ab dem nächsten Zeitraum, ohne Erstattung, und erst, wenn Plätze und Server in den kleineren Tarif passen; sonst sagt die Seite, was zu viel ist. Bis dahin nimmt „… behalten“ den Wechsel zurück.
• Bezahlen. Der Tarif gilt sofort, zunächst 45 Tage. Die Rechnung kommt per Mail; als bezahlt markiert gilt er bis zum Ende des Zeitraums. 14 Tage nach dem letzten bezahlten Tag fällt ein Mandant auf Free zurück.
• Preislisten. Ein Preis wird nie geändert, die Datenbank weist es ab. Neue Preise sind eine neue Liste für neue Bestellungen; jede Bestellung behält den Betrag, mit dem sie aufgegeben wurde. Installation, Preise zeigt die Liste im Verkauf und verkauft eine neue; die Liste im Verkauf steht unter /api/prices für die Website bereit.

Wer bestellt hat, sehen die Administratoren der Installation unter Installation, Bestellungen, wo sie eine Bestellung als bezahlt markieren: Jeder Klick begleicht den ältesten noch offenen Zeitraum, erst den ersten, dann jeden danach in Rechnung gestellten, sodass eine späte Zahlung nie einen späteren Zeitraum mit abdeckt. HEINZEL_SALES_TO nennt die Adresse, die jede Bestellung per Mail bekommt, dazu jede Kündigung, jede fällige Rechnung und jede Rechnung, die von Hand zu schreiben ist. Jede dieser Mails endet mit allem über den Kunden und die Bestellung: dem Mandanten und wann er angelegt wurde, Rechnungsadresse und USt-IdNr., wer bestellt hat und jedem Administrator mit Mailadresse, Tarif, Preis und Zahlungsart, wann bestellt, bezahlt und von wem gekündigt wurde, wann sie endet, und jeder Zahlung, alles mit Uhrzeit, damit Sie beim Kunden nachfragen können, ob alles passt. Außerdem bekommt sie am 1. jedes Monats einen Bericht über den Monat davor: Bestellungen, Kündigungen, was läuft und was es im Monat bringt, was Stripe eingezogen hat, und wie viele Mandanten, Personen, Server und Sessions es gab.

Eine Lizenz für den eigenen Betrieb bestellen

Unter Einstellungen, Tarif schaltet „On-Premise“ auf die Preise für den Betrieb auf eigenen Servern um; es gibt sie für Business und Enterprise, Team läuft nur bei uns. Eine solche Bestellung läuft neben dem Tarif des Mandanten, ändert an ihm nichts und kommt mit einem signierten Lizenzschlüssel, der gleich auf derselben Seite steht und sich als Datei herunterladen lässt. Er gilt 45 Tage, solange die Bestellung noch nicht bezahlt ist, danach vier Wochen über den letzten bezahlten Tag hinaus, als Puffer, falls heinzel-pro.de einmal ausfällt oder eine Zahlung spät kommt. Mit jedem bezahlten Zeitraum gibt es einen neuen auf der Seite, und die eigene Installation holt ihn sich selbst. Per Mail an die Administratoren des Mandanten kommt der erste Schlüssel einer Bestellung, ein verlängerter nur, wenn die Installation ihn nach einer Woche noch nicht abgeholt hat. Wer per Rechnung zahlt, bekommt zu Beginn jedes Zeitraums einen Schlüssel bis vier Wochen nach dessen Ende, bevor die Rechnung bezahlt ist; die Mail an HEINZEL_SALES_TO erinnert daran, sie zu schreiben. Auf der eigenen Installation gehört er unter Installation, Einstellungen, Lizenz, und dort gilt er noch 14 Tage über sein Datum hinaus.

Kündigen

Tarif wie Lizenz kündigt ein Administrator auf derselben Seite zum Ende des laufenden Zeitraums. Bis dahin gilt alles weiter, danach wird nichts mehr abgebucht und kein Schlüssel mehr signiert; ein Mandant fällt dann sofort auf Free zurück. Bis zum letzten Tag lässt sich die Kündigung zurücknehmen. Die Mail an HEINZEL_SALES_TO nennt den Tag, an dem sie endet.

Für den Betreiber: Signiert wird mit HEINZEL_LICENSE_PRIVATE_KEY, dem privaten Teil des Schlüsselpaars unten. Er gehört nur auf die gehostete Installation, nie auf die eines Kunden. Ohne ihn signiert die Installation nichts, und die Mail an HEINZEL_SALES_TO sagt, dass der Schlüssel von Hand auszustellen ist.

Bezahlen per Karte oder Lastschrift

Unter Einstellungen, Tarif hinterlegen die Administratoren eines Mandanten eine Karte oder ein SEPA-Lastschriftmandat, auf der Seite von Stripe; Heinzel Pro bekommt davon nur, welches es ist („Visa •••• 4242“). Danach wird jede Bestellung abgebucht: der fällige Betrag sofort, der volle Betrag zu Beginn jedes weiteren Zeitraums. Bezahlt ist ein Zeitraum erst, wenn Stripe es meldet, bei einer Karte sofort, bei einer Lastschrift nach einigen Tagen. Schlägt eine Abbuchung fehl, steht der Grund auf der Seite; der Tarif gilt dann wie bei einer offenen Rechnung noch 14 Tage, und mit einer neu hinterlegten Karte wird der Betrag erneut abgebucht.

Die Preise sind netto. Stripe bucht sie mit der Umsatzsteuer ab, die die Rechnungsadresse verlangt: 19 % in Deutschland und für Privatpersonen im übrigen EU-Ausland, keine für Unternehmen im übrigen EU-Ausland mit USt-IdNr. (Reverse Charge) und für alle außerhalb der EU. Stripe zieht nur das Geld ein; die Rechnung schreibt sevdesk und mailt sie sofort an die Person, die bestellt hat, als E-Rechnung mit dem Vermerk, dass sie bezahlt ist.

Für den Betreiber: STRIPE_SECRET_KEY schaltet das ein, und STRIPE_WEBHOOK_SECRET ist das Signaturgeheimnis des Webhooks https://<Host>/api/stripe/webhook mit den Ereignissen payment_intent.succeeded, payment_intent.processing und payment_intent.payment_failed. Welche Zahlungsarten Stripe anbietet, legt das Stripe-Dashboard fest: Legen Sie dort eine eigene Zahlungsmethoden-Konfiguration mit nur Karte und SEPA-Lastschrift an und tragen Sie deren Kennung (pmc_…) als STRIPE_PAYMENT_METHOD_CONFIGURATION ein. Ohne sie bietet Stripe alles an, was die Standardkonfiguration des Kontos enthält, auch Zahlungsarten, die sich nicht ohne Zutun abbuchen lassen.

SEVDESK_API_TOKEN, der API-Token eines sevdesk-Administrators, lässt sevdesk diese Rechnungen schreiben. Ohne ihn, bei einem Land in der Rechnungsadresse, dessen Umsatzsteuer Heinzel Pro nicht kennt, oder wenn sevdesk eine Rechnung zehnmal ablehnt, sagt die Mail an HEINZEL_SALES_TO, dass sie von Hand zu schreiben ist. Als bezahlt gebucht wird die Rechnung in sevdesk nicht; ordnen Sie sie dort der Auszahlung von Stripe zu. Mit einem Testschlüssel (sk_test_…) wird nichts in Rechnung gestellt: Testgeld ist kein Umsatz.

Für den Anbieter

Schlüssel sind Ed25519-Signaturen über eine JSON-Nutzlast. Das Signierpaar einmal erzeugen:

$ mix heinzel.license keygen

Den öffentlichen Schlüssel in den Build legen (config :heinzel_pro, :license_public_key) oder auf Kundeninstallationen HEINZEL_LICENSE_PUBLIC_KEY setzen. Den privaten Schlüssel offline aufbewahren; die einzige Ausnahme ist die gehostete Installation, die Bestellungen ihren Schlüssel selbst signiert (HEINZEL_LICENSE_PRIVATE_KEY).

Einen Schlüssel ausstellen:

$ mix heinzel.license issue --customer "ACME GmbH" --plan team --seats 5 \
  --expires 2027-12-31 --private-key "$HEINZEL_LICENSE_PRIVATE_KEY"

Einen prüfen:

$ mix heinzel.license verify HPL1....

Pläne: team, business, enterprise. Die Nutzlast trägt zusätzlich eine optionale Serveranzahl und Feature-Liste für später.

Quellcode für einzelne Kunden

Heinzel Pro ist keine Open-Source-Software. Einzelne Kunden bekommen den Quellcode zu lesen und zu ändern, nach LICENSE.md, und dürfen Änderungen als Pull Request zurückgeben. Was sie zurückgeben, wird an alle anderen Kunden verkauft, also sind die Rechte daran geklärt, bevor es jemand übernimmt:

1. Der Vertrag des Kunden räumt den Zugriff schriftlich ein.
2. Der Kunde schickt die Beitragsvereinbarung unterschrieben zurück (docs/de/contributor-agreement.md), mit den GitHub-Konten seiner Leute in der Anlage. Sie wird außerhalb des Repositorys aufbewahrt.
3. Die Konten kommen in .github/contributors. Die Prüfung contributors lässt einen Pull Request durchfallen, solange sein Ersteller oder der Autor eines seiner Commits dort fehlt.
4. Die Konten bekommen auf GitHub die Rolle „Read“.

Schritt 4 setzt voraus, dass das Repository einer Organisation gehört. Ein Repository eines persönlichen Kontos kennt nur Mitarbeiter mit Schreibrecht: Wer dort eingeladen ist, kann nach main schreiben, Pull Requests übernehmen und ein Tag setzen, und ein Tag baut das Image und spielt es auf die gehostete Installation. Nachzulesen bei GitHub unter „Permission levels for a personal account repository“. Solange das Repository bei einem persönlichen Konto liegt, wird kein Kunde eingeladen.

Die Prüfung beweist, wer eingereicht hat, nicht, wer geschrieben hat. Für Code Dritter unter dem Namen eines Benannten steht der Kunde nach Ziffer 6 der Vereinbarung ein.