Zum Inhalt springen

Lizenzen

Heinzel Pro wird als Abonnement verkauft. Die Installation prüft einen signierten Lizenzschlüssel offline: Der Schlüssel wird nirgendwohin gesendet. Womit sich eine Installation verbindet, steht in security.md, "Was die Installation verlässt".

Für Kunden

  • Ohne Schlüssel läuft die Installation 14 Tage als Testphase mit drei Plätzen.
  • Ein Platz ist jeder aktive Benutzer, der handeln kann: Operator, Freigeber oder Administrator, oder wer ein einzelnes Recht zum Handeln bekommen hat. Rechte zum Ansehen sind frei.
  • 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.

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.

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.